This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: PR bootstrap/35752: Combined gcc + binutils source tree doesn't bootstrap
The patch was made for 133636 but still applies to trunk. It's small
enough that you can apply it by hand, I think, if problems continue. All
the three files are in gcc/ of course.
It doesn't work. stage 2 ld-new shell script still calls itself to
create .libs/lt-ld-new.
Here is what I'm going to commit as soon as bootstrap finishes (but it
has already created stage2 lt-ld-new, so it works).
Paolo
2008-04-01 Paolo Bonzini <bonzini@gnu.org>
* Makefile.in (objdir): Set it here.
* configure.ac: Not here. Find dynamic linker characteristics.
* exec-tool.in: Use them.
* aclocal.m4: Regenerate.
* configure: Regenerate.
Index: Makefile.in
===================================================================
--- Makefile.in (revision 133636)
+++ Makefile.in (working copy)
@@ -79,9 +79,8 @@ abs_docdir = @abs_srcdir@/doc
# Top build directory for this package, relative to here.
top_builddir = .
-# objdir is set by configure.
-# It's normally the absolute path to the current directory.
-objdir = @objdir@
+# The absolute path to the current directory.
+objdir := $(shell pwd)
host_subdir=@host_subdir@
build_subdir=@build_subdir@
Index: configure.ac
===================================================================
--- configure.ac (revision 133636)
+++ configure.ac (working copy)
@@ -1817,6 +1817,21 @@ esac
# Assembler & linker features
# ---------------------------
+# During stage 2, ld is actually gcc/collect-ld, which is a small script to
+# discern between when to use prev-ld/ld-new and when to use ld/ld-new.
+# However when ld-new is first executed from the build tree, libtool will
+# relink it as .libs/lt-ld-new, so that it can give it an RPATH that refers
+# to the build tree. While doing this we need to use the previous-stage
+# linker, or we have an infinite loop. The presence of a shell script as
+# ld/ld-new, and the fact that the script *uses ld itself*, is what confuses
+# the gcc/collect-ld script. So we need to know how libtool works, or
+# exec-tool will fail.
+
+m4_defun([_LT_CONFIG_COMMANDS], [])
+AC_PROG_LIBTOOL
+AC_SUBST(objdir)
+AC_SUBST(enable_fast_install)
+
# Identify the assembler which will work hand-in-glove with the newly
# built GCC, so that we can examine its features. This is the assembler
# which will be driven by the driver program.
@@ -3714,9 +3729,6 @@ else
fi)
AC_SUBST(slibdir)
-objdir=`${PWDCMD-pwd}`
-AC_SUBST(objdir)
-
AC_ARG_WITH(datarootdir,
[ --with-datarootdir=DIR Use DIR as the data root [[PREFIX/share]]],
datarootdir="\${prefix}/$with_datarootdir",
Index: aclocal.m4
===================================================================
--- aclocal.m4 (revision 133636)
+++ aclocal.m4 (working copy)
@@ -105,4 +105,8 @@ m4_include([../config/lib-link.m4])
m4_include([../config/lib-prefix.m4])
m4_include([../config/progtest.m4])
m4_include([../config/warnings.m4])
+m4_include([../libtool.m4])
+m4_include([../ltoptions.m4])
+m4_include([../ltsugar.m4])
+m4_include([../ltversion.m4])
m4_include([acinclude.m4])
Index: exec-tool.in
===================================================================
--- exec-tool.in (revision 133636)
+++ exec-tool.in (working copy)
@@ -23,6 +23,8 @@ ORIGINAL_AS_FOR_TARGET="@ORIGINAL_AS_FOR
ORIGINAL_LD_FOR_TARGET="@ORIGINAL_LD_FOR_TARGET@"
ORIGINAL_NM_FOR_TARGET="@ORIGINAL_NM_FOR_TARGET@"
exeext=@host_exeext@
+fast_install=@enable_fast_install@
+objdir=@objdir@
invoked=`basename "$0"`
case "$invoked" in
@@ -50,7 +52,23 @@ case "$original" in
scriptdir=`cd "$tdir" && pwd`
if test -x $scriptdir/../$dir/$prog; then
- exec $scriptdir/../$dir/$prog ${1+"$@"}
+ test "$fast_install" = yes || exec $scriptdir/../$dir/$prog ${1+"$@"}
+
+ # if libtool did everything it needs to do, there's a fast path
+ lt_prog=$scriptdir/../$dir/$objdir/lt-$prog
+ test -x $lt_prog && exec $lt_prog ${1+"$@"}
+
+ # libtool has not relinked ld-new yet, but we cannot just use the
+ # previous stage (because then the relinking would just never happen!).
+ # So we take extra care to use prev-ld/ld-new *on recursive calls*.
+ test -f $lt_prog-recursive && exec $scriptdir/../prev-$dir/$prog ${1+"$@"}
+
+ touch $lt_prog-recursive
+ $scriptdir/../$dir/$prog ${1+"$@"}
+ result=$?
+ rm -f $lt_prog-recursive
+ exit $result
+
else
exec $scriptdir/../prev-$dir/$prog ${1+"$@"}
fi