2009-09-28 13 views
29

Gentoo का उपयोग करने के कारण, यह अक्सर होता है कि एक अद्यतन कार्यक्रम पुस्तकालयों के पुराने संस्करणों के खिलाफ जुड़े हुए हैं। आम तौर पर, revdep-rebuild इसे हल करने में मदद करता है, लेकिन इस बार यह एक पायथन पुस्तकालय पर निर्भरता है, और python-updater इसे नहीं उठाएगा।पदानुक्रमित ldd (1)

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

उत्तर

15

आप FEATURES=preserve-libs साथ Portage ≥ 2.2 चला रहे हैं, तो आप शायद ही कभी revdep-rebuild अब ज़रूरत चाहिए के रूप में वर्ष .so. vers रूप में की जरूरत संरक्षित किया जाएगा (आप अभी भी ध्यान से पुनर्निर्माण के लिए, के रूप में सामान अभी भी kaboom चला जाता है जब libA.so.0 चाहता है की जरूरत है, हालांकि libC.so.0 और libB.so.0libC.so.1 चाहता है और कुछ बाइनरी libA.so.0 और libB.so.0 दोनों चाहते हैं)।


कहा जा रहा है, क्या ldd करता है यह आम तौर पर होगा के रूप में निष्पादन योग्य या लाइब्रेरी लोड करने के लिए गतिशील लिंकर मिलता है, लेकिन रास्ते में कुछ जानकारी का प्रिंट आउट के लिए है। यह एक पुनरावर्ती "बाइनरी जरूरत पुस्तकालय की अन्य लाइब्रेरी & hellip" खोज की आवश्यकता है, क्योंकि गतिशील लिंकर यही करता है।

मैं वर्तमान में लिनक्स/पीपीसी 32 चला रहा हूं; लिनक्स/x86 पर, डायनामिक लिंकर आमतौर पर /lib/ld-linux.so.2 होता है, और लिनक्स/x86_64 पर, गतिशील लिंकर आमतौर पर /lib/ld-linux-x86-64.so.2 होता है। यहां, मैं इसे सीधे इस बिंदु पर हथौड़ा लगाने के लिए कहता हूं कि सभी ldd एक शैल स्क्रिप्ट से अधिक कुछ नहीं है जो गतिशील लिंकर को अपने जादू करने के लिए कहता है।

 
$ /lib/ld.so.1 /sbin/badblocks 
Usage: /sbin/badblocks [-b block_size] [-i input_file] [-o output_file] [-svwnf] 
     [-c blocks_at_once] [-d delay_factor_between_reads] [-e max_bad_blocks] 
     [-p num_passes] [-t test_pattern [-t test_pattern [...]]] 
     device [last_block [first_block]] 
$ LD_TRACE_LOADED_OBJECTS=1 /lib/ld.so.1 /sbin/badblocks 
     linux-vdso32.so.1 => (0x00100000) 
     libext2fs.so.2 => /lib/libext2fs.so.2 (0x0ffa8000) 
     libcom_err.so.2 => /lib/libcom_err.so.2 (0x0ff84000) 
     libc.so.6 => /lib/libc.so.6 (0x0fdfa000) 
     libpthread.so.0 => /lib/libpthread.so.0 (0x0fdc0000) 
     /lib/ld.so.1 (0x48000000) 
$ LD_TRACE_LOADED_OBJECTS=1 /lib/ld.so.1 /lib/libcom_err.so.2 
     linux-vdso32.so.1 => (0x00100000) 
     libpthread.so.0 => /lib/libpthread.so.0 (0x6ffa2000) 
     libc.so.6 => /lib/libc.so.6 (0x6fe18000) 
     /lib/ld.so.1 (0x203ba000) 
$ grep -l pthread /sbin/badblocks /lib/libcom_err.so.2 
/lib/libcom_err.so.2 

/sbin/badblockslibpthread.so.0 एक पुस्तकालय निर्भरता के रूप में सूचीबद्ध नहीं करता है, लेकिन यह libcom_err.so.2 द्वारा में खींच लिया जाता है।

क्या आपकी समस्या है कि ldd एक अच्छा दिखने वाला निर्भरता पेड़ आउटपुट नहीं करता है? ldd -v का प्रयोग करें।

 
$ LD_TRACE_LOADED_OBJECTS=1 LD_VERBOSE=1 /lib/ld.so.1 /sbin/badblocks 
     linux-vdso32.so.1 => (0x00100000) 
     libext2fs.so.2 => /lib/libext2fs.so.2 (0x0ffa8000) 
     libcom_err.so.2 => /lib/libcom_err.so.2 (0x0ff84000) 
     libc.so.6 => /lib/libc.so.6 (0x0fdfa000) 
     libpthread.so.0 => /lib/libpthread.so.0 (0x0fdc0000) 
     /lib/ld.so.1 (0x201f9000) 

     Version information: 
     /sbin/badblocks: 
       libc.so.6 (GLIBC_2.2) => /lib/libc.so.6 
       libc.so.6 (GLIBC_2.4) => /lib/libc.so.6 
       libc.so.6 (GLIBC_2.1) => /lib/libc.so.6 
       libc.so.6 (GLIBC_2.0) => /lib/libc.so.6 
       libc.so.6 (GLIBC_2.3.4) => /lib/libc.so.6 
     /lib/libext2fs.so.2: 
       libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6 
       libc.so.6 (GLIBC_2.4) => /lib/libc.so.6 
       libc.so.6 (GLIBC_2.3) => /lib/libc.so.6 
       libc.so.6 (GLIBC_2.2) => /lib/libc.so.6 
       libc.so.6 (GLIBC_2.1) => /lib/libc.so.6 
       libc.so.6 (GLIBC_2.0) => /lib/libc.so.6 
     /lib/libcom_err.so.2: 
       ld.so.1 (GLIBC_2.3) => /lib/ld.so.1 
       libpthread.so.0 (GLIBC_2.1) => /lib/libpthread.so.0 
       libpthread.so.0 (GLIBC_2.0) => /lib/libpthread.so.0 
       libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6 
       libc.so.6 (GLIBC_2.4) => /lib/libc.so.6 
       libc.so.6 (GLIBC_2.1) => /lib/libc.so.6 
       libc.so.6 (GLIBC_2.0) => /lib/libc.so.6 
     /lib/libc.so.6: 
       ld.so.1 (GLIBC_PRIVATE) => /lib/ld.so.1 
       ld.so.1 (GLIBC_2.3) => /lib/ld.so.1 
     /lib/libpthread.so.0: 
       ld.so.1 (GLIBC_2.3) => /lib/ld.so.1 
       ld.so.1 (GLIBC_2.1) => /lib/ld.so.1 
       ld.so.1 (GLIBC_PRIVATE) => /lib/ld.so.1 
       libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6 
       libc.so.6 (GLIBC_2.3.4) => /lib/libc.so.6 
       libc.so.6 (GLIBC_2.4) => /lib/libc.so.6 
       libc.so.6 (GLIBC_2.1) => /lib/libc.so.6 
       libc.so.6 (GLIBC_2.3.2) => /lib/libc.so.6 
       libc.so.6 (GLIBC_2.2) => /lib/libc.so.6 
       libc.so.6 (GLIBC_PRIVATE) => /lib/libc.so.6 
       libc.so.6 (GLIBC_2.0) => /lib/libc.so.6 

यदि आप चाहते हैं, आप के बजाय गतिशील लिंकर पर निर्भर करता है की सीधे ELF हेडर पढ़ सकते हैं।

 
$ readelf -d /sbin/badblocks | grep NEEDED 
0x00000001 (NEEDED)      Shared library: [libext2fs.so.2] 
0x00000001 (NEEDED)      Shared library: [libcom_err.so.2] 
0x00000001 (NEEDED)      Shared library: [libc.so.6] 
$ readelf -d /lib/libcom_err.so.2 | grep NEEDED 
0x00000001 (NEEDED)      Shared library: [libpthread.so.0] 
0x00000001 (NEEDED)      Shared library: [libc.so.6] 
0x00000001 (NEEDED)      Shared library: [ld.so.1] 

तुम भी man ld.so अन्य प्यारा चाल के लिए आप glibc के गतिशील लिंकर साथ खेल सकते हैं कर सकते हैं।

+0

वाह, बहुत बहुत धन्यवाद! – Astro

+0

'ldd -v' आउटपुट का वृक्ष अनुभाग केवल संस्करण वाले प्रतीकों के साथ पुस्तकालय दिखाता है – marcin

0

मैं भी "readelf -d" का सुझाव देने जा रहा था, लेकिन यह भी सुनिश्चित करता हूं कि आप एलडीएफएलजीएस = "- डब्ल्यूएल, - जरूरी" के साथ निर्माण करें यदि आप पहले से नहीं हैं। यह आपको इस समस्या को कम बार कम कर देगा। पोर्टेज 2.2 की संरक्षित-libs अच्छी है, लेकिन मैं इसे मुख्य रूप से इसके कारण मुखौटा बना देता हूं - इसमें त्रुटियां होती हैं।

+0

दोष आजकल मामूली हैं। हालांकि, मुझे लगता है कि मुझे उन पर एक नज़र डालना था, जैसे एक महीने पहले या कुछ: पी। –

60

मुझे कई दिलचस्प विवरण दिखाई देते हैं लेकिन पूछे गए प्रश्न का कोई सीधा जवाब नहीं है।

'श्रेणीबद्ध' ldd के संस्करण lddtree (app-misc/pax-utils से) है:

$ lddtree /usr/bin/xmllint 
xmllint => /usr/bin/xmllint (interpreter => /lib64/ld-linux-x86-64.so.2) 
    libreadline.so.6 => /lib64/libreadline.so.6 
     libncurses.so.5 => /lib64/libncurses.so.5 
      libdl.so.2 => /lib64/libdl.so.2 
    libxml2.so.2 => /usr/lib64/libxml2.so.2 
     libicui18n.so.49 => /usr/lib64/libicui18n.so.49 
      libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/32/libstdc++.so.6 
       ld-linux.so.2 => /lib64/ld-linux.so.2 
      libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/32/libgcc_s.so.1 
     libicuuc.so.49 => /usr/lib64/libicuuc.so.49 
     libicudata.so.49 => /usr/lib64/libicudata.so.49 
     libz.so.1 => /lib64/libz.so.1 
     liblzma.so.5 => /usr/lib64/liblzma.so.5 
     libm.so.6 => /lib64/libm.so.6 
    libpthread.so.0 => /lib64/libpthread.so.0 
    libc.so.6 => /lib64/libc.so.6 
+2

आप, महोदय, मेरे नायक हैं। 'Lddtree' का उल्लेख करने के लिए धन्यवाद, मैं थोड़ी देर के लिए इस तरह के एक उपकरण की तलाश में रहा हूँ। – ack

6

मैं कुछ इस तरह की जरूरत है, तो मैं tldd लिखा था, यहाँ यह अपने आप ही पुस्तकालय निर्भरता दिखा रहा है:

 
$ ./tldd ./tldd 
./tldd 
└─libstdc++.so.6 => /lib64/libstdc++.so.6 (0x0000003687c00000) 
    ├─libm.so.6 => /lib64/libm.so.6 (0x0000003685000000) 
    │ └─libc.so.6 => /lib64/libc.so.6 (0x0000003684c00000) 
    │ └─ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000003684400000) 
    └─libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003686c00000)