Hiyerarşik ldd (1)

Question

Gentoo kullanımı nedeniyle, çoğu zaman bir güncelleme programlarının eski kitaplık sürümleriyle ilişkilendirildikten sonra gerçekleşir. Normalde, revdep-rebuild bunu çözmenize yardımcı olur, ancak bu sefer bir python kütüphanesine bağımlıdır ve python-updater onu almayacaktır.

ldd'un "hiyerarşik" bir varyasyonu var mı, hangi paylaşılan kitaplığın hangi başka bir paylaşılan kitaplığa bağlı olduğunu gösterir misiniz? Çoğu zaman kütüphaneler ve yürütülebilir dosyalar yalnızca bir avuç diğer paylaşılan kütüphaneye bağlıdır; bu da bir avuç dolusuyla bağlantılıdır ve kütüphane bağımlılığını büyük bir listeye dönüştürür. Yeni sürüme geçirdiğim başka bir kitaplığın yeni sürümüyle yeniden kurmam gereken bağımlılığı bilmek istiyorum. Gerektiğinde eski .so. vers (korunacaktır olarak

Answer 1

Eğer FEATURES=preserve-libs ile Portage ≥ 2.2 çalıştırıyorsanız, nadiren artık hiç revdep-rebuild gerektiğinde yine libA.so.0 istediğinde şeyler hala güm giderse, dikkatle yeniden gerek olsa libC.so.0 ve libB.so.0libC.so.1 istiyor ve bazı ikili hem libA.so.0 hem de libB.so.0 istiyor. söyleniyor

---

ne ldd yapar genellikle olduğu gibi yürütülebilir veya kitaplığı yüklenemedi yapmak dinamik bağlayıcı olsun, ama yol boyunca bazı bilgileri yazdırmak etmektir. Bu, dinamik bir bağlayıcının yaptığı şey, çünkü bu özyinelemeli bir "ikili kütüphane ihtiyacı olan diğer kütüphane & hellip" aramasına ihtiyaç duymaktadır.

Şu anda Linux/ppc32 çalıştırıyorum; Linux/x86 üzerinde, dinamik bağlayıcı genellikle /lib/ld-linux.so.2 ve Linux/x86_64 üzerinde dinamik bağlayıcı genellikle /lib/ld-linux-x86-64.so.2'dur. Burada, sadece tüm ldd'un, büyüsünü gerçekleştirmek için dinamik bağlayıcıyı çağıran bir kabuk komut dosyasından başka bir şey olmadığı noktada doğrudan çekiç olarak adlandırıyorum.

 
$ /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/badblocks

kütüphane bağımlılık olarak libpthread.so.0 listelemiyor ama libcom_err.so.2 tarafından çekilmiş olur.

Sorun, ldd'un güzel görünümlü bir bağımlılık ağacı oluşturmuyor mu? ldd -v kullanın.

---

İsterseniz

 
$ 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 

, bunun yerine Dinamik bağlayıcı bağlı olarak doğrudan ELF başlıklarını okuyabilir.

 
$ 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] 

Ayrıca man ld.so diğer sevimli hileler için size glibc 'ın Dinamik bağlayıcı ile oynayabilir yapabilirsiniz.

Answer 2

Ayrıca, “readelf -d” yi önermekle kalmayıp, aynı zamanda LDFLAGS = "- Wl, - gerektiği gibi" ile de oluşturulmasını sağladım. Bu, bu sorunu daha az sıklıkla vurmanızı sağlar. Portage 2.2'nin koruyucusu-lib'leri güzel ama topladım, çünkü esas olarak onun yüzünden maskeleniyordu - kusurları var.

Answer 3

Birçok ilginç ayrıntı görüyorum ama sorulan soruya doğrudan bir cevap yok.

ldd arasında 'hiyerarşik' versiyonu lddtree (app-misc/pax-utils itibaren) geçerli:

$ 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 

Answer 4

böyle bir şey gerekiyordu, ben de burada kendi kütüphane bağımlılıklarını gösteren, tldd yazdı:

 
$ ./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)