टाइप करने के लिए g ++ अपरिभाषित संदर्भ

208

मैं बस निम्नलिखित त्रुटि पर भागा (और समाधान ऑनलाइन पाया, लेकिन यह स्टैक ओवरफ्लो में मौजूद नहीं है):

।

लिंकर की त्रुटियों के लिए इन "अपरिभाषित संदर्भ" में से किसी एक को क्यों प्राप्त किया जा सकता है?

(बोनस अंक यदि आप बता सकते हैं कि पर्दे के पीछे क्या चल रहा है।)

c++ linker g++

— cdleary
स्रोत

31

मुझे पता है कि यह एक पुरानी पोस्ट है, लेकिन मुझे आज भी यही समस्या थी, और समाधान बस मेरे वर्चुअल फ़ंक्शन को वर्चुअल एबीसी () के बजाय बेस क्लास में वर्चुअल एबीसी () {} के रूप में परिभाषित करना था; जो त्रुटि दी।

— नव

15

के रूप में बेहतर अभी तक virtual void abc() =0;(यदि आधार संस्करण कभी नहीं कहा जाता है)

— dhardy

3

@Nav: यदि आप इस abc()तरह परिभाषित करते हैं कि आप आसानी abc()से व्युत्पन्न वर्ग में फिर से परिभाषित कर सकते हैं और सोच सकते हैं कि सब कुछ ठीक है, क्योंकि आप अभी भी फ़ंक्शन को बिना किसी समस्या के कॉल कर सकते हैं। शुद्ध आभासी कार्यों को लागू करने के लिए एक अच्छा अभ्यास इस लेख में पाया जाता है , और यह फ़ंक्शन प्रिंट को "शुद्ध आभासी फ़ंक्शन कहा जाता है" बनाने और फिर प्रोग्राम को क्रैश करने के लिए है।

— HelloGoodbye

1

मुझे एक ही त्रुटि हो रही थी। मैंने पाया है कि "lib" के संदर्भों के बदलते क्रम से मदद मिल सकती है। मैंने सिर्फ समस्या को लिबरल करने से लेकर सूची के अंत तक ले जाने की समस्या को हल किया और इस समस्या को हल किया

— javapowered

2

GAH। यह अब कम से कम दूसरी बार है जब मैंने इस पेज पर बिल्कुल नेविगेट किया है, @ डॉड़ी द्वारा टिप्पणी पढ़ने और खुद को 'दोह' कहने के लिए। बस कुछ पागल व्यवहार को ट्रैक करने की कोशिश में 45minutes बिताए और मुझे जो चाहिए था = 0;।

— dwanderson

222

एक संभावित कारण यह है कि आप इसे परिभाषित किए बिना एक आभासी फ़ंक्शन घोषित कर रहे हैं।

जब आप इसे एक ही संकलन इकाई में परिभाषित किए बिना घोषित करते हैं, तो आप संकेत दे रहे हैं कि यह कहीं और परिभाषित है - इसका मतलब है कि लिंकर चरण इसे अन्य संकलन इकाइयों (या पुस्तकालयों) में से एक में खोजने की कोशिश करेगा।

वर्चुअल फ़ंक्शन को परिभाषित करने का एक उदाहरण है:

virtual void fn() { /* insert code here */ }

इस स्थिति में, आप घोषणा की एक परिभाषा संलग्न कर रहे हैं, जिसका अर्थ है कि लिंकर को बाद में इसे हल करने की आवश्यकता नहीं है।

रेखा

virtual void fn();

fn()इसे परिभाषित किए बिना घोषित करता है और आपके द्वारा पूछे गए त्रुटि संदेश का कारण होगा।

यह कोड के समान है:

extern int i;
int *pi = &i;

जो बताता है कि पूर्णांक iएक अन्य संकलन इकाई में घोषित किया गया है जिसे लिंक समय पर हल किया जाना चाहिए (अन्यथा piइसे इसके पते पर सेट नहीं किया जा सकता है)।

— paxdiablo
स्रोत

28

यह कहना गलत है कि virtual void fn() = 0यह एक परिभाषा है। यह कोई परिभाषा नहीं है, बल्कि एक मात्र घोषणा है । एकमात्र कारण जो लिंकर इसे हल करने की कोशिश नहीं कर रहा है, वह यह है कि संबंधित वीएमटी प्रविष्टि एक फ़ंक्शन बॉडी का उल्लेख नहीं करेगी (इसमें नल-पॉइंटर सबसे अधिक होने की संभावना है)। हालाँकि, कोई भी आपको इस शुद्ध आभासी फ़ंक्शन को गैर-आभासी तरीके से, यानी पूर्ण-योग्य नाम का उपयोग करने से रोकता है। इस मामले में लिंकर शरीर की तलाश करेगा , और आपको फ़ंक्शन को परिभाषित करना होगा। और हाँ, आप एक शुद्ध आभासी कार्य के लिए एक निकाय को परिभाषित कर सकते हैं।

— चींटी

1

और कभी-कभी किसी को शुद्ध आभासी कार्य के लिए एक निकाय भी घोषित करना चाहिए।

— मार्क

3

संकलक (जी ++) आपको बताएगा कि लापता प्रतीक क्या है। नोट: डायनेमिक लाइब्रेरी को लिंक करने के मामले में आपको एक मांगलिक नाम मिल सकता है। इसे पढ़ने योग्य रूप में प्राप्त करने के लिए c ++ filt <mangledNameVariable> का उपयोग करें। वर्ग नाम के साथ टाइपिनफ़ॉफ़ त्रुटि मेरे मामले में कुछ बेस क्लास में एक लापता वर्चुअल विध्वंसक कार्यान्वयन के कारण थी।

— चीकू

1

प्रश्न में विशेष रूप से उल्लेख किया गया है कि यह टाइपिनफो गायब है, जिसे आरटीआई के साथ करना है। में डैमन से टिप्पणी देखें stackoverflow.com/questions/11904519/...

— wilsonmichaelpatrick

1

@ गुम्हंटर, काफी फेयर। परिवर्तन कर दिया।

— paxdiablo

149

जब आप मिक्स -fno-rttiऔर -frttiकोड करते हैं तो यह भी हो सकता है । फिर आपको यह सुनिश्चित करने की आवश्यकता है कि किसी भी वर्ग, जो कोड type_infoमें एक्सेस किया गया है -frtti, उनकी कुंजी विधि के साथ संकलित है -frtti। इस तरह की पहुंच तब हो सकती है जब आप कक्षा, उपयोग dynamic_castआदि का उद्देश्य बनाते हैं ।

[ स्रोत ]

— सर्गी बेलोज़ोरोव
स्रोत

20

बहुत बहुत धन्यवाद। 5 घंटे की खोज के बाद मेरी समस्या ठीक हो गई।

— स्टीफेट

1

स्रोत लिंक मृत है, यह निश्चित रूप से permalink.gmane.org/gmane.comp.gcc.help/32475

— गणित

1

इस पर ध्यान दिलाने के लिए धन्यवाद। मूल पृष्ठ अभी भी यहाँ उपलब्ध है: web.archive.org/web/20100503172629/http://www.pubbs.net/201004/…

— सर्गी बेलोज़ोरोव

3

StackOverflow.com फिर से बचाव के लिए! काश मैं एक से अधिक बार उत्थान कर पाता। एक घंटे के लिए कीबोर्ड पर मेरा सिर पीटने के बाद आपका जवाब था कि मुझे क्या चाहिए।

— स्पार्टीगव

1

n + 1 की जान बची और अभी भी गिनती जारी है :)

— गेब्रियल

53

यह तब होता है जब घोषित (गैर-शुद्ध) वर्चुअल फ़ंक्शंस गुम शरीर होते हैं। आपकी कक्षा की परिभाषा में, कुछ इस तरह है:

virtual void foo();

परिभाषित किया जाना चाहिए (इनलाइन या किसी लिंक किए गए स्रोत फ़ाइल में):

virtual void foo() {}

या शुद्ध आभासी घोषित:

virtual void foo() = 0;

— cdleary
स्रोत

27

जीसीसी मैनुअल से उद्धरण :

पॉलीमॉर्फिक क्लासेस (वर्चुअल फ़ंक्शंस वाली कक्षाएं) के लिए, टाइप_इनफ़ॉफ़ ऑब्जेक्ट को वाइबेट के साथ लिखा जाता है [...] अन्य सभी प्रकारों के लिए, हम टाइप_इन्फो ऑब्जेक्ट को तब लिखते हैं जब इसका उपयोग किया जाता है: किसी अभिव्यक्ति के लिए 'टाइपिड' लगाते समय, ऑब्जेक्ट को फेंकना, या कैच क्लॉज या अपवाद विनिर्देश में एक प्रकार का संदर्भ देना।

और उसी पृष्ठ पर थोड़ा पहले:

यदि वर्ग किसी भी गैर-इनलाइन, गैर-शुद्ध आभासी कार्यों की घोषणा करता है, तो पहले वाले को कक्षा के लिए "कुंजी विधि" चुना जाता है, और विटेब केवल अनुवाद इकाई में उत्सर्जित होता है जहां कुंजी विधि परिभाषित होती है।

इसलिए, यह त्रुटि तब होती है जब "कुंजी विधि" अपनी परिभाषा को याद कर रही है, जैसा कि पहले से ही वर्णित अन्य उत्तर हैं।

— CesarB
स्रोत

2

मेरे मामले में, मेरे पास एक आधार वर्ग था जिसने घोषित किया लेकिन उन आभासी तरीकों को परिभाषित नहीं किया जो शुद्ध आभासी नहीं थे। एक बार मैंने उन्हें शुद्ध आभासी बना दिया, जो कि मेरा मतलब था, लिंकर त्रुटियां दूर हो गईं।

— तातियाना रचेवा

@TatianaRacheva धन्यवाद! लिंकर से त्रुटि रिपोर्टिंग मददगार से कम है और बड़े इंटरफ़ेस के लिए '= 0' की कमी को याद करना बहुत आसान है; शुद्ध आभासी के लिए!

— शाम

20

यदि आप एक .so को दूसरे से जोड़ रहे हैं, फिर भी एक और संभावना gcc या g ++ में "-fvisibility = hidden" के साथ संकलन कर रहा है। यदि दोनों .so फाइलें "-fvisibility = hidden" के साथ बनाई गई थीं और कुंजी विधि समान .so में नहीं है, तो वर्चुअल फ़ंक्शन के अन्य कार्यान्वयन के रूप में, बाद वाले को पूर्व की vtable या typeinfo नहीं दिखाई देगी। लिंकर के लिए, यह एक अनइम्प्लीमेंटेड वर्चुअल फंक्शन की तरह दिखता है (जैसा कि paxdiablo's और cdleary के जवाबों में)।

इस स्थिति में, आपको बेस क्लास की दृश्यता के लिए एक अपवाद बनाना चाहिए

__attribute__ ((visibility("default")))

कक्षा घोषणा में। उदाहरण के लिए,

class __attribute__ ((visibility("default"))) boom{
    virtual void stick();
}

एक और उपाय, निश्चित रूप से, "-fvisibility = hidden" का उपयोग नहीं करना है। यह संकलक और लिंकर के लिए चीजों को जटिल करता है, संभवतः कोड के प्रदर्शन की गिरावट के लिए।

— मानव
स्रोत

1

यदि आप सार या अप्रयुक्त हैं, तो बस गैर-आभासी कार्यों, सामान्य तौर पर सिर्फ कंस्ट्रक्टर के लिए आपको बेस क्लास को निर्यात (अनहाइड) करने की आवश्यकता नहीं है। व्युत्पन्न दूसरी ओर कक्षाएं, निर्यात करने के लिए अगर वे उपयोग किया जाता है है।

— क्रिस हुआंग-लीवर

एक हैक की तरह लगता है, लेकिन यह मेरी तरफ से लक्षणों को हल किया। धन्यवाद !

— मलत

15

पिछले उत्तर सही हैं, लेकिन यह त्रुटि उस वर्ग के ऑब्जेक्ट पर टाइपिड का उपयोग करने का प्रयास करने के कारण भी हो सकती है जिसमें कोई वर्चुअल फ़ंक्शन नहीं है। C ++ RTTI के लिए एक व्यवहार्य की आवश्यकता होती है, इसलिए ऐसी कक्षाएं जिन्हें आप कम से कम एक वर्चुअल फ़ंक्शन की आवश्यकता पर टाइप पहचान करने के लिए चाहते हैं।

यदि आप एक वर्ग पर काम करने के लिए जानकारी टाइप करना चाहते हैं जिसके लिए आप वास्तव में कोई आभासी कार्य नहीं चाहते हैं, तो विध्वंसक को आभासी बनाएं।

— टायलर मैकहेनरी
स्रोत

2

अधिकमास क्योंकि मुझे लगता है कि यह उस विशिष्ट त्रुटि संदेश का कारण होने की संभावना है (अपरिभाषित तरीकों के अधिक सामान्य मामले के विपरीत ...)

— एलेस्टेयर

4

एसओ के साथ मेरी एक आदत थी कि वोटों के आधार पर आदेश बदल सकता है क्योंकि उत्तर "ऊपर" के लिए नहीं है। मैं अब आम तौर पर किसी भी अन्य उत्तर का संदर्भ नहीं देता क्योंकि उन्हें भी हटाया जा सकता है। मेरा मानना है कि उत्तर स्टैंडअलोन होना चाहिए। मैं अभी भी रोपण के लिए उपयोगकर्ता नामों का उल्लेख करता हूं।

— paxdiablo

आप बिना किसी कंपनीयता के टाइपिड का उपयोग कर सकते हैं; जीसीसी मैनुअल से उद्धरण के लिए मेरा जवाब देखें।

— सीजरबी

11

मैंने बस इस त्रुटि पर कुछ घंटे बिताए, और जब यहां अन्य उत्तरों ने मुझे यह समझने में मदद की कि क्या चल रहा था, तो उन्होंने मेरी विशेष समस्या को ठीक नहीं किया।

मैं एक ऐसी परियोजना पर काम कर रहा हूं जो दोनों का उपयोग कर संकलन करती है clang++और g++। मुझे उपयोग करने से कोई लिंकिंग समस्या नहीं हो clang++रही थी, लेकिन undefined reference to 'typeinfo forत्रुटि हो रही थी g++।

महत्वपूर्ण बिंदु: जोड़ने के आदेश के साथ सामग्री g++। यदि आप उन पुस्तकालयों को सूचीबद्ध करते हैं जिन्हें आप एक क्रम में लिंक करना चाहते हैं जो गलत है तो आप प्राप्त कर सकते हैंtypeinfo त्रुटि ।

/ के साथ लिंक करने के आदेश के बारे में अधिक विवरण के लिए यह SO प्रश्न देखें ।gccg++

— dinkelk
स्रोत

धन्यवाद!!! मैंने एक दिन से अधिक समय यह जानने की कोशिश में बिताया है कि मुझे यह त्रुटि क्यों हो रही थी और जब तक मैंने यह उत्तर और आपके द्वारा लिंक किए गए लिंक को नहीं देखा, तब तक कुछ भी काम नहीं किया। बहुत बहुत धन्यवाद!!

— आइरीन

10

RTTI और गैर-RTTI पुस्तकालयों के साथ काम करने वाले कोड के लिए संभावित समाधान:

a) -ttti या -fno-rtti
b) के साथ सब कुछ पुनः प्राप्त करें ) यदि a) आपके लिए संभव नहीं है, तो निम्न प्रयास करें:

मान लें कि libfoo RTTI के बिना बनाया गया है। आपका कोड libfoo का उपयोग करता है और RTTI के साथ संकलित करता है। यदि आप libfoo में एक वर्ग (Foo) का उपयोग करते हैं जिसमें वर्चुअल हैं, तो आपको लिंक-टाइम त्रुटि में चलने की संभावना है जो कहता है: वर्ग Foo के लिए टाइपिनफो गायब है।

किसी अन्य वर्ग (जैसे FooAdapter) को परिभाषित करें जिसमें कोई वर्चुअल नहीं है और फू को आपके द्वारा उपयोग किए जाने वाले कॉल को अग्रेषित करेगा।

FooAdapter को एक छोटे स्थिर पुस्तकालय में संकलित करें जो RTTI का उपयोग नहीं करता है और केवल libfoo प्रतीकों पर निर्भर करता है। इसके लिए एक शीर्ष लेख प्रदान करें और अपने कोड (आरटीटीआई का उपयोग करता है) के बजाय इसका उपयोग करें। चूंकि FooAdapter का कोई आभासी कार्य नहीं है, इसलिए इसमें कोई भी प्रकार नहीं होगा और आप अपने बाइनरी को लिंक कर पाएंगे। यदि आप libfoo से कई अलग-अलग वर्गों का उपयोग करते हैं, तो यह समाधान सुविधाजनक नहीं हो सकता है, लेकिन यह एक शुरुआत है।

— फ्रेंकोइस
स्रोत

यह मेरे लिए था, विभिन्न आरटीटीआई सेटिंग्स के साथ एक पुस्तकालय से जोड़ना।

— मार्श

6

इसी तरह, RTTI, NO-RTTI के ऊपर चर्चा के दौरान, यह समस्या तब भी हो सकती है जब आप डायनेमिक_का उपयोग करते हैं और क्लास कार्यान्वयन वाले ऑब्जेक्ट कोड को शामिल करने में विफल होते हैं।

मैं साइगविन पर इस समस्या के निर्माण में भाग गया और फिर कोड को लिनक्स में पोर्ट कर रहा हूं। मेक फाइल्स, डायरेक्टरी स्ट्रक्चर और यहां तक कि gcc वर्जन (4.8.2) दोनों ही मामलों में समान थे, लेकिन कोड जोड़ा गया और Cygwin पर सही ढंग से संचालित हुआ लेकिन लिनक्स पर लिंक करने में विफल रहा। Red Hat Cygwin ने स्पष्ट रूप से कंपाइलर / लिंकर संशोधन किए हैं जो ऑब्जेक्ट कोड लिंकिंग आवश्यकता से बचते हैं।

लिनक्स लिंकर त्रुटि संदेश ने मुझे डायनेमिक_कास्ट लाइन में ठीक से निर्देशित किया था, लेकिन इस मंच में पहले के संदेशों ने मुझे वास्तविक समस्या: लापता ऑब्जेक्ट कोड के बजाय लापता फ़ंक्शन कार्यान्वयन की तलाश थी। मेरा वर्कअराउंड बेस और व्युत्पन्न वर्ग में एक आभासी प्रकार के फ़ंक्शन को स्थानापन्न करना था, उदाहरण के लिए डायनामिक_का उपयोग करने के बजाय वर्चुअल इंट isSpecialType ()। यह तकनीक ऑब्जेक्ट कार्यान्वयन कोड को लिंक करने की आवश्यकता से बचाती है ताकि ठीक से काम करने के लिए डायनेमिक_कास्ट प्राप्त किया जा सके।

— FNE
स्रोत

5

बेस क्लास (एक सार बेस क्लास) में आप एक वर्चुअल डिस्ट्रक्टर की घोषणा करते हैं और जैसा कि आप एक डिस्ट्रक्टर को एक शुद्ध वर्चुअल फ़ंक्शन के रूप में घोषित नहीं कर सकते हैं, या तो आपको इसे यहीं एब्सट्रैक्ट क्लास में परिभाषित करना होगा, बस एक डमी परिभाषा जैसे वर्चुअल / बेस; ) {} करेंगे, या किसी भी व्युत्पन्न वर्ग में।

यदि आप ऐसा करने में विफल रहते हैं, तो आप लिंक समय पर "अपरिभाषित प्रतीक" में समाप्त हो जाएंगे। चूंकि VMT में मिलान मिलान के साथ सभी शुद्ध आभासी कार्यों के लिए एक प्रविष्टि है क्योंकि यह व्युत्पन्न वर्ग में कार्यान्वयन के आधार पर तालिका को अपडेट करता है। लेकिन गैर-शुद्ध लेकिन आभासी कार्यों के लिए, इसे लिंक समय पर परिभाषा की आवश्यकता है ताकि यह वीएमटी तालिका को अपडेट कर सके।

प्रतीक को गिराने के लिए c ++ filt का उपयोग करें। $ C ++ फिल्ट की तरह _ZTIN10storageapi8BaseHostE "typeinfo for storageapi :: BaseHost" जैसा कुछ आउटपुट देगा।

— प्रशांत
स्रोत

3

मुझे अभी इन त्रुटियों का एक बहुत कुछ मिला है। क्या हुआ कि मैंने हेडर-फाइल-केवल क्लास को हेडर फाइल और सीपीपी फाइल में विभाजित किया है। हालाँकि, मैंने अपने बिल्ड सिस्टम को अपडेट नहीं किया, इसलिए cpp फ़ाइल संकलित नहीं हुई। हेडर में घोषित कार्यों के लिए अपरिभाषित संदर्भों के अलावा, लेकिन कार्यान्वित नहीं होने पर, मुझे इन प्रकार की बहुत सी त्रुटियां मिलीं।

समाधान के लिए नई cpp फ़ाइल को संकलित करने और लिंक करने के लिए बिल्ड सिस्टम को फिर से चलाना था।

— Claudiu
स्रोत

3

मेरे मामले में, मैंने हेडर फ़ाइलों और फ़ाइल के साथ एक तृतीय-पक्ष लाइब्रेरी का उपयोग किया। मैंने एक वर्ग को उप-वर्गित किया, और इस तरह की लिंक त्रुटि तब हुई जब मैंने अपने उपवर्ग को तत्काल करने का प्रयास किया।

जैसा कि @sergiy द्वारा उल्लेख किया गया है, यह जानते हुए कि यह 'आरटीआई' की समस्या हो सकती है, मैंने कंस्ट्रक्टर के कार्यान्वयन को अलग .cpp फ़ाइल में डालकर और फ़ाइल में '-fno-rtti' संकलन फ़्लैग लगाकर इसे हल करने में कामयाब रहा । यह अच्छा काम करता है।

जैसा कि मैं अभी भी इस लिंक त्रुटि के आंतरिक के बारे में बिल्कुल स्पष्ट नहीं हूं, मुझे यकीन नहीं है कि मेरा समाधान सामान्य है। हालाँकि, मुझे लगता है कि @francois द्वारा बताए गए एडॉप्टर के तरीके को आजमाने से पहले यह एक शॉट के लायक है। और निश्चित रूप से, यदि सभी स्रोत कोड उपलब्ध हैं (मेरे मामले में नहीं), तो संभव हो तो '-ttti' के साथ फिर से करें।

एक और बात, यदि आप मेरे समाधान का प्रयास करना चाहते हैं, तो अलग फ़ाइल को यथासंभव सरल बनाने का प्रयास करें, और C ++ की कुछ फैंसी विशेषताओं का उपयोग न करें। बढ़ावा देने वाली चीजों पर विशेष ध्यान दें, इसका बहुत कारण rtti पर निर्भर करता है।

— uwydoc
स्रोत

2

जब मेरे इंटरफ़ेस (सभी शुद्ध आभासी कार्यों के साथ) को एक और फ़ंक्शन की आवश्यकता होती है, तो मुझे वही त्रुटि मिली है और मैं इसे "शून्य" करना भूल गया।

मैं था

class ICommProvider { public: /** * @brief If connection is established, it sends the message into the server. * @param[in] msg - message to be send * @return 0 if success, error otherwise */ virtual int vaSend(const std::string &msg) = 0; /** * @brief If connection is established, it is waiting will server response back. * @param[out] msg is the message received from server * @return 0 if success, error otherwise */ virtual int vaReceive(std::string &msg) = 0; virtual int vaSendRaw(const char *buff, int bufflen) = 0; virtual int vaReceiveRaw(char *buff, int bufflen) = 0; /** * @bief Closes current connection (if needed) after serving * @return 0 if success, error otherwise */ virtual int vaClose(); };

अंतिम vaClose आभासी नहीं है इसलिए संकलित नहीं किया गया था कि इसके लिए कार्यान्वयन कहां से प्राप्त करना है और इस तरह भ्रमित हो गया है। मेरा संदेश था:

... TCPClient.o :(? Rodata + 0x38): अपरिभाषित संदर्भ 'ICOMProvider के लिए टाइपिनो' के लिए

से सरल परिवर्तन

virtual int vaClose();

सेवा

virtual int vaClose() = 0;

समस्या को ठीक किया। आशा करता हूँ की ये काम करेगा

— अलेक्स पनियुतिन
स्रोत

1

मैं एक ऐसी स्थिति का सामना करता हूं जो दुर्लभ है, लेकिन इससे अन्य मित्रों को भी ऐसी ही स्थिति में मदद मिल सकती है। मुझे gcc 4.4.7 के साथ एक पुराने सिस्टम पर काम करना है। मुझे c ++ 11 या उपरोक्त समर्थन के साथ कोड संकलित करना है, इसलिए मैं gcc 5.3.0 का नवीनतम संस्करण बनाता हूं। मेरे कोड का निर्माण करते समय और निर्भरता से जोड़ने के लिए यदि निर्भरता पुराने संकलक के साथ निर्मित होती है, तो मुझे 'त्रुटि' के लिए अपरिभाषित संदर्भ मिला, हालांकि मैंने स्पष्ट रूप से -L / path / to / lib -llibname के साथ लिंकिंग पथ को स्पष्ट रूप से परिभाषित किया है। कुछ पैकेज जैसे बूस्ट और प्रॉजेक्ट्स, जो सीमेक के साथ निर्मित होते हैं, आमतौर पर पुराने कंपाइलर का उपयोग करने की प्रवृत्ति होती है, और वे आमतौर पर ऐसी समस्याओं का कारण बनते हैं। आपको यह सुनिश्चित करने के लिए एक लंबा रास्ता तय करना होगा कि वे नए संकलक का उपयोग करें।

— केमिन झोउ
स्रोत

1

मेरे मामले में यह विशुद्ध रूप से एक पुस्तकालय निर्भरता मुद्दा है, भले ही मेरे पास डायनेमिक_कास्ट कॉल हो। मेकफाइल में पर्याप्त निर्भरता जोड़ने के बाद यह समस्या दूर हो गई थी।

— चार्ली
स्रोत

0

जांचें कि आपके आश्रितों को बिना संकलित किया गया था -f-nortti।

कुछ परियोजनाओं के लिए आपको इसे स्पष्ट रूप से सेट करना होगा, जैसे कि RocksDB में:

USE_RTTI=1 make shared_lib -j4

— विटाली इसेव
स्रोत

0

मेरे मामले में यह एक इंटरफ़ेस क्लास में एक वर्चुअल फ़ंक्शन था जिसे शुद्ध वर्चुअल के रूप में परिभाषित नहीं किया गया था।

class IInterface
{
public:
  virtual void Foo() = 0;
}

मैं = 0थोड़ा भूल गया ।

— रोंगटे
स्रोत