This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
LD_PRELOAD (was Re: EI_DATA and different byte order)
- From: Peter Bergner <bergner at brule dot borg dot umn dot edu>
- To: GNU C Library <libc-alpha at sources dot redhat dot com>
- Date: Tue, 28 May 2002 11:27:18 -0500
- Subject: LD_PRELOAD (was Re: EI_DATA and different byte order)
- References: <20020508162146.A10833@lucon.org>
On Wed, May 08, 2002 at 04:21:46PM -0700, H . J . Lu wrote:
: I think ld.so should skip and keep searching, like what we do for
: EI_CLASS and e_machine.
This reminds me of a question. I'm on a PPC64 Linux box which
supports both ppc32/elf32 apps and ppc64/elf64 apps and I see that
both ld.so's correctly skip any libraries they happen to come across
while searching LD_LIBRARY_PATH with the wrong EI_CLASS or e_machine.
However, if I place a library in LD_PRELOAD which has the wrong EI_CLASS
and e_machine than I get the following error:
brule% LD_DEBUG=libs LD_PRELOAD=/lib/libc.so.6 ./hello-elf64
./hello-elf64: error while loading shared libraries: /lib/libc.so.6: cannot open shared object file: No such file or directory
or:
brule% LD_DEBUG=libs LD_PRELOAD=/lib64/libc.so.6 ./hello-elf32
./hello-elf32: error while loading shared libraries: /lib64/libc.so.6: cannot open shared object file: No such file or directory
Is this "working as designed", other than the inaccurate error message,
or should we be silently skipping the libraries with the wrong EI_CLASS
and e_machine like we do with LD_LIBRARY_PATH?
An example I can think of is something like dante where we preload
the dante library by placing a:
export LD_PRELOAD /lib/libdsocks.so
in /etc/profile. However on our PPC64 Linux box, we'd want something
closer to:
export LD_PRELOAD /usr/lib/libdsocks.so:/usr/lib64/libdsocks.so
Peter