设置LD_PRELOAD后,共享对象被列出两次,既是找到的,也是未找到的,这意味着什么?

What does it mean for a shared object to be listed twice, both as found and not found, after setting LD_PRELOAD?

提问人:mpliax 提问时间:10/27/2023 最后编辑:mpliax 更新时间:11/17/2023 访问量:47

问:

我正在Red Hat Enterprise Linux 8上使用GCC 8.5.0编译C++可执行文件(比方说)和它所依赖的两个库(比方说和)。myexecmylib1.somylib2.so

运行返回:ldd myexec

        linux-vdso.so.1 (0x00007ffcf9852000)                                       
        libpython3.6m.so.1.0 => /lib64/libpython3.6m.so.1.0 (0x00007fa8571aa000)   
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa856f8a000)             
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fa856d86000)                       
        libutil.so.1 => /lib64/libutil.so.1 (0x00007fa856b82000)                   
        mylib1.so => not found  # First missing lib 
        mylib2.so => not found  # Second missing lib
        # ...more libs follow

这意味着 AFAIU 找不到两个自定义链接库。我会说这是意料之中的,因为库位于未被搜索的目录中。ldd

我希望,设置会有所帮助,所以我运行:LD_PRELOAD

export LD_PRELOAD="/path/to/mylib1.so:/path/to/mylib2.so"
ldd myexec

这返回了我:

        linux-vdso.so.1 (0x00007fc5a293c000)                                       
        /path/to/mylib1.so (0x00007fc5a31ed000)  # First lib found
        /path/to/mylib2.so (0x00007fc5a2e7e000)  # Second lib found
        libpython3.6m.so.1.0 => /lib64/libpython3.6m.so.1.0 (0x00007fc5a293c000)   
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc5a271c000)             
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fc5a2518000)                       
        libutil.so.1 => /lib64/libutil.so.1 (0x00007fc5a2314000)                   
        mylib1.so => not found   # First lib...also NOT found?
        # ...more libs follow   

请注意,已找到,但列出两次,分别为找到未找到。mylib2.somylib1.so

所以,我的问题是:如果列出它,为什么会丢失?这是否与在我尝试链接的符号中找不到符号有关?mylib1.solddLD_PRELOAD


编辑:对我来说更神秘的是,软链接库会导致:mylib1.so/usr/lib64

        linux-vdso.so.1 (0x00007fff3c3e7000)                                       
        /path/to/mylib1.so (0x00007f5dc2cfa000)  # First lib found
        /path/to/mylib2.so (0x00007f5dc298b000)  # Second lib found
        libpython3.6m.so.1.0 => /lib64/libpython3.6m.so.1.0 (0x00007f5dc2449000)   
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5dc2229000)             
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f5dc2025000)                       
        libutil.so.1 => /lib64/libutil.so.1 (0x00007f5dc1e21000)                    
        # ...more libs follow

即条目消失了。但是,我不想那样解决问题,因为这意味着会弄乱机器的所有其他用户。mylib1.so => not found


编辑2:我尝试将LD_LIBRARY_PATH设置为/dir/containing/mylib1/之类的内容,但它不起作用,仍然找不到 mylib1.so最终奏效了,这似乎是一个可行的解决方案,但我仍然想知道为什么没有得到尊重。LD_LIBRARY_PATHLD_PRELOAD


编辑 3:跑步列出了一些我仍然不明白的额外信息:LD_DEBUG=all ldd myexec

     57257:     file=/path/to/mylib1.so [0];  needed by /path/to/myexec [0]
     57257:     file=/path/to/mylib1 [0];  generating link map
     57257:       dynamic: 0x00007f7d44ecdd40  base: 0x00007f7d44cbd000   size: 0x00000000002114c0
     57257:         entry: 0x00007f7d44cc2eb0  phdr: 0x00007f7d44cbd040  phnum:                  9

     # ... more lines follow
     
     57257:     file=mylib1.so [0];  needed by /path/to/myexec [0]
     57257:     find library=mylib1.so [0]; searching
     57257:      search cache=/etc/ld.so.cache

     # ... searches all remaining paths, like /usr/lib64, where I decided to make a soft link>

所以它找到了我指定的 ,但它不满意,并继续搜索它。mylib1.soLD_PRELOAD

GCC 连接器 LD-Preload LDD

评论


答: 暂无答案