Re: [PATCH]: ld/Makefile.am

[Ian Lance Taylor <ian at zembu dot com>]

   Date: Thu, 9 Mar 2000 23:10:39 +0100
   From: Andreas Schwab <schwab@suse.de>

   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.

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