> 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-*“
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).
I can see we need to add any paths to shared libraries used by the host tools
(so that, perhaps, we’ll need to add libgrust if the rust FE uses that) but,
otherwise AFAIK, the only [shared] target library used by the host tools is
libgcc_s (when gnat1 needs it) - otherwise we default to static linking of
libstdc++ and libgcc (and the gnat* tools link libgnat statically too) ?
>> Does it work on Darwin?
I’ll kick off a run shortly - know later this evening.
Iain
>
> Oops, that was broken, please consider this one instead:
>
> <0001-build-add-prev-target-libs-to-rpath.patch>
