This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: ld: warning: ld-linux.so.2, needed by /lib/libc.so.6, not found
- From: Kai Ruottu <karuottu at mbnet dot fi>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: Ron Arts <ron dot arts at neonova dot nl>, binutils at sources dot redhat dot com
- Date: Sun, 27 Apr 2003 15:20:03 +0300
- Subject: Re: ld: warning: ld-linux.so.2, needed by /lib/libc.so.6, not found
- References: <3EAA9A03.1060503@neonova.nl> <20030426223314.GA4057@nevyn.them.org>
- Reply-to: kai dot ruottu at luukku dot com
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