Red Hat Bugzilla – Bug 249256
ld.so too verbose when it can't LD_PRELOAD a 32 bit library on a 64 bit OS
Last modified: 2016-11-24 10:44:52 EST
Description of problem: If I set LD_PRELOAD to point to a 32 bit shared object when running a 32 bit application on a 64 bit OS, ld.so (/lib64/ld-2.3.4.so) can report: ERROR: ld.so: object '/path/to/some.so' from LD_PRELOAD cannot be preloaded: ignored. This can happen if the 32 bit application spawns a sub-process using the system() call - because this calls /bin/sh which is a 64 bit binary (which reports the 'ERROR') ... Version-Release number of selected component (if applicable): glibc-2.3.4-2.25 How reproducible: Every time Steps to Reproduce: 1. Set LD_PRELOAD to point to a 32 bit lib (on 64 bit OS) 2. Run 32 bit application that calls system() 3. Actual results: ERROR: ld.so: object '/path/to/some.so' from LD_PRELOAD cannot be preloaded: ignored. Expected results: No 'ERROR' message Additional info: This causes us problems as we have to use LD_PRELOAD you work round issues in 3rd party 32 bit applications - the 'ERROR' message cause users to report problems where there are none. The word 'ERROR' is too strong - it's not really an error as the application runs fine. There doesn't seem to be a way to turn off this message. I can 'fix' the issue using the attatched patch to glibc - which will only print the message if LD_WARN is defined
Created attachment 159775 [details] Patch to glibc to suppress LD_PRELOAD 'ERROR'
No, the diagnostics is totally appropriate, in some cases it might not be a problem when the preloaded library is purely optional, but ld.so can't know that. If you don't want to see any diagnostic and the preloaded lib is really needed just for one arch and not for the other, just build a dummy shared library, stick say the real preload lib into /lib/libpreload.so, the dummy into /lib64/libpreload.so and use LD_PRELOAD=libpreload.so. Or you can use even full path, if you have say /path/lib/libpreload.so containing the 32-bit preload lib and /path/lib64/libpreload.so containing 64-bit preload lib (either of those can be a dummy gcc -shared -fpic -o libpreload.so -xc /dev/null -m{32,64} built lib) and LD_PRELOAD=/path/'$LIB'/libpthread.so whatever
Thanks for the info ... I assume the '$LIB' is some internal variable to the runtime linker - as it not defined in the enviroment ??? Is this documented somewhere - there is no mention of this in the ld.so man page
$LIB is a dynamic string token recognized by ld.so similar to $ORIGIN or $PLATFORM. It expands to lib or lib64 depending on architecture of ld.so (x86_64, s390x, ppc64 ld.so expand it to lib64, i?86, s390, ppc, ia64 ld.so to lib).
Not meaning to hijack bug, but this is still overly verbose as it warns for each library during load, rather than just once. Is there a dynamic string token that applies to the arch of the binary ld.so is loading? Steam by default preloads a 32bit lib for their overlay support, warnings appear for 64bit binaries but I cant understand how one could make a dummy library, use $LIB to load either 32/64 overlay lib, and yet not break the 32bit lib loading, as it would always pick lib64 for a 64bit system, right?