LD_PRELOAD (was Re: EI_DATA and different byte order)
Peter Bergner
bergner@brule.borg.umn.edu
Tue May 28 23:06:00 GMT 2002
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
More information about the Libc-alpha
mailing list