एक ही प्रक्रिया में एक ही (बूस्ट) डीएलएल के कई संस्करण सह-अस्तित्व में मौजूद हो सकते हैं?

Question

मेरा (सी ++, क्रॉस-प्लेटफ़ॉर्म) ऐप Boost लाइब्रेरीज़ (संस्करण 1.x कहता है) का भारी उपयोग कर रहा है, और मैं Boost (लेकिन संस्करण का उपयोग कर स्वयं तृतीय पक्ष (विक्रेता) के एसडीके (कोई स्रोत) के खिलाफ भी लिंक करना चाहता हूं (लेकिन संस्करण 1.y)।

तो, हम दोनों Boost डीएलएल के अपने संस्करण के मुकाबले गतिशील रूप से लिंक करते हैं, सीआरटी समान है। नतीजतन, रन-टाइम पर मेरे ऐप को Boost 1.x & 1.y दोनों डीएलएल लोड करना होगा।

संभावित समस्याएं & गॉथस संबंधित हैं?

मैं विक्रेता के एसडीके को नहीं बदल सकता, लेकिन मैं अपना ऐप बदल सकता हूं। शायद मुझे अपने Boost 1.x के खिलाफ स्थिर रूप से लिंक करने का प्रयास करना चाहिए?

पीएस: Boost के डीएलएल का नाम उनके संस्करण में शामिल है, इसलिए कोई नाम टकराव नहीं है, दोनों पहचान योग्य हैं। सामान्य डीएलएल-नरक नहीं।

Answer 1

यदि आप foo फ़ंक्शन लिखते हैं, और इसे F.dll से निर्यात करते हैं, और एक अन्य फ़ंक्शन foo G.dll से निर्यात किया गया है, तो क्या आप समस्याओं की अपेक्षा करेंगे?

जब AF.exe लिंक होता है, तो लिंकर को बताया जाता है: वहां कुछ कोड डालें जो F.dll से foo फ़ंक्शन का पता लोड करता है। अब BG.dll को G.dll से foo पता पुनर्प्राप्त करने के लिए जोड़ा गया है। मुझे अभी भी कोई समस्या नहीं है।

अब अपने ऐप के साथ AF.exe को बदलें, अपने विक्रेता के ऐप के साथ BG.dll, अपने बूस्ट संस्करण के साथ F.dll, विक्रेता के बूस्ट संस्करण के साथ G.dll।

निष्कर्ष: यदि डीएल नाम अलग हैं तो मुझे कोई समस्या नहीं दिखती है।

Answer 2

जहां तक ​​विभिन्न संस्करणों के लिए डीएलएल का उपयोग करना कोई समस्या नहीं होनी चाहिए। कम से कम विंडोज पर नहीं।

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

Answer 3

यह एक बड़ी समस्या है। डीएलएल नरक पर एक खोज करें।

मूल रूप से डीएलएल (या लिनक्स में साझा libs) लोड हो जाते हैं लेकिन सभी नाम लोड समय पर हल नहीं होते हैं। क्या होता है आलसी मूल्यांकन, इसलिए नामों का पहले उपयोग पर मूल्यांकन किया जाता है। समस्या यह है कि यदि 2 डीएल का एक ही नाम है तो उस स्थान पर जहां नाम हल किया गया है, उस पर निर्भर करता है कि डीएलएल किस क्रम में खोजा गया है (जो लोड ऑर्डर पर निर्भर करता है)।

यदि आप स्थिर रूप से लिंक करते हैं तो आपको विधि कॉल के साथ समस्या नहीं होगी क्योंकि आपका संकलन समय पर हल हो जाएगा और तीसरे पक्ष को डीएलएल से रनटाइम पर हल किया जाएगा। लेकिन संस्करण -1 बूस्ट द्वारा बनाई गई संरचनाओं के बारे में क्या। यदि आप इन्हें तीसरी पार्टी लाइब्रेरी में पास करते हैं जो इसे संस्करण-एक्स बूस्ट में भेज देता है। क्या संरचनाएं उसी तरह से बाहर रखी गई हैं?

यह एक बहुत मुश्किल क्षेत्र है और जब समस्याएं डी-बग के लिए बहुत कठिन होती हैं। तो उसी संस्करण का प्रयास करें और उपयोग करें।