This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

LD_PRELOAD (was Re: EI_DATA and different byte order)


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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]