Bug 239238

Summary: ldd(1) showing dependencies for shared objects in same name in library paths instead of in current working directory
Product: Base System Reporter: WHR <msl0000023508>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: New ---    
Severity: Affects Only Me CC: markj
Priority: ---    
Version: CURRENT   
Hardware: Any   
OS: Any   

Description WHR 2019-07-16 02:57:24 UTC
ldd(1) should show the dependencies of the program in current directory; however when a shared object file is given, and its file name is same with another shared object under library path (such as /usr/local/lib /usr/lib /lib), ldd(1) will showing dependencies for the shared object under library path.

For example:

[root@test ~/src]# uname -a
FreeBSD test 13.0-CURRENT FreeBSD 13.0-CURRENT r349753 GENERIC  amd64
[root@test ~/src]# ls -l /usr/lib/libfetch.so.6
-r--r--r--  1 root  wheel  81496 Jul  5 15:16 /usr/lib/libfetch.so.6
[root@test ~/src]# ldd /usr/lib/libfetch.so.6
/usr/lib/libfetch.so.6:
        libssl.so.111 => /usr/lib/libssl.so.111 (0x800695000)
        libcrypto.so.111 => /lib/libcrypto.so.111 (0x800e00000)
        libc.so.7 => /lib/libc.so.7 (0x800242000)
        libthr.so.3 => /lib/libthr.so.3 (0x80072e000)
[root@test ~/src]# ls -l libfetch.so.6
ls: libfetch.so.6: No such file or directory
[root@test ~/src]# ldd libfetch.so.6
ldd: libfetch.so.6: No such file or directory
[root@test ~/src]# cat dummy.c 
#include <stdio.h>

void useless() {
        fprintf(stderr, "You just called an useless function\n");
}
[root@test ~/src]# gcc --shared -Wall -O1 -fPIC dummy.c -o libfetch.so.6
[root@test ~/src]# ls -l libfetch.so.6
-rwxr-xr-x  1 root  wheel  7384 Jul 16 10:46 libfetch.so.6
[root@test ~/src]# file libfetch.so.6
libfetch.so.6: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, with debug_info, not stripped
[root@test ~/src]# ldd libfetch.so.6
libfetch.so.6:
        libssl.so.111 => /usr/lib/libssl.so.111 (0x800695000)
        libcrypto.so.111 => /lib/libcrypto.so.111 (0x800e00000)
        libc.so.7 => /lib/libc.so.7 (0x800242000)
        libthr.so.3 => /lib/libthr.so.3 (0x80072e000)
[root@test ~/src]# ldd ./libfetch.so.6
./libfetch.so.6:
        libc.so.7 => /lib/libc.so.7 (0x800242000)
Comment 1 Mark Johnston freebsd_committer freebsd_triage 2020-06-02 15:16:06 UTC
Indeed, the handling of executables and shared libs is inconsistent.  The current behaviour makes some sense since it matches the runtime linker's search algorithm, but it is not really intuitive for a command-line program.  Our behaviour is also incompatible with Linux's.  The main question would be whether changing this breaks anything.  It might be reasonable to try searching the current directory before falling back to the rtld search path.  That would give more consistent behaviour and be less likely to break anything.