ld: warning: ld-linux.so.2, needed by /lib/libc.so.6, not found

[Kai Ruottu]

> On Fri, Apr 18, 2003 at 04:33:13PM -0500, Rocha Iran-QIR001 wrote:
>
>> In order for the cross-compiler to work, I need to use a libc.so
>> file that looks like this:
>>
>> /* GNU ld script
>>   Use the shared library, but some functions are only in
>>   the static library, so try that secondarily.  */
>> GROUP ( libc.so.6.1 libc_nonshared.a ld-linux-ia64.so.2 )

> On Sat, Apr 26, 2003 at 04:38:59PM +0200, Ron Arts wrote:
> 
>>We are creating a chrooted development environment, and
>>have the above error report when issuing the following command:
>>
>># cc -o nbs-bbnet nbs-bbnet.c
>>ld: warning: ld-linux.so.2, needed by /lib/libc.so.6, not found (try 
>>using -rpath or -rpath-link)
>>
>>Now, ld is called as follows by `cc`:
>>
>>ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o nbs-bbnet
>> /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o
>> /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crti.o
>> /usr/lib/gcc-lib/i386-redhat-linux/2.96/crtbegin.o
>> -L/usr/lib/gcc-lib/i386-redhat-linux/2.96
>> -L/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../.. /tmp/gASdsdfggS
>> -lgcc -lc -lgcc /usr/lib/gcc-lib/i386-redhat-linux/2.96/crtend.o
>> /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crtn.o
>>
>>The funny thing is, when I add -rpath-link /lib to the above
>>statement, the linking succeeds. I guess something is wrong
>>in our setup, but how do I go about finding it?

Daniel Jacobowitz wrote:

> Probably ld doesn't think it's a native linker.  If it thinks it's a
> cross linker it will default tonot searching host directories, of
> course.

  As Iran wrote earlier, a cross-GCC user will be forced to list
those NEEDED shared libraries like the 'ld-linux.so.2' for 'libc.so.6',
or to add the '-rpath-link <library-dir>' into the 'specs' in order
to get the 'linked' shared libs unmentioned on the linker command
line to be found at link-time, although all the '-L' options are
there already. Usually the 'ld-linux.so.2' is exactly in the same
place ($prefix/$target/lib) as the 'libc.so.6' in a cross-GCC...

  So why the GNU linker cannot find the NEEDED/linked-stuff, in the
Iran's case:

H:\usr\local\ia64-linux-gnu\lib>..\bin\objdump -p libc.so.6.1

libc.so.6.1:     file format elf64-ia64-little
private flags = LE, ABI64
<snip>
Dynamic Section:
   NEEDED      ld-linux-ia64.so.2
   SONAME      libc.so.6.1
   INIT        0x39ee0
   FINI        0x1fe770

when the info in the libc.so.6.1 tells that linking against this
is also necessary ?

  I don't see any absolute '/lib' being in the name, so it is a
miracle that it will be searched from '/lib' in the native case.
If the linked shared library would have an absolute path in its
name, like:

H:\usr\local\mips-nec-sysv4.2MP\lib>..\bin\objdump -p libsocket.so

libsocket.so:     file format elf32-tradbigmips
<snip>
Dynamic Section:
   NEEDED      /usr/lib/libnsl.so
   0x70000005  0x2
   0x70000001  0x1
   0x70000006  0x5d000000

then not finding the linked one (here 'libnsl.so') could sound
more sane...

  So, why the 'linked' shared libraries are not found from the
normal search places (pointed with '-L') or not even from the
same place where the libraries needing them exist?  Ok, adding
the '-rpath-link <library-dir>' helps, but why adding it is
obligatory ?  On Windows/MinGW host not even this helps and
one must follow the method Iran used -- to excplicitly list
all the hided linked shared libs on the link command or in
the link scripts...

  For me, adding the '-rpath-link' into 'specs' in cross-GCCs
is not a serious issue, but generally a cross-GCC should work
with the same 'specs' as the native one (excluding all the
Solaris2 etc. targets with their '/usr/ccs/lib', '/usr/ucblib'
etc. absolute search places listed in the LIB_SPEC), or what?

Cheers, Kai