निर्भरता के साथ गतिशील पुस्तकालय के साथ जोड़ना

Question 1

इस परिदृश्य पर विचार करें:

साझा पुस्तकालय libA.so, कोई निर्भरता के साथ।
साझा पुस्तकालय libB.so, libA.so के साथ इसकी निर्भरता के रूप में।

मैं एक बाइनरी फ़ाइल संकलित करना चाहता हूं जो कि libB के साथ लिंक करती है। क्या मुझे बाइनरी को केवल libB के साथ या liba के साथ जोड़ना चाहिए?

क्या केवल प्रत्यक्ष निर्भरता के साथ लिंक करने का कोई तरीका है, जिससे रनटाइम के लिए निर्भरता से अनसुलझे प्रतीकों का समाधान हो सके?

मैं इस तथ्य के बारे में चिंतित हूं कि भविष्य में पुस्तकालय libB कार्यान्वयन बदल सकता है, उदाहरण के लिए अन्य निर्भरताएं (libC, libD, libE)। क्या मुझे इससे कोई समस्या है?

दूसरे शब्दों में:

libA फ़ाइलें: a.cpp आह
libB फाइलें: b.cpp bh
मुख्य कार्यक्रम की फाइलें: main.cpp

बेशक, b.cpp में आह शामिल है और main.cpp में bh शामिल है

संकलन आदेश:

g++ -fPIC a.cpp -c
g++ -shared -o libA.so a.o

g++ -fPIC b.cpp -c -I.
g++ -shared -o libB.so b.o -L. -lA

मुझे किस विकल्प का उपयोग करना चाहिए?

g++ main.cpp -o main -I. -L. -lB

या

g++ main.cpp -o main -I. -L. -lB -lA

मैं पहले विकल्प का उपयोग नहीं कर सका। लिंकर पुस्तकालय लायब्रेरी से अनसुलझे प्रतीकों के बारे में शिकायत करता है। लेकिन यह मुझे थोड़ा अजीब लगता है।

बहुत बहुत धन्यवाद।

- अद्यतित टिप्पणियाँ:

जब मैं बाइनरी लिंक करता हूं, तो लिंकर मुख्य और libB से सभी प्रतीकों को हल करने का प्रयास करेगा। हालांकि, libB ने liba से अपरिभाषित प्रतीक हैं। इसलिए लिंकर उस बारे में शिकायत करता है।

इसलिए मुझे लिबास से भी जुड़ना होगा। हालाँकि मुझे साझा पुस्तकालयों से अनसुलझे प्रतीकों को अनदेखा करने का एक तरीका मिला। ऐसा लगता है कि मुझे निम्नलिखित कमांड लाइन का उपयोग करना चाहिए:

g++ main.cpp -o main -I. -L. -lB -Wl,-unresolved-symbols=ignore-in-shared-libs

ऐसा लगता है कि -rpathविकल्प का उपयोग करना अभी भी संभव है । हालांकि मुझे इसे थोड़ा बेहतर समझने की जरूरत है।

क्या कोई -Wl,-unresolved-symbols=ignore-in-shared-libsविकल्प का उपयोग करते समय किसी भी संभावित नुकसान को जानता है?

- अपडेट किया गया 2:

-rpathइस उद्देश्य के लिए उपयोग नहीं किया जाना चाहिए। किसी दिए गए डायरेक्टरी में लाइब्रेरी को खोजने के लिए बाध्य करना उपयोगी है। -unresolved-symbolदृष्टिकोण बहुत बेहतर लग रहा है।

एक बार फिर धन्यवाद।

Question 2

ऐसा लगता है कि आप पहले से ही वहां सबसे ज्यादा हैं। अच्छी तरह से अपनी जांच के साथ किया। देखते हैं कि क्या मैं इसके पीछे 'क्यों' को स्पष्ट करने में मदद कर सकता हूं।

यहाँ लिंकर क्या कर रहा है। जब आप अपने निष्पादन योग्य ('मुख्य' को ऊपर) से जोड़ते हैं तो इसमें कुछ चिन्ह (कार्य और अन्य चीजें) होते हैं जो अनसुलझे होते हैं। यह उन पुस्तकालयों की सूची को देखेगा, जो अनसुलझे प्रतीकों को सुलझाने की कोशिश कर रहे हैं। साथ ही, यह पाता है कि कुछ प्रतीकों को libB.so द्वारा प्रदान किया गया है, इसलिए यह नोट करता है कि वे अब इस पुस्तकालय द्वारा हल किए गए हैं।

हालांकि, यह भी पता चलता है कि उन प्रतीकों में से कुछ अन्य प्रतीकों का उपयोग करते हैं जो अभी तक आपके निष्पादन योग्य में हल नहीं किए गए हैं, इसलिए इसे अब उन लोगों को भी हल करने की आवश्यकता है। LibA.so के खिलाफ लिंक के बिना, आपका आवेदन अधूरा होगा। एक बार जब यह libA.so के खिलाफ लिंक हो जाता है, तो सभी प्रतीकों को हल कर दिया जाता है और लिंकिंग पूरा हो जाता है।

जैसा कि आपने देखा, का उपयोग -unresolved-symbols-in-shared-libs, समस्या को ठीक नहीं करता है। यह सिर्फ इतना है कि उन प्रतीकों को चलाने के समय में हल कर रहे हैं की रक्षा करता है। इसके लिए यही -rpathहै: पुस्तकालयों को चलाने के लिए निर्दिष्ट किया जाए। यदि उन प्रतीकों को हल नहीं किया जा सकता है, तो आपका ऐप शुरू करने में विफल रहेगा।

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

इस प्रक्रिया का एक और विवरण यहां दिया गया है: क्यों जिस क्रम में पुस्तकालयों को जोड़ा जाता है वह क्रम कभी-कभी जीसीसी में त्रुटियों का कारण बनता है?

Question 3

केवल प्रत्यक्ष निर्भरता के साथ डायनामिक लिंकिंग के लिए आप बाद-Wl,--as-needed में लिबास जोड़ने के साथ उपयोग कर सकते हैं : -Wl,--as-needed

gcc main.c -o main -I. -L. -Wl,--as-needed -lB -lA

प्रत्यक्ष निर्भरता की जाँच करने के लिए आपको ldd के बजाय readelf का उपयोग करना चाहिए क्योंकि ldd भी अप्रत्यक्ष निर्भरता को दर्शाता है।

$ readelf -d main | grep library
0x0000000000000001 (NEEDED)             Shared library: [libB.so]
0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

ldd भी अप्रत्यक्ष निर्भरता दिखाता है:

$ LD_LIBRARY_PATH=. ldd ./main
linux-vdso.so.1 (0x00007fff13717000)
libB.so => ./libB.so (0x00007fb6738ed000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb6734ea000)
libA.so => ./libA.so (0x00007fb6732e8000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb673af0000)

यदि आप cmake का उपयोग करते हैं , तो आप केवल प्रत्यक्ष निर्भरता को शामिल करने के लिए निम्नलिखित पंक्तियों को जोड़ सकते हैं:

set(CMAKE_EXE_LINKER_FLAGS    "-Wl,--as-needed ${CMAKE_EXE_LINKER_FLAGS}")
set(CMAKE_SHARED_LINKER_FLAGS "-Wl,--as-needed ${CMAKE_SHARED_LINKER_FLAGS}")

Question 4

एक अन्य विकल्प का उपयोग करना है libtool

यदि आप g++कॉल को बदलते हैंlibtool --mode=compile g++ स्रोत कोड को संकलित करने और फिर libtool --mode=link g++एप्लिकेशन को बंद लिएlibB , तो libAस्वचालित रूप से लिंक हो जाएगा।

Question 5

यह एक दिलचस्प पोस्ट है - मैं इसके साथ ही अपना सिर पीट रहा था, लेकिन मुझे लगता है कि आप यहां एक बिंदु याद करते हैं।

विचार इस प्रकार है, है ना?

main.cpp =(depends)=> libB.so =(depends)=> libA.so

आइए आगे विचार करें कि ।।

A.cpp (और केवल वहाँ) में आप एक वर्ग / चर को परिभाषित करते हैं, इसे "सिमा" कहते हैं
B.cpp (और केवल वहाँ) में आप एक वर्ग / चर को परिभाषित करते हैं, इसे "सिम्ब" कहते हैं।
सिंबल सिम्मा का उपयोग करता है
main.cpp सिम का उपयोग करता है

अब, libB.so और libA.so को ऊपर वर्णित के अनुसार संकलित किया गया है। उसके बाद, आपका पहला विकल्प काम करना चाहिए , अर्थात:

g++ main.cpp -o main -I. -L. -lB

मुझे लगता है कि आपकी समस्या इस तथ्य से उत्पन्न होती है

main.cpp में आप सिमा को भी देखें

क्या मैं सही हूँ?

यदि आप अपने कोड में किसी प्रतीक का उपयोग करते हैं, तो उस प्रतीक को एक .so फ़ाइल में मिलना चाहिए

अंतर-संदर्भित साझा पुस्तकालयों (यानी एपीआई बनाने) का पूरा विचार यह है कि गहरी परतों में प्रतीक छिपे हुए हैं (प्याज को छीलने के बारे में सोचें) और उपयोग नहीं किए गए हैं। .. यानी अपने main.cpp में syma का संदर्भ न लें, बल्कि केवल symB के बजाय (और symb को केवल syma को देखें)।