> On 10 Feb 2024, at 12:07, Jason Merrill <ja...@redhat.com> wrote:
>
> On 2/10/24 05:46, Iain Sandoe wrote:
>>> On 9 Feb 2024, at 23:21, Iain Sandoe <idsan...@googlemail.com> wrote:
>>>
>>>
>>>
>>>> On 9 Feb 2024, at 10:56, Iain Sandoe <idsan...@googlemail.com> wrote:
>>>>> 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.
>>>
>>> The fail is occurring in the target libada build; so, I suppose, one might
>>> say it’s reasonable that it
>>> requires this host path to be added to the target exports since it’s a host
>>> library used during target
>>> builds (or do folks expect the host exports to be made for target lib
>>> builds as well?)
>>>
>>> Appending the prev-gcc dirctory to the HOST_LIB_PATH fixes this
>> Hmm this is still not right, in this case, I think it should actually be the
>> “just built” directory;
>> - if we have a tool that depends on host libraries (that happen to be also
>> target ones),
>> then those libraries have to be built before the tool so that they can be
>> linked to it.
>> (we specially copy libgcc* and the CRTs to gcc/ to allow for this case)
>> - there is no prev-gcc in cross and —disable-bootstrap builds, but the tool
>> will still be
>> linked to the just-built host libraries (which will also be installed).
>> So, I think we have to add HOST_LIB_PATH_gcc to HOST_LIB_PATH
>> and HOST_PREV_LIB_PATH_gcc to POSTSTAGE1_HOST_EXPORTS (as per this patch).
>
> I don't follow. In a cross build, host libraries are a different
> architecture from target libraries, and certainly can't be linked into host
> binaries.
>
> In a disable-bootstrap build, even before my change TARGET_LIB_PATH isn't
> added to RPATH_ENVVAR, since that has been guarded with @if gcc-bootstrap.
>
> So in a bootstrap build, it shouldn't be needed for stage1 either. And for
> stage2, the one we need is from stage1, that matches the compiler we're
> building host tools with.
>
> What am I missing?
nothing, I was off on a tangent about the cross/non-bootstrap, sorry about that.
However, when doing target builds (the previous point) it seems we do have to
make provision for gnat1 to find libgcc_s, and, at present, it seems that only
the target exports are active.
Iain
> Jason
