On 4/19/21 1:44 AM, Jan Engelhardt wrote:
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.
As I said before, pedantic. LD_PRELOAD doesn't affect shared objects... Only programs, even those that masquerade as shared objects (thanks for that. I never paid much attention to it before nor to the fact the ldd was "just" a shell script that invokes ld-linux... Good to know, but not particularly useful for the question that started this) ldd /lib64/ld-linux-x86-64.so.2 statically linked and that's why LD_PRELOAD has no effect on it... It's not just a program, it's a statically linked program that uses no external shared objects and has no need to resolve them. My entire point was that LD_PRELOAD effects programs the are dynamically linked (not those that are statically linked) and can be used, in conjunction with ld-linux and the rest of the ELF executable format to over ride library/shared object/program loading. I can only conclude by your demonstrated knowledge that you chose to ignore that point in order to continue to call people/situations name and "bike shed" the original question. I've spent enough time on you and this so I'm done with you and this discussion. Thanks for the trivia added to my store... it may be useful someday.