On Tue, Aug 24, 2021 at 2:52 PM Richard W.M. Jones <rjones(a)redhat.com> wrote:
There's a problem here ...
For background see:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
(You have to click the "..." in that email)
If libc_malloc_debug.so.0 isn't installed then LD_PRELOAD generates
lots of warning messages and this actually breaks some tests.
If ./configure is used without --libdir then we try to set
LD_PRELOAD=/usr/local/lib/libc_malloc_debug.so.0 which causes the
warnings/failures.
My first idea was to test in ./configure if $libdir/libc_malloc_debug.so.0
exists and only set LD_PRELOAD if so. However that doesn't work
because of $!"£% exec_prefix (a.k.a. the most useless GNU feature that
no one uses but causes all the trouble).
Also if you have glibc.i686 and glibc.x86_64 installed then both
/lib64/libc_malloc_debug.so.0 and /lib/libc_malloc_debug.so.0 exist
and you must choose the correct one. On other distros the path will
be different, eg. the 64 bit one in /lib/libc_malloc_debug.so.0 or
/lib/x86_64-linux-gnu/... etc.
ld.so has a new --list-diagnostics option (since 2.34 AFAICT,
backported to at least 2.33) that lists the system directories; maybe
that could help?
$ /lib64/ld-linux-x86-64.so.2 --list-diagnostics | grep system_dirs
path.system_dirs[0x0]="/lib64/"
path.system_dirs[0x1]="/usr/lib64/"
libc_malloc_debug.so.0 will always be in one of these directories
unless a distribution has misconfigured their glibc and not added
their multilib paths into system_dirs.
So I don't know how to solve any of this. It would be nicer if
glibc
handled the details and automatically loaded the right library if
GLIBC_TUNABLES was set.
It is not impossible to implement; tunable parsing happens early
enough that if any tunable requires a preloaded module then we can
make it happen as long as the module is in path.system_dirs. We could
fail silently too; it's certainly better than ignoring silently.
Do you see any gotchas here Florian?
Siddhesh