macOS versioned sysroot
src/tools/darwin_sysroot (previously in src/template/darwin) contains this:
# [...] Using a version-specific sysroot seems
# desirable, so if the path is a non-version-specific symlink, expand
# it.
On my system, the non-version-specific symlink is
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
and this script turns that into
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk
Now, every time the minor version of macOS is updated (e.g., 13.1 ->
13.2), the sysroot path is no longer there and the build fails. The fix
is to reconfigure and rebuild.
Maybe in the past these minor versions were rare, but at the moment it
looks like there is one about every two months. So every two months I
have to reconfigure and rebuild all my Postgres checkouts, of which I
have about 20 to 30, so this is getting a bit insane.
This code has been whacked around quite a bit, so it's hard to find the
origin of this. But I'm going to submit a vote for "seems *not* desirable".
(There is a workaround by setting PG_SYSROOT in the environment or
setting a meson option. But the default shouldn't be so fragile.)
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
src/tools/darwin_sysroot (previously in src/template/darwin) contains this:
# [...] Using a version-specific sysroot seems
# desirable, so if the path is a non-version-specific symlink, expand
# it.
This code has been whacked around quite a bit, so it's hard to find the
origin of this. But I'm going to submit a vote for "seems *not* desirable".
The reasoning for this is in the commit log for 4823621db:
Also, "xcrun --show-sdk-path" may give a path that is valid but lacks
any OS version identifier. We don't really want that, since most
of the motivation for wiring -isysroot into the build flags at all
is to ensure that all parts of a PG installation are built against
the same SDK, even when considering extensions built later and/or on
a different machine. Insist on finding "N.N" in the directory name
before accepting the result. (Adding "--sdk macosx" to the xcrun
call seems to produce the same answer as xcodebuild, but usually
more quickly because it's cached, so we also try that as a fallback.)
The core reason why we don't want to use Xcode's default SDK in cases
like this is that Apple's technology for introducing new syscalls
does not play nice with Autoconf: for example, configure will think
that preadv/pwritev exist when using a Big Sur SDK, even when building
on an older macOS version where they don't exist. It'd be nice to
have a better solution to that problem, but this patch doesn't attempt
to fix that.
Discussion: /messages/by-id/ed3b8e5d-0da8-6ebd-fd1c-e0ac80a4b204@postgrespro.ru
Re-reading the linked discussion makes me quite loath to remove
the version dependency logic; we'd certainly just be reinventing
that wheel next time Apple adds a new syscall that we care about.
Perhaps it would be adequate if we could select MacOSX13.sdk instead
of MacOSX13.1.sdk given the available choices:
$ ll /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
total 0
drwxr-xr-x 7 root wheel 224 Nov 12 16:18 MacOSX.sdk/
lrwxr-xr-x 1 root wheel 10 Dec 14 10:51 MacOSX13.1.sdk@ -> MacOSX.sdk
lrwxr-xr-x 1 root wheel 10 Dec 14 10:51 MacOSX13.sdk@ -> MacOSX.sdk
It does not seem that xcrun/xcodebuild will offer that, but we
could contemplate putting in some ad-hoc pathname munging to
strip any dot-digits part.
regards, tom lane