Date: Thu, 9 Mar 2000 20:50:34 -0800
From: "H . J . Lu" <[EMAIL PROTECTED]>
It was my mistake. It works. Here is a new patch for ld/Makefile.am.
Any objections?
2000-03-09 H.J. Lu <[EMAIL PROTECTED]>
* Makefile.am (stmp-run-ld): New target.
(all-am): Depend on it.
(clean-stmp-run-ld): New target.
(clean): Depend on it.
* Makefile.in: Rebuild.
Well, yes, I object. This doesn't make any sense to me. We shouldn't
have to put a weird rule in ld/Makefile.am because of an odd libtool
hack which causes trouble in a highly specific case. We should write
software that works. We shouldn't require strange hacks.
If we decide that for some odd reason we can't live without a hack, we
should put the hack in the place where we need it: when doing a
one-tree build with both ld and gcc, ideally only when using
--enable-shared. Note that your patch would appear to cause libtool
to relink the binary twice: once in the build directory and then again
when installing; this is not desirable in the normal case of building
and installing binutils.
That is, if you are using a Cygnus style top level Makefile, add a
rule like this to all-gcc:
# When configured with --enable-shared, libtool 1.3.4 creates
# a script in the build directory which automatically relinks
# the program to search for shared libraries in the build
# directory. Something about this process, as yet undetermined,
# causes an argument size overflow in some versions of GNU/Linux.
# This can be avoided by running the script, so we do that here.
# FIXME: This should be fixed in libtool.
if test -f ld/ld-new; then \
ld/ld.new >/dev/null 2>&1; \
else \
true; \
fi
Ian
