Bug 249256 - ld.so too verbose when it can't LD_PRELOAD a 32 bit library on a 64 bit OS
Summary: ld.so too verbose when it can't LD_PRELOAD a 32 bit library on a 64 bit OS
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: glibc   
(Show other bugs)
Version: 4.4
Hardware: x86_64
OS: Linux
Target Milestone: ---
: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2007-07-23 11:53 UTC by James Pearson
Modified: 2016-11-24 15:44 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-23 12:06:32 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch to glibc to suppress LD_PRELOAD 'ERROR' (593 bytes, patch)
2007-07-23 11:53 UTC, James Pearson
no flags Details | Diff

Description James Pearson 2007-07-23 11:53:54 UTC
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:

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):


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()
Actual results:

ERROR: ld.so: object '/path/to/some.so' from LD_PRELOAD cannot be preloaded:

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

Comment 1 James Pearson 2007-07-23 11:53:54 UTC
Created attachment 159775 [details]
Patch to glibc to suppress LD_PRELOAD 'ERROR'

Comment 2 Jakub Jelinek 2007-07-23 12:06:32 UTC
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

Comment 3 James Pearson 2007-07-23 12:55:23 UTC
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

Comment 4 Jakub Jelinek 2007-07-23 13:07:45 UTC
$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).

Comment 5 John Drinkwater 2013-05-08 13:48:58 UTC
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?

Note You need to log in before you can comment on or make changes to this bug.