Ld (लिंकर) खोज पथ को कैसे प्रिंट करें

Question

खोज पथों को मुद्रित करने का तरीका क्या है जो खोजे गए क्रम में ld द्वारा देखा गया है ।

Answer 1

आप निम्न आदेश निष्पादित करके ऐसा कर सकते हैं:

ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012

gcc लिंकर को कुछ अतिरिक्त -L पथ देता है, जिसे आप निम्नलिखित कमांड से सूचीबद्ध कर सकते हैं:

gcc -print-search-dirs | sed '/^lib/b 1;d;:1;s,/[^/.][^/]*/\.\./,/,;t 1;s,:[^=]*=,:;,;s,;,;  ,g' | tr \; \\012

Ld.so.conf और ldconfig का उपयोग करने का सुझाव देने वाले उत्तर सही नहीं हैं क्योंकि वे रनटाइम डायनेमिक लिंकर द्वारा खोजे गए रास्तों का उल्लेख करते हैं (अर्थात जब भी कोई प्रोग्राम निष्पादित किया जाता है), जो कि ld (यानी जब भी खोजे गए पथ के समान नहीं होता) एक कार्यक्रम जुड़ा हुआ है)।

Comments

आपने मौके पर मारा। मुझे एक लिंकिंग समस्या है, लिंक करने की प्रक्रिया के दौरान लिंकर मैन्युअल रूप से स्थापित लाइब्रेरी पाता है /usr/local/..जिसमें लाइब्रेरी की अनुपलब्धता का कारण बनता है, और लिंकिंग विफल हो जाती है। मुझे /usr/localउस खोज पथ को बाहर करने के लिए हर बार नाम बदलना होगा । क्या मार्ग को बाहर करने या ओवरराइड करने का एक सरल तरीका है /usr/local?

— kenn

आप GCC के लिए -L विकल्प के साथ लाइब्रेरी पथ को मैन्युअल रूप से निर्दिष्ट करने का प्रयास कर सकते हैं, जो मुझे लगता है (सुनिश्चित नहीं है) सिस्टम लाइब्रेरी के ओवरराइड को ओवरराइड करेगा। तुम भी संकलन से पहले LIBRARY_PATH env चर सेट करने के लिए कोशिश कर सकते: $ LIBRARY_PATH = / somedir / जीसीसी ...

— faken

मुझे पता है कि कमांड लाइन संकलन में लिंकिंग। मेरा मतलब है कि ldखोज पथ को ओवरराइड करने का एक वैश्विक तरीका है । उदाहरण के लिए कभी कभी मैं से एक स्रोत कोड संकलन करने के लिए है makefileया पैदा करने makefile configureस्क्रिप्ट या से CMakeLists.txtया यहाँ तक कि इस तरह के रूप लोगों को और अधिक जटिल valaया srt। ldऐसे मामलों में खोज पथ को संशोधित करना मेरे लिए कठिन है

— kenn

CMake का उपयोग करते समय आप सटीक पुस्तकालयों का चयन कर सकते हैं जो कॉन्फ़िगरेशन चरण के दौरान उपयोग किए जाते हैं (इनमें से कुछ प्रविष्टियां केवल उन्नत मोड में दिखाई जाती हैं)। ऑटोटूल से स्क्रिप्ट को कॉन्फ़िगर करने के लिए, इस उत्तर को देखें: stackoverflow.com/questions/7561509/… । यह सीधे आपके प्रश्न का उत्तर नहीं देता है, लेकिन आपको वह करने में मदद कर सकता है जो आप चाहते हैं।

— faken

Answer 2

लिनक्स पर, आप उपयोग कर सकते हैं ldconfigजो ld.so विन्यास और कैश का कहना है,, निर्देशिका के आधार पर खोज करने के लिए प्रिंट आउट ld.soके साथ

ldconfig -v 2>/dev/null | grep -v ^$'\t'

ldconfig -vलिंकर (एक अग्रणी टैब के बिना) और उन निर्देशिकाओं में पाए जाने वाले साझा पुस्तकालयों (एक अग्रणी टैब के साथ) द्वारा निर्देशिकाओं को प्रिंट करता है; grepनिर्देशिका हो जाता है। मेरी मशीन पर, यह रेखा प्रिंट करती है

/usr/lib64/atlas:
/usr/lib/llvm:
/usr/lib64/llvm:
/usr/lib64/mysql:
/usr/lib64/nvidia:
/usr/lib64/tracker-0.12:
/usr/lib/wine:
/usr/lib64/wine:
/usr/lib64/xulrunner-2:
/lib:
/lib64:
/usr/lib:
/usr/lib64:
/usr/lib64/nvidia/tls: (hwcap: 0x8000000000000000)
/lib/i686: (hwcap: 0x0008000000000000)
/lib64/tls: (hwcap: 0x8000000000000000)
/usr/lib/sse2: (hwcap: 0x0000000004000000)
/usr/lib64/tls: (hwcap: 0x8000000000000000)
/usr/lib64/sse2: (hwcap: 0x0000000004000000)

बिना hwcapलाइन के पहले रास्ते या तो अंतर्निहित हैं या /etc/ld.so.conf से पढ़े जाते हैं। इसके बाद लिंक करने वाला अतिरिक्त लाइब्रेरी सर्च पथ के तहत अतिरिक्त निर्देशिकाओं को खोज सकता है, जिसमें sse2अतिरिक्त सीपीयू क्षमताओं के अनुरूप नाम होते हैं । ये पथ, hwcapलाइन में, इन CPU क्षमताओं के अनुरूप अतिरिक्त लाइब्रेरी हो सकते हैं।

एक अंतिम नोट: -pइसके बजाय -vऊपर का उपयोग करके ld.soकैश को खोजता है ।

Comments

वह लिंकर (ld) और लोडर (ld.so) के बारे में नहीं पूछ रहा है!

— फोंस

यह कैसे संभव है कि अगर मैं सेट करता हूं export LD_LIBRARY_PATH=/some/other/dir, तो यह इस कमांड के आउटपुट को प्रभावित नहीं करेगा ?! ऐसा लगता है कि यह 100% काम नहीं करता है?

— TMS

@ फोंस फनीथिंग यह है कि मैं इस उत्तर की तलाश में यहां आया हूं। :) लिंक-टाइम या रन-टाइम पथ? मुझे लगता है कि यह सवाल है। LIBRAY_PATH (लिंक समय) बनाम LD_LIBRARY_PATH।

— डैनियल सांतोस

मुझे कुछ प्लेटफ़ॉर्म पर पाया गया है (जैसे Linaro toolchain के साथ बांह) कि ldconfig वास्तव में रन टाइम लिंकर के समान निर्देशिका नहीं खोजता है। आप इसे अपने खोज पथ को आउटपुट करने के लिए प्राप्त कर सकते हैं, और LD_LIBRARY_PATHडिबगिंग को सक्षम करके पथों को शामिल कर सकते हैं । जैसे LD_DEBUG=libs /lib/ld-linux.so --list cat(आप किसी भी निष्पादन योग्य का उपयोग कर सकते हैं, मैंने catपहली चीज के रूप में उठाया था जो मैं सोच सकता था)। " search path" के लिए टटोलने लायक हो सकता है । ध्यान दें कि यदि आपके पास एक ऐसा है /etc/ld.so.cacheजो सभी आवश्यक कामों से मेल खाता है, तो आपको अंतर्निहित सिस्टम खोज पथ देखने को नहीं मिलेगा, क्योंकि यह अब तक नहीं मिलेगा।

— जॉन ओ.एम.

क्या gccखोज पथ इन के साथ समान है?

— nn0p

Answer 3

मुझे यकीन नहीं है कि पूर्ण प्रभावी खोज पथ को मुद्रित करने के लिए कोई विकल्प नहीं है।

लेकिन: खोज पथ -Lमें कमांड लाइन पर विकल्पों द्वारा निर्दिष्ट निर्देशिकाएं शामिल हैं , इसके बाद निर्देशिकाएं SEARCH_DIR("...")लिंकर स्क्रिप्ट (एस) में निर्देशों द्वारा खोज पथ में जोड़ दी जाती हैं । तो आप इसे काम कर सकते हैं यदि आप उन दोनों को देख सकते हैं, जो आप निम्नानुसार कर सकते हैं:

यदि आप ldसीधे आमंत्रित कर रहे हैं:

• -Lविकल्प आप जो कुछ भी कहा है कि वे कर रहे हैं।
• लिंकर स्क्रिप्ट देखने के लिए, --verboseविकल्प जोड़ें । के लिए देखो SEARCH_DIR("...")निर्देशों, आम तौर पर उत्पादन के शीर्ष के निकट। (ध्यान दें कि ये अनिवार्य रूप से हर मंगलाचरण के लिए समान नहीं हैं ld- लिंकर के पास कई अलग-अलग अंतर्निहित डिफ़ॉल्ट लिंकर स्क्रिप्ट हैं, और विभिन्न अन्य लिंकर विकल्पों के आधार पर उनके बीच चयन करता है।)

यदि आप इसके माध्यम से लिंक कर रहे हैं gcc:

• आप -vविकल्प को पास कर सकते हैं gccताकि यह आपको दिखाए कि यह लिंकर को कैसे आमंत्रित करता है। वास्तव में, यह आम तौर पर ldसीधे आह्वान नहीं करता है , लेकिन अप्रत्यक्ष रूप से एक उपकरण के माध्यम से बुलाया जाता है collect2(जो इसके आंतरिक निर्देशिका में से एक में रहता है), जो बदले में आह्वान करता है ld। यह आपको दिखाएगा कि किस -Lविकल्प का उपयोग किया जा रहा है।
• आप लिंकर से गुजरने के -Wl,--verboseलिए gccविकल्पों को जोड़ सकते --verboseहैं, लिंकर स्क्रिप्ट को ऊपर बताए अनुसार देख सकते हैं।

Comments

लिंकर के लिए --verbose विकल्प ने चाल चली। बहुत मददगार!

— अरी

मैं यह पता लगाने की कोशिश कर रहा था कि लिंकर कहां दिख रहा था और आउटपुट में SEARCH_DIR नहीं मिला। जैसा कि मैं -T scriptअपनी स्क्रिप्ट का उपयोग कर रहा था पूरी तरह से ld की डिफ़ॉल्ट स्क्रिप्ट को बदल देता है और केवल वही दिखता है जहाँ मैंने इंगित किया था।

— थोमैसा88

Answer 4

लिनक्स पर gcc और क्लैंग के लिए सबसे अधिक संगत कमांड जो (armando.sano के लिए धन्यवाद):

$ gcc -m64 -Xlinker --verbose  2>/dev/null | grep SEARCH | sed 's/SEARCH_DIR("=\?\([^"]\+\)"); */\1\n/g'  | grep -vE '^$'

यदि आप देते हैं -m32, तो यह सही पुस्तकालय निर्देशिकाओं का उत्पादन करेगा।

मेरी मशीन पर उदाहरण:

के लिए g++ -m64:

/usr/x86_64-linux-gnu/lib64
/usr/i686-linux-gnu/lib64
/usr/local/lib/x86_64-linux-gnu
/usr/local/lib64
/lib/x86_64-linux-gnu
/lib64
/usr/lib/x86_64-linux-gnu
/usr/lib64
/usr/local/lib
/lib
/usr/lib

के लिए g++ -m32:

/usr/i686-linux-gnu/lib32
/usr/local/lib32
/lib32
/usr/lib32
/usr/local/lib/i386-linux-gnu
/usr/local/lib
/lib/i386-linux-gnu
/lib
/usr/lib/i386-linux-gnu
/usr/lib

Comments

धन्यवाद! नन्हा वृद्धि - एक grep या दो से छुटकारा पाएं: sed -n 's / SEARCH_DIR ("= \ _? ([^"] \ +) "); * / \ _ 1 \ n / gp'

— ब्रूस

इसके लिए ऐसी अस्पष्ट पद्धति की आवश्यकता क्यों है?

— bmacnaughton

इसने एकदम जादू की तरह काम किया ! हम इस सूची में निर्देशिकाओं को कैसे जोड़ते हैं, लिंकर खोज पथ?

— परी

Answer 5

प्रश्न लिनक्स को टैग किया गया है, लेकिन शायद यह लिनक्स के तहत भी काम करता है?

gcc -Xlinker -v

मैक ओएस एक्स के तहत, यह प्रिंट करता है:

@(#)PROGRAM:ld  PROJECT:ld64-224.1
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 armv6m armv7m armv7em
Library search paths:
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib
Framework search paths:
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/
[...]

ऊपर का -Xlinkerविकल्प gccसिर्फ पास -vहोता है ld। तथापि:

ld -v

खोज पथ मुद्रित नहीं करता है।

Comments

लिनक्स पर यह निर्देशिकाओं को प्रिंट करता है, लेकिन इसके रूप में -Lpath। तो @ राफेल लोंडेक्स का जवाब बेहतर है।

— pevik

Answer 6

मैक संस्करण: $ ld -v 2, विस्तृत पथ प्राप्त करने का तरीका नहीं जानता। उत्पादन

Library search paths:
    /usr/lib
    /usr/local/lib
Framework search paths:
    /Library/Frameworks/
    /System/Library/Frameworks/

Comments

मुझे "2 नहीं खुल सकता: ऐसी कोई फ़ाइल या निर्देशिका नहीं"। रनिंगld -v 2

— जैक

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

— jww