On 2/20/24 00:45, Alexandre Oliva wrote:
On Feb 16, 2024, Jason Merrill <ja...@redhat.com> wrote:
So, for stage2+, let's add just prev- libgcc.
I'm pretty sure this will break bootstrap-lean where libgcc_s isn't a
system library, and we're building post-bootstrap host tools :-(
We need the current stage lib after the prev stage is removed.
That's a good point, we should make sure it doesn't break. It looks to
me like stage3-bubble removes stage1 after we're done building stage3,
which should be fine, but compare removes the stage2 libgcc that we
might still need to run stage3. So indeed I guess we still want both
prev and current libgcc directories in RPATH to handle the case where
we've removed the previous stage, as below.
I also doubt that TARGET_LIB_PATH was defined and used for no reason.
My hunch is that bootstrap options and/or targets that don't have these
libraries as system libraries will break in some obscure way without it.
But I don't have the bandwidth to track down the history behind their
inclusion.
That has not seemed to be the case in Iain's testing on a system without
these libraries as system libraries.
I can't think of why we would need to depend on the current stage target
libraries, and we already weren't depending on the previous stage target
libraries. I believe the only target code we run is tests, and if the
tests need the target libraries in RPATH that should happen in the
testsuite.
It's arguable that we should pass TARGET_LIB_PATH down to make it easier
for the testsuites to find them, in case they are currently relying on
them being part of RPATH. My impression from Iain's testing is that
this isn't actually needed. I wouldn't mind keeping TARGET_LIB_PATH
unused, but I'm not sure why that would be better than bringing it back
if we turn out to need it.
I insist that the entire approach of choosing the same set of target
library directories regardless of the freshness relationship between
e.g. a system libstdc++ and the one we're building can't possibly be an
overall improvement, it's only trading problems in some scenarios (where
we're building an older libstdc++) for problems in other scenarios
(where we're building a newer libstdc++). The latter is unfortunately
far more likely, which is reason enough for the current arrangement, but
libstdc++ problems will likely only hit if the gap between system and
being-built libraries is large enough (say, new symbols in the newer
libstdc++ used by the compiler, but not available in the system
library).
If bootstrap doesn't actually need the target libraries, as seems to be
the case, then I think removing them from RPATH trades the former
problem for no problem.
I'm really uncomfortable with this change, especially at this stage.
I'd much rather have a relatively obscure workaround for this relatively
obscure problem, while keeping the defaults that have accumulated lots
of testing on lots of configurations.
I'm happy to defer this change to GCC 15 stage 1.
An idea that occurred to me is to have some configure option or just a
make variable that would be prepended to RPATH_ENVVAR, so that it would
preempt TARGET_LIB_PATH. That would be a far more conservative change,
that I think we could make even at this stage. WDYT?
I'm hoping for a fix that doesn't require individual users to know about
a workaround.
Jason
From 5312d534f1724c106feabebc9fdfa99e3717f859 Mon Sep 17 00:00:00 2001
From: Jason Merrill <ja...@redhat.com>
Date: Wed, 21 Feb 2024 23:03:36 +0000
Subject: [PATCH] lean
To: gcc-patches@gcc.gnu.org
ChangeLog:
* Makefile.tpl:
---
Makefile.tpl | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/Makefile.tpl b/Makefile.tpl
index e3de2a7ba3b..674a6d7c711 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -650,10 +650,12 @@ HOST_LIB_PATH = [+ FOR host_modules +][+
IF lib_path +]$(HOST_LIB_PATH_[+module+])[+ ENDIF lib_path +][+
ENDFOR host_modules +]$(HOST_LIB_PATH_gcc)
-# libgcc is a target library in the current stage and a host library
-# in the previous stage (when bootstrapping).
+# When bootstrapping, the previous stage libgcc is a host library. But with
+# bootstrap-lean we might remove the previous libgcc and still want to run the
+# current gcc that depends on it, so let's also include the current stage
+# libgcc to accommodate that situation.
@if gcc-bootstrap
-HOST_LIB_PATH_gcc = $$r/$(HOST_SUBDIR)/prev-gcc$(GCC_SHLIB_SUBDIR):
+HOST_LIB_PATH_gcc = $$r/$(HOST_SUBDIR)/prev-gcc$(GCC_SHLIB_SUBDIR):$$r/$(HOST_SUBDIR)/gcc$(GCC_SHLIB_SUBDIR):
@endif gcc-bootstrap
[+ FOR host_modules +][+ IF lib_path +]
--
2.43.0
