Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

For bugs related to Red Hat Enterprise Linux 4 product line. The current stable release is 4.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 249256

Summary:

ld.so too verbose when it can't LD_PRELOAD a 32 bit library on a 64 bit OS

Product:

Red Hat Enterprise Linux 4

Reporter:

James Pearson <james-p>

Component:

glibc

Assignee:

Jakub Jelinek <jakub>

Status:

CLOSED NOTABUG

QA Contact:

Brian Brock <bbrock>

Severity:

low

Docs Contact:

Priority:

low

Version:

4.4

CC:

fweimer, john

Target Milestone:

---

Target Release:

---

Hardware:

x86_64

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2007-07-23 12:06:32 UTC

Type:

---

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
Patch to glibc to suppress LD_PRELOAD 'ERROR'	none

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

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?