On 4/18/21 4:10 PM, Jan Engelhardt wrote:
On Sunday 2021-04-18 22:06, Bruce Ferrell wrote:
ls: relocation error: /tmp/glibc/root/glibc-2.33/lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference ---- When the app originally compiled it had one set of symbols ls does not require "_dl_fatal_printf".
This is part of the reason that very "elemental" *IX (Linux, UNIX etc) programs like ls, ps, etc used to be installed in a staticlly linked version... That is a red herring.
The error stems from the dynamic linker unable to combine two versions of libc. If you were to attempt the same with a static link, that would equally fail.
Static linking mode just doesn't fix stupid linking attempts in the first place.
If a program is statically linked at build time, attempts at loading additional dynamic link libraries at run time NEVER happens. If a "stupid link" errors has happened, the build never completes... The most common version is you don't have a version of the library that allows static linking. For all intents and purposes, in this circumstance, you don't get a binary you can even try to run.
To make a long story short, the linker universally sticks a hook into programs that looks for the environment variable LD_PRELOAD, and if present, uses the libraries found there before looking at LD_LIBRARY_PATH to resolve library loading. No, not really, especially not for the case of dynamicly-linked executables.
Analysis of LD_PRELOAD/LD_LIBRARY_PATH happens by ld-linux.so, which is not a hook but a program in its own right.
Good lord you're pedantic! ld-linux.so is a dynamic link library. The so extension means "shared object" and I know a DLL is windows nomenclature. I know the man page for ldd calls ld-linux a program. They serve the same purpose and I don't get hung up on anything BUT purpose. Just to be equally pedantic, it's placed by the linker, unless the --static option was specified during the build it's used only for resolving any other dynamic link libraries (shared objects) to be used. <library>.so is a dynamic link library/shared object intended for dynamic use. <library>.a is the same set of library functions in a format that can be statically linked. Once statically linked into the program, you can run the program without <library>.a present outside the of the program. In the example below, the same example used in the ldd man page, we can the exact shared objects linked in. we see linux-vdso.so, (see man vdso) a shared object for the kernel for support of the virtual ELF dynamic format. ELF support in the kernel configuration has to be specified... if happen you to build a kernel. we also see the full path to ld-linux and the rest of the shared objects used by ls ldd /usr/bin/ls linux-vdso.so.1 (0x00007ffc554df000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fc99bffa000) libcap.so.2 => /usr/lib64/libcap.so.2 (0x00007fc99bdf5000) libc.so.6 => /lib64/libc.so.6 (0x00007fc99ba3a000) libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007fc99b7af000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fc99b5ab000) /lib64/ld-linux-x86-64.so.2 (0x00007fc99c445000) If any are missing or are not available, we get a "not found" If you happen to make an incorrect library version match up to what the ELF format of the process specifies for, it MAY try to run but is likely to have different errors at run time... I know, I've tried. Sometimes it works though. IF you use LD_PRELOAD, you can force an override of "normal" resolution... Cause different versions of libraries to be used. To digress for just a moment, there is one use of LD_PRELOAD for forcing a shared object that was never linked to load, that will cause the openssl library to dump session keys generated during the run and those can be used to decrypt TLS packets collected with tcpdump. Gawd! it's been a VERY long time since I've wanted to look at this stuff for other than minor functional reasons. I can't even remember why ELF is/was considered to be better than a.out anymore... But, it's what is done now. Thanks for the trip down memory lane!