> On 21 Feb 2024, at 23:36, Iain Sandoe <idsan...@googlemail.com> wrote:
>
>> 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 tested this addition with bootstrap-lean on i686-darwin9 (needs libgcc_s to
boostrap), x86_64-darwin21/23 (does not use libstdc++ in the system) ..
aarch64-linux-gnu
.. and it worked OK.
Note that the testsuite does still have some glitches with bootstrap-lean (but
those are independent of this patch).
(we really need to adapt the idea of “host compiler/plugin compiler” to be the
stage3 one when we bootstrap-lean).
Iain
>
>>> 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
