On 2/8/24 12:51, Iain Sandoe wrote:
On 8 Feb 2024, at 17:16, Jason Merrill <ja...@redhat.com> wrote:
On 2/8/24 12:12, Jason Merrill wrote:
On 2/8/24 10:04, Iain Sandoe wrote:
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).
Thank you!
-----
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.
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?
Yes in terms of me mixing up “just built” and “prev-*“
I've been unclear about that myself.
However, IIUC this still means we’re adding LD_LIBRARY_PATHs for each target
library, including libstdc++ (so I’m not sure if it solves the problem that I’d
seen before).
Yes, after stage 1.
You're right that we won't need all of the stage1 target libraries to
run the stage2 compiler. But if your gnat1 is linked with shared
libgcc, isn't also linked with shared libstdc++, so it would need to
find the stage1 libstdc++?
In general, though, it would make sense to decide whether to include
both libgcc and libstdc++ based on with_static_shared_libraries. And
likewise the other language runtimes (libada, libgfortran, ...)?
We probably don't need libgomp/libatomic/libitm?
libsanitizer/vtv/ssp should only be needed for a bootstrap using those
hardening options.
If your stage2 gnat1 does need the stage1 libstdc++ and you're also
using the system ld that needs the system libstdc++, that seems to call
for another approach discussed on the PR: have exec-tool.in splice out
the build directory from LD_LIBRARY_PATH when calling a tool from
outside the build directory.
Jason
