https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84257
Iain Sandoe <iains at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |iains at gcc dot gnu.org
--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #4)
> Confirmed even if I recover only a factor 2.
Unfortunately, neither SIP's ignoring - nor removing RPATH_ENVVAR - produces
the intended result.
Quoting from the Makefile
"
# This is the list of directories that may be needed in RPATH_ENVVAR
# so that programs built for the target machine work.
TARGET_LIB_PATH =
# This is the list of directories that may be needed in RPATH_ENVVAR
# so that programs built for the host machine work.
HOST_LIB_PATH =
"
> I don't think setting RPATH_ENVVAR to DYLD_LIBRARY_PATH is necessary on
> modern macOS > versions, please check.
The requirement has nothing to do with 'modern' c.f. 'old' macOS/Darwin; these
paths are intended to ensure that the correct (just-built, or even not present
in the system installation) libraries are available to the stage#1 target
libraries build and stage#2+ where needed. For most people's "usual" build the
compiler is statically linked with libstdc++ &c. and so this really only
affects configure steps when the new compiler is generating code that _should_
use the newly-built support libs.
When SIP is enabled (or when you remove the DYLD_LIBRARY_PATH setting) we have
been "getting away" falling back to system versions of libstdc++ and libgcc_s.x
... this doesn't work if one introduces a new lib that isn't present on the
system (which I want to do to solve the long-standing hassles with the
unwinder).
* As an aside, there is no Good Solution to using DYLD_LIBRARY_PATH - if it's
exported at the top level, since it must be honoured for *every* exe that runs
below this, which means that it also affects system-utils (e.g. ld).. this has
been a source of instability on occasion.
So.. what to do?
We don't (well I don't) really want to be forced to switch SIP off to build
toolchains, but OTOH it's necessary to manipulate the library load ordering
when building a toolchain....
1) Speculation: that there are a lot of paths to search and they might contain
many files, so that if there's no caching of the results (perhaps that was
present pre-SIP and is now removed) .. it could mean a lot of work to find the
libgcc_s - that's the last path in the list.
* To test this hypothesis, I'm going to experiment with re-ordering the search
path (temporary fix).
2) A possible proper fix is to make use of @rpath/ and set appropriate rpaths
in the build. A while ago I was experimenting with this to solve some of our
general deployment issues
* will look out those patches.
3) We could (probably) abandon the shared libgcc_ext lib, after some patches in
progress to eliminate the unwinder hassles. This would hide (most) of the
problem, but not really solve it.
* I can easily try this.
1 and 3 are, of course, the easier options (they paper over cracks for the
short-term) - but 2 might be quite tricky to get right (it has to work in the
build layout _and_ when installed).
4) I did think that we could perhaps move all built host libs to a Known Place
in the build tree [e.g. $(builddir)/host-libs, prev-host-libs] (likewise target
libs, to a separate Known Place). That would mean a reduced number of paths to
search, and that path would only have the libs - not thousands of other files
too. That's probably quite a bit of build/test system hacking tho ..
