> On 16 Feb 2024, at 21:05, Jason Merrill <ja...@redhat.com> wrote:
>
> On 2/14/24 18:33, Iain Sandoe wrote:
>>> On 14 Feb 2024, at 22:59, Iain Sandoe <idsan...@googlemail.com> wrote:
>>>> 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
>> Incidentally, during my investigations I was looking into various parts of
>> this and it seems that actually TARGET_LIB_PATH might well be effectively
>> dead code now.
>
> Good point. Could you test this version as well?
>
>
> <0001-build-drop-target-libs-from-LD_LIBRARY_PATH-PR105688.patch>
This also works for me on a number of darwin versions (including one that
actually needs libgcc_s to bootstrap),
thanks
Iain
