> 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).
It would be nice to declare the libraries that are used for both host and
target as
separate modules in the top level template (since we might want to build them
with different
configure options; e.g. there’s no real point in bootstrapping the host
libstdc++ as
a shared lib - pulling in its dependent libs - if we are only going to link
the .a).
Iain
(will check a cross-compiler build with the changes above).
> because HOST_LIB_PATH is
> appended to the TARGET_EXPORTS (we do not seem to make those depend on the
> stage).
>
> Iain
