> On 8 Feb 2024, at 21:44, Jason Merrill <ja...@redhat.com> wrote:
>
> On 2/8/24 12:55, Paolo Bonzini wrote:
>> On 2/8/24 18:16, Jason Merrill wrote:
>>>>>
>>>>
>>>> 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? Does it work on Darwin?
>>>
>>> Oops, that was broken, please consider this one instead:
>> Yes, this one makes sense (and the current code would not work since it
>> lacks the prev- prefix on TARGET_LIB_PATH).
>
> Indeed, that seems like evidence that the only element of TARGET_LIB_PATH
> that has been useful in HOST_EXPORTS is the prev- part of HOST_LIB_PATH_gcc.
>
> So, here's another patch that just includes that for post-stage1:
> <0001-build-drop-target-libs-from-LD_LIBRARY_PATH-PR105688.patch>
Hmm this still fails for me with gnat1 being unable to find libgcc_s.
It seems I have to add the PREV_HOST_LIB_PATH_gcc to HOST_LIB_PATH for it to
succeed so,
presumably, the post stage1 exports are not being forwarded to that build.
I’ll try to analyze what
exactly is failing.
Iain
