This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: linker search directories
- To: Ian Lance Taylor <ian at zembu dot com>
- Subject: Re: linker search directories
- From: Brendan John Simon <Brendan dot Simon at ctam dot com dot au>
- Date: Wed, 26 Jan 2000 22:28:44 +1100
- CC: binutils at sourceware dot cygnus dot com, crossgcc at sourceware dot cygnus dot com
- Organization: CTAM Pty Ltd
- References: <388E6475.FE3A64C5@ctam.com.au> <20000125164642.6443.qmail@daffy.airs.com>
- Reply-To: Brendan dot Simon at ctam dot com dot au
Ian Lance Taylor wrote:
> 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?
It definately is there. It may be a problem with using --prefix=/usr/local/gcc
when configurin glibc-2.1.2 ?
Maybe there is a bug with the linker ?
> 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?
At the moment I am building updated native tools, so that I can use them to build
the cross-tools.
> 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.
Maybe the -lc option causes it to override the --dynamic-linker option somehow ?
I added %{!rpath:-rpath /usr/local/gcc/lib} to my specs file and it now works
fine.
I would probably need to use the -rpath-link option for my cross-compiler if I
have similar problems.
Thanks,
Brendan Simon.