Bug 239238 - ldd(1) showing dependencies for shared objects in same name in library paths instead of in current working directory
Summary: ldd(1) showing dependencies for shared objects in same name in library paths ...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
Depends on:
Reported: 2019-07-16 02:57 UTC by WHR
Modified: 2020-06-02 15:16 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
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
        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
        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
        libc.so.7 => /lib/libc.so.7 (0x800242000)
Comment 1 Mark Johnston freebsd_committer 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.