This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: linker search directories
- To: Brendan dot Simon at ctam dot com dot au
- Subject: Re: linker search directories
- From: Ian Lance Taylor <ian at zembu dot com>
- Date: 25 Jan 2000 11:46:42 -0500
- CC: binutils at sourceware dot cygnus dot com, crossgcc at sourceware dot cygnus dot com
- References: <388E6475.FE3A64C5@ctam.com.au>
Date: Wed, 26 Jan 2000 14:05:26 +1100
From: Brendan John Simon <Brendan.Simon@ctam.com.au>
I am trying to build a powerpc-linux cross-compiler from
binutils-2.9.5.0.24, gcc-2.95.2 and glibc-2.1.2 sources. I first want
to compile and install the native compiler from the above sources. I
have --prefix=/usr/local/gcc. The binutils, gcc and glibc compile went
fine. I can no longer compile simple test program after I install the
glibc files. I have tracked this down to the linker getting
ld-linux.so.2 from /lib instead of /usr/local/gcc/lib. I have changed
all the search paths in the linker scripts
(/usr/local/gcc/i586-pc-linux-gnu/lib/ldscripts/*) but I still have the
same problem. Using the --verbose option with ld, I can see it is using
a "built in" linker script which has /lib in its search path. I can get
the program to compile and run only if I use
"-Wl,-rpath,/usr/local/gcc/lib".
I shouldn't have to do this. Is there a way of not using the built in
linker script or changing it's default library search paths. I don't
think setting an environment variable is a very elegant solution (if it
is one).
I can't see anything in the specs file either. Only the
--dynamic-linker option. I have actually changed this to
/usr/local/gcc/lib/ld-linux.so.2.
On Linux systems, gcc normally passes a -dynamic-linker option to the
linker. You can see this when using the -v option. Why is this not
happening in your case?
You say that you are doing a cross link. In that case, the linker
should not have /lib in its search path. How did you configure the
linker? What -m option is the compiler passing to the linker?
For that matter, what -L options is the compiler passing to the
linker?
You say that -rpath fixes the problem, which suggests that
ld-linux.so.2 is not being pulled in explicitly, but is instead being
pulled in due to a reference from a shared library. If you are doing
a cross-link, you should probably be using -rpath-link, not -rpath.
There is no default for -rpath-link; I'm not sure offhand what the
default should be.
Ian