This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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]

Re: How to make an application look somewhere other than /lib forld-linux.so.2


Kai Ruottu kirjoitti:
Mark Cuss kirjoitti:
So - the question is: How do I do this? Even though LD_LIBRARY_PATH points to ./ as it's first entry, ldd still looks in /lib first for ld-linux.so.2. I've tried the rpath option to ld at link time, but that doesn't work either. It seems that thing is somehow hardcoded to look in /lib for this library.

Seems that also I must learn to read much better!!! Not thinking that "others cannot ever even read". Not very good results yet got... My apologies for not reading what Mark wrote!!!

 So '-rpath' was tried but not yet the '-dynamic-linker', which must
be used for the 'ld-linux.so.2', 'ld.so.1' or something depending on
the Linux, SVR4 etc. variation...

 Finding the "dynamic linker", "program interpreter" or whatever the
official name then is, from the right place at runtime can be a problem,
but it is also a problem at linktime!!!  Here is my clue for those who
yet don't know how on earth the search place for those "NEEDED" shared
libraries (told inside other shared libraries being needed too when
linking) :

---------------------- clip ----------------------
F:\usr\local\i486-linux-gnu\bin>ld -verbose

GNU ld version 2.10.1 (with BFD 2.10.1)
  Supported emulations:
   elf_i386
   i386linux
using internal linker script:
==================================================
OUTPUT_FORMAT("elf32-i386", "elf32-i386",
              "elf32-i386")
OUTPUT_ARCH(i386)
ENTRY(_start)
 SEARCH_DIR(/usr/local/i486-linux-gnu/lib);
/* Do we need any of these for elf?
   __DYNAMIC = 0;    */
SECTIONS
---------------------- clip ----------------------

 The "SEARCH_DIR" told in the internal linker script seems to be the
place where the stuff will be searched...

 Sometimes there was a bug in this and using '-rpath-link' was
obligatory.  Nowadays there can be a problem with the bi-arch
(64/32-bit) targets like 'x86_64-linux-gnu', using '-m elf_i386'
in the linker command gives something like :

---------------------- clip ----------------------
GNU ld version 020322 20020322
  Supported emulations:
   elf_x86_64
   elf_i386
   i386linux
using internal linker script:
==================================================
/* Default linker script, for normal executables */
OUTPUT_FORMAT("elf32-i386", "elf32-i386",
              "elf32-i386")
OUTPUT_ARCH(i386)
ENTRY(_start)
 SEARCH_DIR("/usr/local/i386-linux-gnu/lib");
---------------------- clip ----------------------

 So the linker was made for 'x86_64-linux-gnu' but it searches from
'.../i386-linux-gnu/lib' for the 32-bit 'ld-linux.so.2' at linktime.
Who could have guessed this?

I haven't though checked how the uptodate linkers behave...


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