https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
--- Comment #14 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Jeremy Huddleston Sequoia from comment #13)
I fully understand that a (perhaps the most) common use-case is
build=host=target.
However, we want the other use-cases to work (for example, I regularly
cross-host x86-64-darwinxx => powerpc-darwin9, and also use native
{build!=host=target} crosses (essential when porting Ada across versions).
> 1. clang honors $SDKROOT from the environment if it is not passed via
> -isysroot on the command line. That's all gcc needs to do, and then users
> running 'xcrun gcc' would ge this behavior automatically.
This ({$SDKROOT} support) is now implemented, but IMO it's dangerous - since
that will apply everywhere when no --sysroot/-isysroot is given which
could/would break any other case than build=host=target. It's likely to
produce bug reports about cross-builds not working.
> 2. xcrun is not OSS, but the primary functionality that you asked for was
> provided in libxcselect in macOS 10.15, so you wouldn't need to exec xcrun
> to find the path to the SDK.
That's a great addition, we will have to figure out how to incorporate it for
the folks that can use 10.15+.
> 3. I cannot decipher your comment "when clang is using a "different" SDK to
> target a version of MacOS, it is using the runtimes provided by the target
> MacOS version." ... that doesn't quite make sense, so please be a bit more
> specific about which runtime you are referring to (the compiler runtime, the
> OS runtime)... either way I try to interpret it, it makes no sense, so I'm
> not sure how to address this comment, sorry.
when target != host (and target-version < host-version -1) it's safer to use an
SDK that's for the actual target (from an earlier Xcode or Command line tools
SDK). This becomes more and more important when the gap between host and
target version gets larger.
It is obviously essential when doing crosses from x86_64 => powerpc darwin,
since there's no support for powerpc in the current SDKs. It's now also
essential for targeting i686.
So this is just repeating that the OSS use of macOS/Darwin does not necessarily
follow the "only version N and N-1 matter" pattern. Nor are people in a
position to use the latest-and-greatest in all cases; one of my fastest
machines is a 2008 8core xeon mac pro - which cannot go beyond 10.11. In fact,
many places are unwilling to use bleeding edge for production machines too.
> 4. macOS deprecates APIs but will almost never remove them (unless we change
> architectures ... such as when we removed a bunch of deprecated API when
> moving from ppc to intel). Internal / private SPI is subject to removal,
> but we aim to never remove API as that breaks binary compatibility.
That's good to know (for the record, I would not sanction the use of an
internal API for the GCC port, however tempting it might be).
=== attempt at a summary.
In principle, there are 3 SDKs that could matter (where build, host and target
system versions can all be different - analogous to a so-called "Canadian
cross").
1) for the build system version (since we build code that must run on the host
- the generators, and some of the Ada stuff)
That can be provided by doing CC/CXX="xxx --sysroot=" on the configure line.
2) for the host code.
This is usually expected to be provided by the compiler that is targeting the
host.
macOS is an usual case for GCC in that, in principle, we can target all
versions with one compiler, where other systems can expect the
compiler-for-host to reference an appropriate sysroot-for-host.
we are missing a good way to provide the SDK to the compiler in this case (in
fact, I usually just build a cross-compiler with the host macOS as the target
and install it in the usual "linux-y" way).
(as an aside) In the 10.5/6 era it all "just worked" because the SDKs included
support for all the cross-cases, and there were not really any big gaps in the
support.
Now we have a large range of macOS/Darwin versions and the current SDKs won't
support building for perfectly sane hardware (e.g. my 8 core Xeon) much less
the vintage (powerpc).
3) for the target code.
The usual case is to provide --with-sysroot=
As noted before, although the provided SDK path becomes the default, it does
not prevent it from being overridden by a user's command line --sysroot= [and
now also $SDKROOT will override when there's no --sysroot/-isysroot on the
command line]
--with-build-sysroot=dir is allowing for the case that the build system wants
to provide the build time sys root from a different place than the one given by
--with-sysroot=
(so, for example, --with-sysroot=/ ... --with-build-sysroot=/path/to/target/SDK
)
https://gcc.gnu.org/install/configure.html describes in more detail.
This option is not working completely (on other platforms too) so the patch
listed above is a sketch at trying to improve that (albeit incomplete, it
apparently solves some of the issues).
