> On 21 Feb 2024, at 23:06, Jason Merrill <ja...@redhat.com> wrote:
>
> 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’ll try that on darwin and aarch64 linux (I quite often need to use
bootstrap-lean on the latter becuase of low disk space).
>> 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.
Unless we change to (or add) a bootstrap where we use shared libstdc++ in the
compiler, I think that is the case.
As I mentioned in an earlier post, unfortunately we do not yet have a way to
distinguish module builds for host from module builds for target (when a
library is used for both - which is the case for libstdc++, libbacktrace and
libgrust at least), This means that either the target library has to be built
without a shared version (libbacktrace does this), or the host versions get
built with a shared library which is not used (libstdc++) .. AFAICT the only
reason we build libgomp and libatomic in bootstrap phase 1 and 2 is because
they are dependents of the unused shared libstdc++.
Ideally, we’d fix Makefile.{tpl,def} to allow the same module to have different
recipies for host and target builds, but that’s also not a 5 minute hack….
> 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.
Which could also be improved (we do not in Dejagnu really distinguish runpaths
needed by the compiler from those needed by the built executables)
> 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.
there’s actually a fair amount of specific code to locate dependent libs in
places (some of which I just cleaned up a bit since it was now causing fails
with Darwin’s new linker complaining about duplicated libs and so on). So we
are not currently expecting this information to be passed down.
> 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.
+1
>
>
>> 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<0001-lean.patch>
Iain
