public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: Peter Eisentraut <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: macOS versioned sysroot
Date: Mon, 16 Jan 2023 10:19:49 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
Peter Eisentraut <[email protected]> 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: https://postgr.es/m/[email protected]
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
view thread (2+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: macOS versioned sysroot
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox