> On 12 Feb 2024, at 19:59, Jason Merrill <ja...@redhat.com> wrote:
>
> On 2/10/24 07:30, Iain Sandoe wrote:
>>> 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.
>
> Ah, I see: When building target libraries in stage2, we run the stage2
> compiler that needs the stage1 libgcc_s, but we don't have the HOST_EXPORTS
> because we're building target code, so we also need to get the libgcc path
> into TARGET_EXPORTS.
>
> Since TARGET_LIB_PATH is only added when gcc-bootstrap, I guess the previous
> libgcc is the only piece needed in TARGET_EXPORTS as well. So, how about
> this version of the patch?
I tested this one on an affected platform version with and without
—enable-host-shared and for all languages (less go which is not yet supported).
It works for me, thanks,
Iain
>
> Jason<0001-build-drop-target-libs-from-LD_LIBRARY_PATH-PR105688.patch>
