This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


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

Re: linker search directories


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.



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