Date: Thu, 9 Mar 2000 23:10:39 +0100
From: Andreas Schwab <[EMAIL PROTECTED]>
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
|> Date: Thu, 9 Mar 2000 11:50:59 -0800
|> From: "H . J . Lu" <[EMAIL PROTECTED]>
|>
|> 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.
Thanks for the explanation.
I'm still surprised by something here. The error message which
H.J. cites is from libiberty/pexecute.c. That means that the exec
which should start the shell script is failing. The case is precisely
identical from the point of view of gcc, and the shell script is never
actually executed. That means that somewhere inside the kernel, when
it tries to execute the shell script, it is running out of memory.
Executing a shell script does use a bit more memory, but only just
enough for "/bin/sh" and the name of the script to execute. If that
is pushing H.J. over the memory limit, then he must have been
extremely close to that limit to start with.
For that matter, I actually didn't think that the Linux kernel had an
argument size limit.
So I think more investigation is warranted.
Ian
