https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
Iain Sandoe <iains at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2019-05-21
Ever confirmed|0 |1
--- Comment #12 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Jack Howarth from comment #11)
> Just a reminder that clang solves finding the position of the SDK via xcrun
> and SDKROOT.
There are a few important points here.
1. We might be able to do some things in a similar manner, but "clang" is not
doing all the work you describe - there's effectively a wrapper that's
providing input for the clang driver.
2. xcrun is not open-sourced AFAIK, so we have to write an open equivalent /
emulate it in some way - the DEVELOPER_DIR etc require to find a suitable
executable at a specific path in the toolchain installation.
3. when clang is using a "different" SDK to target a version of MacOS, it is
using the runtimes provided by the target MacOS version.
GCC on the other hand is providing a series of runtimes and those runtimes
are configured on the basis of the version of the system they are intending to
target. Likewise, the fixincludes are run against the sysroot provided at
build time (whether it comes from --with-sysroot, or --build-sysroot is
immaterial to that).
4. for a number of sub-ranges of system versions we might be able to get away
with single copies of the runtimes (build for the oldest version you wish to
support). However, that does not guarantee that all APIs will be carried
forward (sometimes they are retired).
5. anything that means N more process launches per source file build seems like
we've picked a bad solution - so some form of caching somehow is highly
desirable.
For "target=host=build" single user cases, the --with-sysroot version works,
and we still have to find a good story for how to handle the more general case.
We've long resisted the notion of having multilibs by system version, but if
one really wants to cover the full range of possibilities - then either muliple
compilers or some form of system-revision multilib seems unavoidable.
Inactivity on this and related subjects (basically how to build and package GCC
for Darwin) should not be taken as meaning we don't care - actually we care
very much - it's just that a good solution has yet to be found.
