On Feb 6, 2024, Jason Merrill <ja...@redhat.com> wrote: > Reverting that hunk of the change fixed my problem with bubblestrapping GCC > 12 with ccache on a host with a newer system libstdc++.
Did you have libcc1, gnattools and gotools enabled in your testing? Those non-bootstrapped tools are most likely to be problem spots. I have a vague recollection that, in native scenarios, when bootstrapping but not when not boostrapping, they are (or used to be?) built using the just-built (last-stage) compiler and target libraries, rather than system tools or previous stage (which I believe would fail bootstrap-lean). Just by looking at the current code I can't bring back to mind all the involved moving parts :-/ but my guess is that the need for TARGET_LIB_PATH comes about for this combination of circumstances, in which we would need to use the just-built native-target libstdc++ to link or to run these host tools using the just-built tools. Having a newer system libstdc++ would, I suspect, unfortunately mask the problem that those who had an older or no system libstdc++ would likely run into. OTOH, if the system linker requires the newer system library, and ld.so and ld overload LD_LIBRARY_PATH for both the libraries loaded for ld to run, the libraries ld searches to link executables, and the libraries loaded for so-linked programs to run, we seem to need some means to distinguish between these three circumstances so as to be able to set LD_LIBRARY_PATH correctly for each one, whether the libstdc++ we're building is newer or older than the system one. And there's an added complication that any single ld invocation involves two different and potentially conflicting uses of LD_LIBRARY_PATH. /me runs screaming :-) Perhaps the best we can do out of these conflicting requirements is to somehow detect a system libstdc++ newer than the one we're about to build, and fail early if we find that some of the tools depend on the newer libstdc++, or disable this env var setting for this case only and hope the newer system library is compatible enough. Holy nightmare, Batman! :-) :-( Perhaps the way to go is an explicit configure setting, recommended by the fail early, to disable the env var setting? -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
