This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix libcpp dependency generation for toplevel bootstrap
On Sat, Dec 17, 2005 at 08:08:17PM +0100, Gabriel Dos Reis wrote:
> | A couple of points here:
> | - We should be using the limits.h in the build tree, not the one in
> | the install tree, during a bootstrap. That would fix this.
I did not think this through thoroughly enough. It's a little more
complicated. Here's the limits.h dependencies for a stage2 libcpp:
/space/fsf/objects/installs2/./prev-gcc/include/limits.h
/space/fsf/objects/installs2/./prev-gcc/include/syslimits.h
/space/fsf/objects/my-inst/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/include/limits.h
/usr/include/limits.h
The first one includes the second one to get _LIBC_LIMITS_H. The
second one uses #include_next. #include_next pushes us through the
"installed" limits.h before taking us to /usr/include. So as long as
we search the installed directory at all, we're going to continue to
have this problem.
In the long term, I hope we won't be searching that install directory.
What I want to do is have an "installed" directory in the build tree
for each stage, corresponding to the current prev-gcc directory.
Instead of running the compiler from its build directory we'll run it
from something that looks like an install tree, and let the relocatable
prefix code sort out everything else. This will simplify things
immensely.
But we're not ready for that change yet. In the mean time, I think
that we should go with Paolo's change: update any directories which use
-MD to rely on -MMD if available. Looks like boehm-gc, fastjar,
libcpp, libffi, libjava, libmudflap, and libssp are all affected - most
of them pull it in through automake, though, so I don't know how we'll
be able to fix it. But libcpp is easy to fix.
> | - We should be passing appropriate flags to 'make install' so that
> | the correct compiler is found when this happens. That would
> | "fix" this - libcpp would still be rebuilt, but it would be
> | rebuilt correctly.
This is a different issue. Here's a patch which fixes it; a change in
the timestamp of the installed limits.h still causes libcpp and
libmudflap to be rebuilt on "make install", but now libcpp uses the
right compiler.
OK for HEAD?
--
Daniel Jacobowitz
CodeSourcery, LLC
2005-12-17 Daniel Jacobowitz <dan@codesourcery.com>
* Makefile.tpl (install-[+module+]): Use the correct compiler
for bootstrapped host modules.
* Makefile.in: Regenerated.
Index: Makefile.tpl
===================================================================
--- Makefile.tpl (revision 108721)
+++ Makefile.tpl (working copy)
@@ -931,9 +931,21 @@
@: $(MAKE); $(unstage)
@r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
+[+ IF bootstrap +]
+ if test -x $$r/$(HOST_SUBDIR)/prev-gcc/xgcc$(exeext); then \
+ $(POSTSTAGE1_HOST_EXPORTS) \
+ (cd $(HOST_SUBDIR)/[+module+] && \
+ $(MAKE) $(POSTSTAGE1_FLAGS_TO_PASS) [+extra_make_flags+] install); \
+ else \
+ $(HOST_EXPORTS) \
+ (cd $(HOST_SUBDIR)/[+module+] && \
+ $(MAKE) $(FLAGS_TO_PASS) [+extra_make_flags+] install); \
+ fi; \
+[+ ELSE +]
$(HOST_EXPORTS) \
(cd $(HOST_SUBDIR)/[+module+] && \
$(MAKE) $(FLAGS_TO_PASS) [+extra_make_flags+] install)
+[+ ENDIF bootstrap +]
[+ ENDIF no_install +]
@endif [+module+]