Это потому, что CDLL
(или LibraryLoader
или что-то еще из [Python]: ctypes - библиотека сторонних функций для Python - и вещи могут быть расширены еще больше) использует "нативный"система загрузки библиотек "для того, чтобы справиться с библиотекой (поиск и) загрузка (включая зависимости).
В Ux системах, что обычно выполняется с помощью динамического компоновщика / загрузчика .
Теперь, я полагаю, вы задаетесь вопросом, почему, например, "/ lib / x86_64-linux-gnu / libc.so.6" найден, хотя "/ lib / x86_64-linux-gnu" is not in $ {LD_LIBRARY_PATH} .
From [man7]: LD.SO (8) :
Программа ld.so обрабатывает двоичные файлы a.out, формат, который использовался давно; ld-linux.so * ( / lib / ld-linux.so.1 для libc5, / lib / ld-linux.so.2 для glibc2) обрабатывает ELF, которым все пользуются уже много лет.В противном случае оба имеют одинаковое поведение и используют те же файлы и программы поддержки, что и ldd (1) , ldconfig (8) и / etc / ld.so.conf .
От [man7]: LD (1) :
Компоновщик использует следующееискать пути для поиска необходимых общих библиотек:
...
8. Для собственного компоновщика в системе ELF, если файл / etc / ld.so.conf существует, список каталогов, найденных в этом файле.
Пример на моей ВМ :
[cfati@cfati-ubtu16x64-0:~/Work/Dev/StackOverflow]> uname -a
Linux cfati-ubtu16x64-0 4.13.0-43-generic #48~16.04.1-Ubuntu SMP Thu May 17 12:56:46 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[cfati@cfati-ubtu16x64-0:~/Work/Dev/StackOverflow]> which ls
/bin/ls
[cfati@cfati-ubtu16x64-0:~/Work/Dev/StackOverflow]> file /bin/ls
/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=d0bc0fb9b3f60f72bbad3c5a1d24c9e2a1fde775, stripped
[cfati@cfati-ubtu16x64-0:~/Work/Dev/StackOverflow]> ldd /bin/ls
linux-vdso.so.1 => (0x00007ffc0e2e1000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f64b63d0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f64b6006000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f64b5d96000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f64b5b92000)
/lib64/ld-linux-x86-64.so.2 (0x00007f64b65f2000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f64b5975000)
[cfati@cfati-ubtu16x64-0:~/Work/Dev/StackOverflow]> readelf -d /bin/ls
Dynamic section at offset 0x1de18 contains 25 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libselinux.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
...
[cfati@cfati-ubtu16x64-0:~/Work/Dev/StackOverflow]> cat /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf
[cfati@cfati-ubtu16x64-0:~/Work/Dev/StackOverflow]> ls -al /etc/ld.so.conf.d/*.conf
-rw-r--r-- 1 root root 32 iun 6 17:42 /etc/ld.so.conf.d/00vboxvideo.conf
-rw-rw-r-- 1 root root 38 nov 24 2014 /etc/ld.so.conf.d/fakeroot-x86_64-linux-gnu.conf
-rw-r--r-- 1 root root 44 ian 27 2016 /etc/ld.so.conf.d/libc.conf
-rw-r--r-- 1 root root 68 apr 15 2016 /etc/ld.so.conf.d/x86_64-linux-gnu.conf
lrwxrwxrwx 1 root root 43 mar 9 19:43 /etc/ld.so.conf.d/x86_64-linux-gnu_EGL.conf -> /etc/alternatives/x86_64-linux-gnu_egl_conf
lrwxrwxrwx 1 root root 42 mar 9 19:43 /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf -> /etc/alternatives/x86_64-linux-gnu_gl_conf
-rw-r--r-- 1 root root 56 ian 15 04:49 /etc/ld.so.conf.d/zz_i386-biarch-compat.conf
-rw-r--r-- 1 root root 58 ian 15 04:50 /etc/ld.so.conf.d/zz_x32-biarch-compat.conf
[cfati@cfati-ubtu16x64-0:~/Work/Dev/StackOverflow]> cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
Поскольку это libc related, также проверьте [SO]: Как работает ctypes.cdll.LoadLibrary (None)?(Ответ @ CristiFati) , чтобы использовать уже загруженную версию libc (и избежать возможных конфликтов), , если libc статически не связан.