On Monday 2021-04-19 02:21, Bruce Ferrell wrote:
If a program is statically linked at build time, attempts at loading additional dynamic link libraries at run time NEVER happens.
No, not "never". $ cat x.cpp #include <pwd.h> int main(){setpwent();} $ g++ x.cpp -static x.cpp:(.text+0x5): warning: Using 'setpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking $ strace -e open,openat ./a.out openat(AT_FDCWD, "/lib64/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = 3
If a "stupid link" errors has happened, the build never completes...
Which was exactly my point. Linda has a stupid link error, it's just that it happens during runtime (but still with a linker).
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.
One can actually run ld-linux-x86-64.so.2 from the command line and get something out of it, which is not the case for e.g. /lib64/libacl.so.1. So ld-linux exhibits a user-visible program characteristic like ls would. (It's also an example of a staticly-linked program that is, perhaps unintuitive to some, a shared object.) Second, one can run ld-linux without ls, but one can't run ls without ld-linux. So that would speak for ld-linux being the "program", and ls being the module/plugin that provides the hook (commonly "main" for C programs, but it's not necessarily fixed), rather than ld-linux being a set of hooks to ls.
In the example below, the same example used in the ldd man page, we can the exact shared objects linked in.
ldd is just some sh code that invokes ld-linux and instructs it to print-and-exit after having processed relocations.
IF you use LD_PRELOAD, you can force an override of "normal" resolution... Cause different versions of libraries to be used.
LD_PRELOAD has no effect on ld-linux.so itself. It cannot have, because the code to evaluate LD_PRELOAD in the first place already is in memory. So LD_PRELOAD (or LD_LIBRARY_PATH) don't affect _all_ shared objects in the process image. So your suggestion to "just use LD_PRELOAD" is completely bogus and utterly flawed.