वीसी 8 से वीसी 10 - एलएनके2005 त्रुटियां

Question

मैंने हाल ही में विजुअल स्टूडियो 2010 स्थापित किया और मेरे प्रोजेक्ट के लिए समाधान फाइलें उत्पन्न करने के लिए सीएमके का इस्तेमाल किया। इस प्रक्रिया ने पहले वीएस2005 पर ठीक काम किया था।

मुझे जो पहला मुद्दा सामने आया वह नए "चालक रचनाकारों" के कारण था, इसलिए मुझे अपने कोड — मेले से कुछ अंतर्निहित रूपांतरणों को दूर करना पड़ा, जो अब काम करता है।

मेरे वर्तमान स्थिति इस प्रकार है: मैं DLL 1 है, जो केवल कुछ प्रणाली पुस्तकालयों (Kernel32, आदि) और CRT पर निर्भर है, और संकलन कर रहा हूँ DLL 2, जो DLL 1 के लिए लिंक, साथ ही कुछ तृतीय पक्ष पुस्तकालयों।

त्रुटियों मैं की तर्ज पर कर रहे हैं:

DLL1.lib(DLL1.dll) : error LNK2005: "public: __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::~basic_string<char,struct std::char_traits<char>,class std::allocator<char> >(void)" (??1?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@XZ) already defined in objFromDLL2.obj 

यही समस्या वर्णित here प्रतीत होता है।

हालांकि, इस धागे में कुछ भी मेरी समस्या हल नहीं करता है।

• मैंने पुष्टि की है कि दोनों DLL1 और DLL2/एमडी कोड जनरेशन ध्वज के साथ संकलित किया गया है,
• DLL2 लिंक तोड़ो, Glew, और शैतान — मैं मैन्युअल रूप से इन और किसी भी पुस्तकालयों वे निर्भर के सभी कंपाइल किया है पर VC10 के लिए, यह भी साथ/एमडी
• संपादित प्रति this article (जो मेरी समस्या के समान है) के रूप में, मैं std :: कंटेनर से पाने वर्गों में से किसी उदाहरण को हटा दिया है
• संपादित करें मैंने पुष्टि की है कि यह तीसरी पार्टी समस्या नहीं है, क्योंकि मैंने पुस्तकालयों के एक ही सेट का सफलतापूर्वक उपयोग करके एक और परियोजना संकलित की है, हालांकि मैं अभी भी अपनी मूल परियोजना
• संपादित करें संपादित करें मेरे सभी आवश्यक स्थानों में dllexport का उपयोग किया जा रहा है कोड

मुझे क्या याद आ रही है? अगर मुझे और जानकारी प्रदान करने की ज़रूरत है तो कृपया मुझे बताएं और मैं इस प्रश्न को जितना संभव कर सकता हूं उतना संपादित कर दूंगा।

अद्यतन: यह थोड़ी देर हो गया है और मेरे पास अभी भी कोई समाधान नहीं है। मैं टिप्पणियों के जवाबों के साथ प्रश्न अद्यतन कर रहा हूं, और मैं वर्तमान में एक अलग कोडबेस पर काम कर रहा हूं जो काम करता है - मुझे लगता है कि पुराने कोड के लिए पिछली संगतता अंततः सूखने लगी है, और मुझे बस आगे बढ़ो।

अधिक अद्यतन: मैंने पाया क्या शायद एक बहुत ही अवांछनीय लिंकर झंडा,/बल दिया गया है: कई है, जो सभी लेकिन प्रतीकों की पहली परिभाषा की अनदेखी करके चेतावनी में त्रुटियों बदल जाता है। ऐसा करने के खराब दुष्प्रभाव होना चाहिए। इस ध्वज के एक परीक्षण ने एलएनके 2001 को हाइलाइट किया: अनसुलझा std :: string :: npos, जिसे पिछले सभी LNK2005 त्रुटियों में दफनाया गया था। यातना कभी खत्म नहीं होती है।

Answer 1

मुझे लगता है कि आपकी अनुमानित धारणाएं गलत हैं। विशेष रूप से, "डीएलएल 1, जो केवल कुछ सिस्टम पुस्तकालयों (कर्नेल 32, आदि) पर निर्भर है, सही नहीं हो सकता है अगर यह/एमडी के साथ संकलित है और std::string::~string को संदर्भित करता है। यह स्पष्ट रूप से सीआरटी पर निर्भरता का कारण बन जाएगा।

असलो, यदि डीएलएल 1 डीएलएल 2 पर निर्भर नहीं है, तो दुनिया में डीएलएल 2 से फाइलों के बारे में जानकारीकर्ता कैसे है ?! क्या आपने किसी भी मौका से चक्रीय निर्भरता स्थापित करने में कामयाब रहे हैं?

वीएस -2008 और वीएस -2010 के बीच, ऐसा लगता है कि std::string::~string सीआरटी से हटा दिया गया था। इसलिए, यह अब आपके कोड के लिए DLLimport नहीं है। यह व्यवहार में अंतर को समझा सकता है। डीएलएल 1 और डीएलएल 2 के बीच एक चक्रीय निर्भरता std::string::~string पर मेल नहीं खाती क्योंकि दोनों इसे सीआरटी से प्राप्त करेंगे, और जाहिर है कि यह चक्र का हिस्सा नहीं होगा।

Answer 2

ऐसा लगता है कि समस्या यह है कि DLL1 std::string निर्यात करता है (संभवतः, क्योंकि इसका उपयोग उस वर्ग में भी किया जाता है जिसे निर्यात किया जाता है), लेकिन डीएलएल 1 के शीर्षलेख इसे घोषित नहीं करते हैं। इसलिए, जब DLL2 संकलित किया जाता है, तो इसे आयात के रूप में नहीं देखा जाता है। यह कोई समस्या नहीं है, क्योंकि यह एक टेम्पलेट है: संकलक सिर्फ एक और प्रतिलिपि बनाता है। लेकिन फिर लिंकर stumbles, क्योंकि DLL2 वास्तव में std::string आयात किया जाना चाहिए था।

समाधान: std::string स्पष्ट रूप से निर्यात/आयात करें; आपके डीएलएल 1 हेडर में _declspec() के लिए शायद आपके पास पहले से एक उपयुक्त मैक्रो है।

Answer 3

मैंने सफलतापूर्वक /FORCE:MULTIPLE का उपयोग किया है। लाइब्रेरी के मिश्रित बैग का उपयोग करते समय कभी-कभी अपरिहार्य होता है। जब तक लिंकर संदर्भ को लगातार हल करने के लिए एक & समान पता का उपयोग करता है, यह काम करता है। अन्य परिभाषाओं को नजरअंदाज कर दिया जाता है।