> On 8 Feb 2024, at 19:25, Jason Merrill <ja...@redhat.com> wrote:
>
> On 2/8/24 12:51, Iain Sandoe wrote:
>>> On 8 Feb 2024, at 17:16, Jason Merrill <ja...@redhat.com> wrote:
>>>
>>> On 2/8/24 12:12, Jason Merrill wrote:
>>>> On 2/8/24 10:04, Iain Sandoe wrote:
>>>>> Hi Jason,
>>>>>
>>>>> I have tested this on modern Darwin (with libc++ as the system library)
>>>>> and on
>>>>> older Darwin, where we do see the issue - because the system linker is
>>>>> written
>>>>> in C++ and links with libstdc++ (so sometimes we get a crash, or worse
>>>>> unpredictable
>>>>> beahviour).
>>>> Thank you!
>>>>> -----
>>>>>
>>>>> For modern Darwin [ > macOS 10.11] , there’s no issue seen so far, but
>>>>> for older Darwin….
>>>>>
>>>>>> On 8 Feb 2024, at 05:36, Alexandre Oliva <ol...@adacore.com> wrote:
>>>>>>
>>>>>> On Feb 6, 2024, Jason Merrill <ja...@redhat.com> wrote:
>>>>>>
>>>>>>> Reverting that hunk of the change fixed my problem with bubblestrapping
>>>>>>> GCC
>>>>>>> 12 with ccache on a host with a newer system libstdc++.
>>>>>>
>>>>>> Did you have libcc1, gnattools and gotools enabled in your testing?
>>>>>
>>>>> … I have done all but “go” since that’s not supported on Darwin.
>>>>>
>>>>> The patch breaks bootstrap on older Darwin because:
>>>>>
>>>>> Ada uses exceptions.
>>>>> gnat1 pulls in system libraries that link with the system unwinder
>>>>> - so we have to link gnat1 “-shared-libgcc”
>>>>> - which means we need to be able to find the just-built one when
>>>>> building the target libs.
>>>> Hmm. In stage 1, when we build with the system gcc, I'd think we want the
>>>> just-built gnat1 to find the system libgcc.
>>>> In stage 2, when we build with the stage 1 gcc, we want the just-built
>>>> gnat1 to find the stage 1 libgcc.
>>>> In neither case do we want it to find the libgcc from the current stage.
>>>> So it seems to me that what we want is for stage2+ LD_LIBRARY_PATH to
>>>> include the TARGET_LIB_PATH from the previous stage. Something like the
>>>> below, on top of the earlier patch.
>>>> Does this make sense?
>> Yes in terms of me mixing up “just built” and “prev-*“
>
> I've been unclear about that myself.
>
>> However, IIUC this still means we’re adding LD_LIBRARY_PATHs for each target
>> library, including libstdc++ (so I’m not sure if it solves the problem that
>> I’d seen before).
>
> Yes, after stage 1.
>
> You're right that we won't need all of the stage1 target libraries to run the
> stage2 compiler. But if your gnat1 is linked with shared libgcc, isn't also
> linked with shared libstdc++, so it would need to find the stage1 libstdc++?
No, we continue to link with -static-libstdc++ (the only reason we use shared
libgcc is to avoid two unwinders in the same process, which never ends well -
usually gnat1 hangs)
> In general, though, it would make sense to decide whether to include both
> libgcc and libstdc++ based on with_static_shared_libraries. And likewise the
> other language runtimes (libada, libgfortran, ...)?
Right now, AFAIK the only target runtimes used by host tools are libstdc++,
libgcc and libgnat. I agree that might change with rust - since the rust folks
are talking about using one of the runtimes in the FE, I am not aware of other
language FEs requiring their targte runtimes to be available to the host tools
(adding Gaius in case I missed something with m2 - which is quite complex inthe
bootstrapping).
linking these shared would seem to me to be placing additional constraints on
the build that are likely to take some shaking down - personally, I much prefer
a toolchain with no shared deps - since then one knows what was tested is not
going to change in reponse to some DSO update.
> We probably don't need libgomp/libatomic/libitm?
unless/until we have multiple threads in the compiler(s), it seems unlikely,
indeed
> libsanitizer/vtv/ssp should only be needed for a bootstrap using those
> hardening options.
Ah, now in that case we probably _do_ need to force shared libstdc++ (since the
sanitizers link against c++ lib)
- an alternative is to force all of libstdc++.a to be included in the host
tools, and use that to provide the symbols,
> If your stage2 gnat1 does need the stage1 libstdc++ and you're also using the
> system ld that needs the system libstdc++, that seems to call for another
> approach discussed on the PR: have exec-tool.in splice out the build
> directory from LD_LIBRARY_PATH when calling a tool from outside the build
> directory.
I’ve done all sorts of dances with this - e.g. linking the ld with a
specially-named libstdc++ (or forcing the linker to be statically linked -
although that creates a secondary problem since the Darwin libLTO (for clang)
is also linked against c++)
Iain
>
> Jason
