On 2/14/24 18:33, Iain Sandoe wrote: > >> On 14 Feb 2024, at 22:59, Iain Sandoe wrote: > >>> On 12 Feb 2024, at 19:59, Jason Merrill wrote: >>> >>> On 2/10/24 07:30, Iain Sandoe wrote: >>>>> On 10 Feb 2024, at 12:07, Jason Merrill wrote: >>>>> >>>>> On 2/10/24 05:46, Iain Sandoe wrote: >>>>>>> On 9 Feb 2024, at 23:21, Iain Sandoe wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 9 Feb 2024, at 10:56, Iain Sandoe wrote: >>>>>>>>> On 8 Feb 2024, at 21:44, Jason Merrill 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?