🆑 🏰 🏷️ लेआउट, निर्भरता नरक और पिछड़े संगतता के बारे में 🚴🏾 👩‍👧‍👦 😘

यह लेख लेआउट पर एक उच्च-स्तरीय नज़र पर ध्यान केंद्रित करेगा। लिनक्स, बीएसडी *, मैक ओएस एक्स, विंडोज पर साझा पुस्तकालय कहां हैं कि एप्लिकेशन निर्भर करते हैं? पिछड़े अनुकूलता के साथ क्या करना है? नशे की लत से कैसे निपटें नरक?

यह माना जाता है कि पाठक "संकलक", "ऑब्जेक्ट फ़ाइल", "लिंकर", "स्टेटिक लाइब्रेरी", "डायनेमिक लाइब्रेरी", "डायनेमिक लोडर" और कुछ अन्य के रूप में ऐसे चरित्र सेट से परिचित है, इसलिए हम कुछ भी नहीं चबाएंगे।

गतिशील पुस्तकालयों के स्थैतिक लोडिंग की समस्याएँ:

main.exe संस्करण-0.3.dll और bar.dll पर निर्भर करता है। बार, बदले में, संस्करण-0.2.dll पर निर्भर करता है, जो संस्करण 0.3 के साथ द्विआधारी संगत नहीं है (न केवल वर्ण अनुपस्थित हैं, लेकिन नाम संयोग हैं, लेकिन एक अलग संख्या में तर्क हैं, या विभिन्न प्रकृति की वस्तुओं को बनाते हैं, आदि)। संस्करण -1.0.dll से वर्णों को संस्करण-0.3.dll से हटा दिया जाएगा? पुस्तकालय के एक स्थिर संस्करण (जैसे संस्करण-0.2.lib) और डायनामिक (संस्करण-0.3.dll) का उपयोग करते समय एक ही सवाल उठता है;
रोमिंग एप्लिकेशन बनाना: डायनामिक लोडर को वर्जन कहां से दिखेगा। पिछले कोड से एप्लिकेशन के लिए ?.d.dll और bar.dll? यदि यह किसी अन्य फ़ोल्डर में ले जाया जाता है, तो क्या यह main.exe निर्भरता को खोजेगा? Main.exe को कैसे इकट्ठा किया जाए ताकि निष्पादन योग्य के सापेक्ष निर्भरता दिखाई दे?
निर्भरता नरक: एक ही पुस्तकालय के दो संस्करणों /opt/kde3/lib/libkdecore.so और /opt/kde4/lib/libkdecore.so (जिसके साथ प्लाज्मा अब नहीं गिरता है), कार्यक्रमों में से आधे को पहले की आवश्यकता होती है, कार्यक्रमों के दूसरे हिस्से में दूसरे की आवश्यकता होती है। दोनों पुस्तकालयों को एक दायरे (एक निर्देशिका) में नहीं रखा जा सकता है। एक ही समस्या बिंदु 1 में मौजूद है, क्योंकि संस्करण लाइब्रेरी के दो संस्करणों को एक ही निर्देशिका में रखा जाना चाहिए।

पहले पैराग्राफ को पढ़ने के बाद, पाठक यह कह सकते हैं: “हाँ, यह विकृति है! वे ऐसा नहीं करते हैं! पुस्तकालय के एक संस्करण का उपयोग किया जाना चाहिए! ”हाँ, यह है, लेकिन जीवन में सब कुछ होता है। सबसे सरल उदाहरण: आपका एप्लिकेशन लाइब्रेरी का उपयोग करता है, और एक तृतीय-पक्ष बंद पुस्तकालय (मैं इस पर जोर देता हूं, किसी और के भुगतान किए गए उत्पाद ) बी, जो, ठीक है, उसी संस्करण का उपयोग नहीं कर सकता है जैसे कि आप या इसके विपरीत।

एक विशाल परियोजना के ढांचे में एक और उदाहरण तथ्य यह है कि विभिन्न भागों की रिहाई की एक अलग अवधि है (जो हमारी टीम का सामना करना पड़ा और आम तौर पर इस पाठ को किस कारण लिखा गया है)। इस प्रकार, मुख्य उत्पाद समय-समय पर पैरा 1 में वर्णित कॉन्फ़िगरेशन में बाहर आ सकता है।

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

नर्क से बचो

उत्तर सरल है: आपको लाइब्रेरी फ़ाइल नाम के संस्करण को जोड़ना होगा। यह आपको लाइब्रेरी फ़ाइलों को एक निर्देशिका में रखने की अनुमति देगा। इसी समय, यह एपीआई नहीं बल्कि एबीआई संस्करण को जोड़ने की सिफारिश की जाती है, जिससे दो समानांतर संस्करण शाखाएं और इसी तरह की कठिनाइयां पैदा होती हैं।

संस्करण नियंत्रण एक बहुत ही नियमित काम है। Xyz योजना पर विचार करें:

x - प्रमुख मुद्दा। कोई अनुकूलता की बात नहीं है;
y - मामूली समस्या। लिबा स्रोत स्तर संगत है, लेकिन बाइनरी संगतता टूट सकती है;
z बग फिक्स है। लिबा दोनों दिशाओं में संगत है।

फिर फ़ाइल नाम में xy को शामिल करना उचित है। यदि लघु संस्करण को बढ़ाते समय संगतता को संरक्षित किया गया था, तो यह संगत सिमलिंक बनाने के लिए पर्याप्त है:

संस्करण-1.1.dll

संस्करण- 1.0.dll → संस्करण- 1.1.dll

संस्करण -१.०.० और संस्करण -१.०.x का उपयोग करने वाले दोनों अनुप्रयोग काम करेंगे।

यदि संगतता टूट गई है, तो सिस्टम में दो फाइलें होंगी और फिर से सब कुछ काम करेगा।

यदि, किसी कारण से, बग फिक्स के दौरान संगतता टूट गई थी, तो लघु संस्करण को बढ़ाया जाना चाहिए (और असफल होने के लिए कुछ भी नहीं है, जैसा कि पसंदीदा क्यूटी की टीम ने किया था। ^[१] )।

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

यह सभी प्लेटफार्मों के लिए सही है।

शेष दो मुद्दों का समाधान ओएस पर निर्भर करता है।

ELF और GNU ld (लिनक्स, * बीएसडी, आदि)

ELF प्रारूप की साझा लाइब्रेरी में तथाकथित SONAME है ^[2] ^[३] । यह एक वर्ण स्ट्रिंग है जो DT_SONAME अनुभाग में बाइनरी फ़ाइल को लिखा जाता है। आप एक पुस्तकालय के लिए उदाहरण के लिए SONAME देख सकते हैं, जैसे:

$ objdump -p /path/to/file | grep SONAME

यदि फ़ैज़ प्रोग्राम / लाइब्रेरी baz लाइब्रेरी को बांधता है, जिसमें SONAME = baz-0.dll है , तो लाइन baz-0.dll को DT_NEEDED सेक्शन में बाइनरी फ़ैज़ फ़ाइल में हार्डकोड किया जाएगा, और जब यह शुरू होता है, तो डायनेमिक लोडर baz नामक फ़ाइल की तलाश करेगा -0.dll इस मामले में, कोई भी फ़ाइल को अलग तरीके से नाम देने के लिए मना नहीं करता है!

आप उन SONAME को देख सकते हैं जिन पर निष्पादन योग्य निर्भर करता है:

 $ objdump -x /path/to/file | grep NEEDED

डायनेमिक लोडर इस क्रम में निम्नलिखित स्थानों में DT_NEEDED अनुभाग से पुस्तकालयों की खोज करता है ^[4] ^[५] :

DT_RPATH अनुभाग में निर्देशिकाओं की एक सूची, जो निष्पादन योग्य फ़ाइल में हार्डकोड है। अधिकांश * निक्स सिस्टम द्वारा समर्थित। उपेक्षित अगर धारा DT_RUNPATH मौजूद है;
LD_LIBRARY_PATH - पर्यावरण चर, निर्देशिका की एक सूची भी शामिल है;
DT_RUNPATH - DT_RPATH के समान, केवल LD_LIBRARY_PATH के बाद देखी गई। केवल नवीनतम यूनिक्स जैसी प्रणालियों पर समर्थित;
/etc/ld.so.conf - डायनेमिक लोडर ld.so के लिए कॉन्फ़िगरेशन फ़ाइल, जिसमें पुस्तकालयों के साथ फ़ोल्डर्स की एक सूची है;
हार्ड-वायर्ड पथ - आमतौर पर / देय और / usr / lib।

RPATH, LD_LIBRARY_PATH और RUNPATH का डेटा प्रारूप पथ के लिए समान है: पथों की एक बृहदान्त्र पृथक सूची। आप उदाहरण के लिए, RUNPATHs देख सकते हैं:

 $ objdump -x /path/to/file | egrep 'R(|UN)PATH'

[UN] PATH में एक विशेष लेबल $ ORIGIN हो सकता है, जिसे लोड करने वाली इकाई को पूर्ण निरपेक्ष पथ पर डायनामिक लोडर तैनात करेगा। यहां यह ध्यान देने योग्य है कि कुछ डेवलपर्स RUNPATH में "" (अवधि) जोड़ते हैं। यह $ ORIGIN जैसा नहीं है! बिंदु वर्तमान कामकाजी निर्देशिका में विस्तार करेगा, जो स्वाभाविक रूप से सार के मार्ग के साथ मेल नहीं खाता है!

जो लिखा गया है, उसे प्रदर्शित करने के लिए, हम पी 1 से योजना के अनुसार एप्लिकेशन विकसित करेंगे ( जीथब में भंडारण के लिए लिंक: github.com/gshep/linking-sample )। पूरे सिस्टम का निर्माण करने के लिए, बस फ़ोल्डर की जड़ में जाएं और कॉल करें ./linux_make_good.sh

, result

फ़ोल्डर में होगा। कुछ विधानसभा चरणों पर नीचे चर्चा की जाएगी।

संस्करण- 0.x पुस्तकालयों को जोड़ने के चरण में, SONAME सेट हैं:

 $ gcc -shared -Wl,-soname,version-0.3.dll -o version-0.3.dll version.o

वे केवल सिस्टम लाइब्रेरी पर निर्भर हैं और इसलिए R [UN] PATH अनुभागों की आवश्यकता नहीं है।

बार लाइब्रेरी पहले से ही संस्करण 0.2 पर निर्भर है, इसलिए आपको RPATH को निर्दिष्ट करने की आवश्यकता है:

 $ gcc -shared -Wl,-rpath-link,/path/to/version-0.2/ -L/path/to/version-0.2/ -l:version-0.2.dll -Wl,-rpath,\$ORIGIN/ -Wl,--enable-new-dtags -Wl,-soname,bar.dll -o bar.dll bar.o

--enable-new-dtags

लिंकर को DT_RUNPATH अनुभाग भरने के लिए कहता है।

-Wl,-rpath,...

R [UN] PATH अनुभाग को भरता है। रास्तों की सूची निर्दिष्ट करने के लिए, आप कई बार पैरामीटर निर्दिष्ट कर सकते हैं, या एक बृहदान्त्र के माध्यम से सभी पथों को सूचीबद्ध कर सकते हैं:

 $ gcc -Wl,-rpath,/path/1/ -Wl,-rpath,/path/2 ... $ gcc -Wl,-rpath,/path/1:/path/2 ...

अब परिणाम फ़ोल्डर या संपूर्ण फ़ोल्डर की संपूर्ण सामग्री को फ़ाइल सिस्टम के चारों ओर ले जाया जा सकता है, जैसा कि आप चाहते हैं, लेकिन जब आप डायनेमिक लोडर शुरू करते हैं तो सभी निर्भरताएँ मिलेंगी और प्रोग्राम निष्पादित होगा:

 $ ./result/main.exe Hello World! bar library uses libversion 0.3.0, number = 3 version::get_version result = 0 But I uses liversion 0.3.0 number = 3

इसलिए हम पात्रों को समेटने की समस्या पर आते हैं! Bar संस्करण-0.2.dll का उपयोग करता है, जिसमें get_number (2) रिटर्न देता है, और एप्लिकेशन संस्करण-0.3.dll, जहां एक ही फ़ंक्शन पहले से ही लौटता है। 3. अनुप्रयोग के आउटपुट के अनुसार, get_number फ़ंक्शन का एक संस्करण दूसरे से अधिलेखित है।

तथ्य है ^[6; ^{डायनेमिक लिंकिंग और लोडिंग, डायनेमिक लिंकिंग एप्रोच की तुलना]} कि GNU ld & ELF सोनम या फ़ाइल नाम का उपयोग आयातित वर्णों के लिए एक नामस्थान के रूप में नहीं करता है:

यदि विभिन्न पुस्तकालय समान नामों के साथ संस्थाओं को निर्यात करते हैं, तो उनमें से कुछ दूसरों को पीस लेंगे और सबसे अच्छी स्थिति में कार्यक्रम दुर्घटनाग्रस्त हो जाएगा।

मामला जब पुस्तकालयों में से एक स्थिर है तो बस हल किया जाता है: स्थैतिक पुस्तकालय के सभी प्रतीकों को छिपाना होगा ^{[Def.२, २.२.२ वैश्विक स्थिरता को परिभाषित करें]} ।

दुर्भाग्य से, गतिशील पुस्तकालयों के मामले में, चीजें इतनी सरल नहीं हैं। GNU लिंकर / लोडर में डायरेक्ट बाइंडिंग जैसी कार्यक्षमता का अभाव है ^[]] । किसी ने गेन्ट में इस अवसर को देखा ^[९] लेकिन लगता है कि सब कुछ खत्म हो गया। डीजल ईंधन में वह है ^[10] ^[११] लेकिन सोलेयार्का की मृत्यु हो गई ...

एक विकल्प यह है कि पात्रों को स्वयं ही संस्करणित किया जाए ^{[Use, २.२.५ एक्सपोर्ट मैप का उपयोग करें]} । यह वास्तव में सजाने वाले पात्रों की तरह है। (आप केवल कल्पना कर सकते हैं कि C ++ में एक पाठक प्रोग्रामिंग अब क्या चिल्ला रहा है ...)

इस पद्धति में एक तथाकथित संस्करण लिपि तैयार करना शामिल है जिसमें सभी निर्यात और छिपी हुई संस्थाओं को सूचीबद्ध करना है ^[12] ^[१३] । संस्करण -1.5 से उदाहरण लिपि:

  VERSION_0.3 {
     वैश्विक:
         get_version;
         get_version2;
         get_number;
     स्थानीय:
         *;
 };

बिल्ड स्टेज पर, --version-script=/path/to/version.script

पैरामीटर का उपयोग करके इस फाइल को निर्दिष्ट करें। उसके बाद, इस तरह के एक काम के साथ जुड़ा हुआ एप्लिकेशन को एनईईडीईडी में संस्करण -०.०.५५ मिलेगा, और आयात तालिका में अपरिभाषित चरित्र get_number@@VERSION_0.3

प्राप्त होगा, हालांकि int get_number () अभी भी हेडर फ़ाइलों में होगा।

Glibc का उपयोग करने वाले किसी भी प्रोग्राम पर nm सेट करें, और आप स्पष्ट रूप से देखेंगे!

संस्करण 0.x पुस्तकालयों में संस्करण वर्णों का उपयोग करके एक उदाहरण बनाने के लिए, linux_make_good.sh

रूट स्क्रिप्ट का use_version_script

पैरामीटर के साथ करें:

 $ ./linux_make_good.sh use_version_script $ ./result/main.exe Hello World! bar library uses libversion 0.2.0, number = 2 version::get_version result = 0 But I uses liversion 0.3.0 number = 3 $ nm ./result/main.exe // … U get_number@@VERSION_0.3 U get_version@@VERSION_0.3 0000000000401008 T main U memset@@GLIBC_2.2.5 $ nm ./result/bar.dll // … U get_number@@VERSION_0.2 U get_version2@@VERSION_0.2 0000000000000800 t register_tm_clones U strcat@@GLIBC_2.2.5

अरे डार्ट! हमारे libX लिनक्स का समर्थन करेंगे!
Noooooooooooooooooooooooooo!

हां, हमारी टीम का सामना करने वाले झगड़े के बाद, कप्तान ने एक मजबूत इरादों वाला फैसला किया और अब केवल एक संस्करण का उपयोग किया जाता है (ठीक लिनक्स के कारण)।

मैक पर चीजें कैसी हैं?

मैक एक्सिस निष्पादन योग्य फ़ाइलों के लिए, और दो-स्तरीय नामस्थान वर्णों की खोज के लिए Mach-o प्रारूप का उपयोग करता है ^{[१४, दो-स्तरीय नामस्थान]} ^[१६] । यह अब डिफ़ॉल्ट रूप से है, लेकिन आप इसे एक फ्लैट नेमस्पेस के साथ बना सकते हैं या प्रोग्राम स्टार्टअप पर पूरी तरह से अक्षम कर सकते हैं ^{[१५, FORCE_FLAT_NAMESPACE]} । कमांड आपको यह पता लगाने में मदद करेगी कि क्या नाम स्थान समर्थन के साथ एक द्विआधारी बनाया गया है:

 $ otool -hv /path/to/binary/file

यही है, आपको नामों के किसी भी अतिरिक्त सजावट के साथ स्नान करने की आवश्यकता नहीं है - बस फ़ाइल नाम में संस्करण शामिल करें!

लेकिन निर्भरता खोज के बारे में क्या?

Makoshi में, लगभग सब कुछ समान है, केवल इसे अलग तरीके से कहा जाता है।

SONAME के बजाय एक पुस्तकालय id या संस्थापित नाम है। उदाहरण के लिए, आप इसे देख सकते हैं:

 $ otool -D /usr/lib/libstdc++.dylib

आप install_name_tool का उपयोग करके बदल सकते हैं।

किसी लाइब्रेरी से लिंक करते समय, उसकी आईडी बाइनरी में लिखी होती है।

आप द्विआधारी निर्भरता इस प्रकार देख सकते हैं:

 $ otool -L /path/to/main.exe

या

 $ dyldinfo -dylibs /path/to/main.exe

शुरू करते समय, डाइल्ड "आईडी" नामक एक फ़ाइल खोलने की कोशिश करता है ^{[१५, डायनामिक लिब्ररी ट्रेडिंग]} , जो स्थापित नाम को निर्भरता के लिए एक निरपेक्ष पथ के रूप में मानता है। यदि यह विफल हो जाता है, तो यह पर्यावरण चर DYLD_LIBRARY_PATH (LD_LIBRARY_PATH का पूर्ण एनालॉग) में सूचीबद्ध निर्देशिकाओं में नाम / प्रत्यय "आईडी" के साथ फ़ाइल खोजता है।

यदि DYLD_LIBRARY_PATH में खोज के परिणाम वापस नहीं आए, तो डाइल्ड इसी तरह एक जोड़े को अधिक पर्यावरण चर में देखता है ^[१५] , इसके बाद यह मानक कैटलॉग में खोज करता है।

यह योजना आपको रोमिंग एप्लिकेशन एकत्र करने की अनुमति नहीं देती है, इसलिए एक विशेष लेबल पेश किया गया था, जिसे आईडी में लिखा जा सकता है: @ निष्पादन योग्य_थानाथ /। बूट समय पर यह चिह्न निष्पादन योग्य फ़ाइल के लिए एक निरपेक्ष पथ पर विस्तारित किया जाएगा।

अगला, आप समाप्त बाइनरी की निर्भरता बदल सकते हैं:

 $ install_name_tool -change /usr/lib/libstdc++.dylib @executable_path/libstdc++.dylib main.exe

अब लोडर सबसे पहले main.exe के समान फ़ोल्डर में इसके लिए खोज करेगा। समाप्त बाइनरी में नहीं बदलने के लिए, आपको libstdc ++ को स्लिप करना होगा। Dylib lib with id = @ निष्पादन योग्य_path / libstdc ++। लिंक करने के दौरान Dylib।

इसके अलावा, एक समस्या उत्पन्न होती है, या दो के बजाय। इस तरह के पदानुक्रम होने दें:

main.bin
उपकरण /
- auxiliary.bin
library.dll

main.bin Library.dll पर निर्भर करता है, लेकिन उपकरण / सहायक.बिन भी इस पर निर्भर करता है।

उसी समय, आईडी = @ निष्पादन योग्य_पाठ / पुस्तकालय.डाल, और दोनों बायनेरिज़ बस इसे से जुड़े थे। फिर, जब असिस्टेंट शुरू कर रहा हो ।bin, बूटलोडर /path/to/tools/library.dll की तलाश करेगा और स्वाभाविक रूप से इसे नहीं मिलेगा! बेशक, आप लिंक को नरम करने या फेंकने के बाद कलमों के साथ उपकरण / सहायक.बिन को सही कर सकते हैं, लेकिन फिर से असुविधा!

बेहतर तब भी, जब प्लगइन्स की बात आती है, तो समस्या स्वयं प्रकट होती है:

main.bin
प्लगइन /
- 1.plugin
- helper.dylib

1.plugin में एंट्री @ execable_path / helper.dylib है, लेकिन स्टार्टअप में यह main.bin के निरपेक्ष पथ तक विस्तृत होगा, न कि 1.plugin!

इस समस्या को हल करने के लिए, एक्सिस 10.4 से याब्लो लोगों ने एक नया मार्कर पेश किया: @ लोडर_पैथ /। निर्भरता लोडिंग के दौरान, यह मार्कर बाइनरी के पूर्ण पथ तक विस्तार करेगा जो निर्भरता को खींचता है।

आखिरी कठिनाई यह है कि आपको लिंक किए गए पुस्तकालयों के दो संस्करणों की आवश्यकता है: कुछ सिस्टम पर इंस्टॉल किए जाएंगे और आईडी = /usr/lib/libfoo.dylib होगा, जबकि अन्य का उपयोग प्रोजेक्ट बनाने के लिए किया जाता है और उनकी आईडी = @ लोडर -path / libfoo.dylib। यह install_name_tool के साथ हल करना आसान है, लेकिन थकाऊ; इसलिए, संस्करण 10.5 से, उन्होंने @ rpath / लेबल दर्ज किया। पुस्तकालय id = @ rpath / libfoo.dylib के साथ बनाया गया है और कहीं भी कॉपी किया गया है। बाइनरी निर्भरताओं की तलाश के लिए रास्तों की एक सूची के साथ संकलित की जाती है, जिसमें @ {निष्पादन योग्य, लोडर} _path / अनुमति दी जाती है:

 $ gcc ... -Xlinker -rpath -Xlinker '@executable_path/libs' -Xlinker -rpath -Xlinker '/usr/lib' ...

यह ELF के लिए RPATH / RUNPATH के समान है। जब द्विआधारी शुरू होता है, तो लाइन @ rpath / libfoo.dylib को @ निष्पादन योग्य_पथ / libs / libfoo.dylib तक विस्तारित किया जाएगा, जो पहले से ही एक निरपेक्ष पथ तक विस्तारित होगा। या /usr/lib/libfoo.dylib पर तैनात हैं।

आप बाइनरी को वायर्ड rpaths निम्नानुसार देख सकते हैं:

 $ otool -l main.bin | grep -A 2 -i lc_rpath

आप install_name_tool का उपयोग करके rpaths को हटा, संशोधित या जोड़ सकते हैं।

एक उदाहरण पर जाँच करें:

 $ ./macosx_make_good.sh Building version-0.2 Building version-0.3 Building bar Building fooapp $ ./result/main.exe Hello World! bar library uses libversion 0.2.0, number = 2 version::get_version result = 0 But I uses liversion 0.3.0 number = 3

IOS पर, सब कुछ समान है।

जैसा कि आप उदाहरण से देख सकते हैं, गतिशील पुस्तकालयों के मामले में मैक ओएस एक्स लिनक्स एंड कंपनी से बेहतर है।

और अंत में, विंडोज!

यहां भी सब ठीक है ^[6; ^{डायनेमिक लिंकिंग और लोडिंग, डायनेमिक लिंकिंग अप्रोच की तुलना]} । आपको बस फ़ाइल नाम के लिए संस्करण जोड़ना होगा और ... कोई सहानुभूति नहीं! यही है, वे हैं, लेकिन कई लोग उनके बारे में शिकायत करते हैं और वे केवल NTFS पर काम करते हैं ~~(विंडोज एक्सपी निश्चित रूप से एफएटी विभाजन पर स्थापित किया जा सकता है)~~ । इसलिए, पिछड़े संगतता डिस्क स्थान की एक सभ्य राशि खर्च कर सकते हैं ... ठीक है, ठीक है। )

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

 > .\windows_make_good.bat // ... >.\result\main.exe Hello World! bar library uses libversion 0.2.0, number = 2 version::get_version result = 0 But I uses liversion 0.3.0 number = 3

झूठ बोलने के बाद ही मांगा जाता है। ^[१]] । निर्भरता खोज एल्गोरिथ्म को बदलने का एक संभावित तरीका एप्लिकेशन कॉन्फ़िगरेशन फ़ाइल और प्रोबिंग की प्राइवेटपैथ संपत्ति का उपयोग करना है ^[१]] । हालाँकि, यह विधि केवल विंडोज 7 / सर्वर 2008 R2 से शुरू होती है।

और वहाँ WinSxS और तथाकथित विधानसभाओं (विधानसभाओं) ^{[१ ९]} । यह एक अलग लेख का विषय है। हालाँकि, जब यह लेख लिखा जा रहा था, तो यह समझ और समझ कि इन असेंबलीज़ की आवश्यकता केवल (कम से कम Sishniki और C ++ उपनामों के लिए) थी, यह सुनिश्चित करने के लिए कि सभी एप्लिकेशन के साथ जुड़े हुए थे, कहते हैं, comdlg32.dll, लेकिन सभी अलग-अलग संस्करणों को कम कर दिया गया था।

निष्कर्ष

सभी प्रमुख प्लेटफ़ॉर्म उन अनुप्रयोगों को बनाने में अपेक्षाकृत आसान बनाते हैं जिन्हें नियमित रूप से कॉपी करके स्थापित किया जा सकता है। हालांकि, डेवलपर्स को अपने दम पर निर्भरता नरक, पिछड़े संगतता, और चरित्र की समस्याओं को हल करना होगा।

मुख्य निर्णय सही संस्करण का चयन करना और उस पर नियंत्रण करना है।

जबकि ~~क्यूरियोसिटी ने मार्टियन खुले स्थानों की प्रतिज्ञा की,~~ लेखक ने यहां यह बताने की कोशिश की कि ओवरराइटिंग के पात्रों से कैसे बचा जाए, लंबे समय से हब पर लेख हैं जो आपको बताते हैं कि विशेष रूप से विपरीत कैसे प्राप्त करें: habrahabr.ru/post/106107 , habrahabr.ru/post/ 115558 है ।

पुनश्च जब इस लेख पर काम किया जा रहा था, तब लेखक ने "ऑन स्ट्राइक!" सम्मेलन में भाग लिया, जहाँ उन्होंने पैवेल्स के। नाज़रोव की एक रिपोर्ट को संस्करण के रूप में सुना। ^[२०] वहाँ कुछ भी अप्रत्याशित या असामान्य नहीं था, लेकिन यह सुनकर अच्छा लगा कि इस तरह की एक प्रसिद्ध कंपनी ने समस्या का एहसास किया और सही निष्कर्ष बनाया। खुद के लिए एक नए लेख से, लेखक ने वहां से एक लिंक बनाया: semver.org ।

मैं अपने सहयोगियों अलेक्जेंडर सिदोरोव और अलेक्जेंडर प्रोकोफीव को रचनात्मक आलोचना और मूल्यवान टिप्पणियों के लिए धन्यवाद करने का अवसर लेता हूं!

संदर्भ

^ QtMultimedia परिवर्तन-5.0.1
^ http://en.wikipedia.org/wiki/Soname
^ प्रोग्राम लाइब्रेरी HOWTO, 3.1.1। साझा लाइब्रेरी नाम ।
^ आदमी ld-linux.so
^ http://en.wikipedia.org/wiki/Rpath
जॉन आर लेविन, http://www.iecc.com/linker/ द्वारा 1 2 लिंकर्स और लोडर।
^ 1 2 उलरिच ड्रेपर द्वारा साझा लाइब्रेरी कैसे लिखें, http://www.akkadia.org/drepper/dsohowto.pdf (pdf)।
^ http://en.wikipedia.org/wiki/Direct_binding
^ https://bugs.gentoo.org/show_bug.cgi?id=114008
^ https://blogs.oracle.com/msw/date/2005050614
^ http://cryptonector.com/2012/02/dll-hell-on-linux-but-not-solaris/ ।
^ https://sourceware.org/binutils/docs/ld/VERSION.html
^ http://www.tux.org/pub/tux/eric/elf/docs/GNUvers.txt
^ आदमी ld।
^ 1 2 3 मैन डाइल्ड।
^ http://en.wikipedia.org/wiki/Mach-O#Mach-O_file_layout
^ MSDN, डायनेमिक-लिंक लाइब्रेरी सर्च ऑर्डर, http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx ।
^ http://stackoverflow.com/a/10390305/1758733
^ http://en.wikipedia.org/wiki/WinSXS
^ नाज़रोव के।, वर्ज़निंग सॉफ्टवेयर उत्पादों पर अत्यधिक पक्षपाती नज़र, http://nastachku.ru/lectures#lecture_178 ।
ओरेकल, लिंकर और लाइब्रेरी गाइड, http://docs.oracle.com/cd/E19683-01/817-1983/index.html ।
लिंकर के लिए शुरुआती गाइड, http://habrahabr.ru/post/150327/ ।

लेआउट, निर्भरता नरक और पिछड़े संगतता के बारे में