Hi Jason, I have tested this on modern Darwin (with libc++ as the system library) and on older Darwin, where we do see the issue - because the system linker is written in C++ and links with libstdc++ (so sometimes we get a crash, or worse unpredictable beahviour).
----- For modern Darwin [ > macOS 10.11] , there’s no issue seen so far, but for older Darwin…. > On 8 Feb 2024, at 05:36, Alexandre Oliva <ol...@adacore.com> wrote: > > 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? … I have done all but “go” since that’s not supported on Darwin. The patch breaks bootstrap on older Darwin because: Ada uses exceptions. gnat1 pulls in system libraries that link with the system unwinder - so we have to link gnat1 “-shared-libgcc” - which means we need to be able to find the just-built one when building the target libs. - that means we need to find it as a host library, which we were getting away with because the host list was appended to the target list. To recover bootstrap I think the following addition is needed: diff --git a/Makefile.tpl b/Makefile.tpl index cb39fbd0434..65621bf6882 100644 --- a/Makefile.tpl +++ b/Makefile.tpl @@ -663,7 +663,7 @@ TARGET_LIB_PATH_[+module+] = $$r/$(TARGET_SUBDIR)/[+module+]/[+lib_path+]: # so that programs built for the host machine work. HOST_LIB_PATH = [+ FOR host_modules +][+ IF lib_path +]$(HOST_LIB_PATH_[+module+])[+ ENDIF lib_path +][+ - ENDFOR host_modules +] + ENDFOR host_modules +]$(HOST_LIB_PATH_gcc) # Define HOST_LIB_PATH_gcc here, for the sake of TARGET_LIB_PATH, ouch @if gcc It’s not clear to me why we consider prev-gcc as relevant to host libgcc (we must have built libgcc in order to have linked it to any host deps .. but perhaps I’m missing a case). I agree with the sentiment below that this is a delicate area…. > 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
