当前位置: 首页 > 面试题库 >

分层ldd(1)

宋伟泽
2023-03-14
问题内容

由于使用了Gentoo,经常发生这样的情况,即在更新程序链接到旧版本的库之后。通常,revdep-
rebuild有助于解决该问题,但是这一次它依赖于python库,python-updater因此不会使用。

是否有“分层”变体ldd向我显示哪个共享库取决于另一个共享库?大多数时候,库和可执行文件仅与少数几个其他共享库链接,而这些共享库又与少数几个共享库链接,从而使库依赖性成为一个大列表。我想知道我必须使用升级的另一个库的新版本来重建哪个依赖项。


问题答案:

如果您正在使用运行Portage≥2.2 FEATURES=preserve-libs,你几乎很少需要revdep- rebuild了,因为老人.so.需要VERS将被保留,(但你仍然需要仔细重建,因为东西还是去KABOOM当libA.so.0欲望libC.so.0libB.so.0希望libC.so.1与一些二进制希望既libA.so.0libB.so.0)。

就是说,要做的ldd是让动态链接器照常加载可执行文件或库,但在此过程中打印出一些信息。这是一个递归的“二进制需求库需要其他库和hellip”搜索,因为这是动态链接器所做的。

我目前正在运行Linux / ppc32;在Linux / x86上,动态链接程序通常为/lib/ld-linux.so.2;在Linux /
x86_64上,动态链接程序通常为/lib/ld- linux-x86-64.so.2。在这里,我直接称呼它只是为了强调一点,ldd就是shell脚本需要动态链接程序执行其魔术。

$ /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没有libpthread.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的动态链接器播放其他可爱的技巧。



 类似资料:
  • 问题内容: 我创建了一个交叉编译的arm可执行文件。我想找到可执行文件的库依赖项。我正在使用ubuntu natty并安装了不包含ldd的arm-linux- gnueabi工具链。有没有可用的工具来查看Linux中arm可执行文件库的依赖性。 问题答案: 这有点儿混乱,但这是我能找到的最好的解决方案,对于基本用途它确实很好用-只需使用其他交叉工具将此脚本另存为“ arm-none-linux-g

  • 本节将对HubbleData的实验分层功能进行介绍。 1.1. 流量分配 A/B测试脱胎于药品测试的双盲实验,本身有非常严谨的科学依据。自从谷歌在互联网行业引入A/B测试以来,A/B测试已经成为互联网行业提升效率、优化运营的必备利器。随着A/B测试的普及,如何在科学性的前提下,尽可能降低成本成为我们研究的方向。 A/B测试最基本的原则是样本除了测试变量之外,其他特征必须完全一致,即所有用户仅受单一

  • 1.【强制】 图中默认上层依赖于下层,箭头关系表示可直接依赖,如:开放接口层可以依赖于 Web 层,也可以直接依赖于 Service 层,依此类推: 开放接口层: 可直接封装 Service 方法暴露成 RPC 接口;通过 Web 封装成 http 接口;进行 网关安全控制、流量控制等。 终端显示层: 各个端的模板渲染并执行显示的层。当前主要是 velocity 渲染,JS 渲染, JSP 渲染,

  • 1.【强制】 图中默认上层依赖于下层,箭头关系表示可直接依赖,如:开放接口层可以依赖于 Web 层,也可以直接依赖于 Service 层,依此类推: 开放接口层: 可直接封装 Service 方法暴露成 RPC 接口;通过 Web 封装成 http 接口;进行网关安全控制、流量控制等。 终端显示层: 各个端的模板渲染并执行显示的层。当前主要是 html 模板渲染,JS 渲染,移动端展示等。 Web

  • 问题内容: 我正在运行这两个命令,并且得到不同的输出: 然后 那是怎么回事?我以为他们都给了图书馆依赖?我关心的原因是我怀疑这是正确的,但是我正在ARM上的linux上工作,在我看来,这没有什么废话。 问题答案: 您可以看到输出的差异。 objdump只是将对象本身列出的内容转储为包含未解析符号的库。 ldd列出了ld.so实际加载的库。它向后跟随该图,以便您可以看到 这些 库将加载的内容。尽管不

  • 问题内容: 我希望我能够解释困扰我的问题。我有以下分层数据集(这只是34K记录的子集) 这是树的代表 我需要的是清单的所有记录,带有exam = N和潜在的extest =’J’记录,可以嵌套。 给我 但是我需要的是 当我遇到EXAM =’N’记录时,需要停止运行。 我需要类似“停止于”子句的内容。 如何才能做到这一点? 问题答案: 罗伯特 您可以通过在connect by子句中添加“ exam