> 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. Outside of the top level Makefile, it is referred to by libgm2 and libgrust top level Makefile.am (as a passed-on flag), however AFAICT it is not exported from the top level Makefile (so, I assume that those references are also unused). Iain > > >> >> Jason<0001-build-drop-target-libs-from-LD_LIBRARY_PATH-PR105688.patch>
