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: [PATCH]: ld/Makefile.am


Ian Lance Taylor <ian@zembu.com> writes:

|>    Date: Thu, 9 Mar 2000 11:50:59 -0800
|>    From: "H . J . Lu" <hjl@valinux.com>
|> 
|>    I know this patch doesn't look very clean. But I don't know automake
|>    well enough to make it better. Here is the problem I am trying to fix.
|>    I got:
|> 
|>    # /work/ia64/bin/cygnus/20000303/gcc/xgcc -B/usr/ia64-cygnus-linux/ia64-cygnus-linux/bin/ -B/usr/ia64-cygnus-linux/ia64-cygnus-linux/lib/ -B/work/ia64/bin/cygnus/20000303/gcc/ -g -O2 -pipe -Dno_inhibit_libc -fvtable-thunks -D_GNU_SOURCE -fno-implicit-templates -fexceptions -Wl,-soname,libstdc++-libc6.1-2.so.3 -shared -o libstdc++-3-libc6.1-2-2.10-ia64-000216.so `cat piclist` -lm
|>    gcc: installation problem, cannot exec
|>    `/work/ia64/bin/cygnus/20000303/gcc/collect2': Argument list too long
|> 
|>    What happened were
|> 
|>    1. I built as, ld, gcc, and libstdc++ together.
|>    2. I enabled shared libbfd.
|> 
|>    As the result, ./ld/ld-new, which is a shell script, uses too many
|>    arguments when it was executed the first time. The first time when
|>    you run ./ld/ld-new, it creates .libs/lt-lt-ld-new if shared libbfd
|>    is enabled. After that, everything seems ok. I am trying to add a
|>    rule to ld/Makefile.am such that we will run ./ld/ld-new just once
|>    after it is built. I don't care if it really works or not. The idea
|>    is to create .libs/lt-lt-ld-new if necessary. However, I couldn't
|>    find a clean way to do so with automake. Any suggestions?
|> 
|> This sounds like a libtool bug.  Why fix it in binutils or automake?
|> Whatever it is ld-new does the first time it is run, why doesn't
|> libtool do that when it creates ld-new?

Because the executable that libtool creates (.libs/ld-new) is meant to be
installed, but when you want to run it in the build directory you want to
make sure that it finds the shared libraries in the build directory, not
the ones that may be installed earlier.  To achieve this, libtool relinks
the binary with a special set of --rpath options pointing into the build
directory.  This is done everytime the actual binary is rebuilt.  There is
an option to libtool (--disable-fast-install) that tells it to do the
relinking at install time, and the binary in the build directory is built
with the appropriate --rpath options in the first place.  All this is
required because --rpath has precedence over LD_LIBRARY_PATH.  On systems
were it doesn't libtool just uses LD_LIBRARY_PATH to achieve the same
effect.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

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