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
$ g++ x.cpp -static
x.cpp:(.text+0x5): warning: Using 'setpwent' in statically linked
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).
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
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
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
the ldd was "just" a shell script that invokes ld-linux... Good to know, but not
particularly useful for the question that started this)
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
I've spent enough time on you and this so I'm done with you and this
Thanks for the trivia added to my store... it may be useful someday.