Re: [PATCH 1/1] Fix detection of pwritev support for OSX. - Mailing list pgsql-hackers
From | Tom Lane |
---|---|
Subject | Re: [PATCH 1/1] Fix detection of pwritev support for OSX. |
Date | |
Msg-id | 522433.1611089678@sss.pgh.pa.us Whole thread Raw |
In response to | Re: [PATCH 1/1] Fix detection of pwritev support for OSX. (James Hilliard <james.hilliard1@gmail.com>) |
Responses |
Re: [PATCH 1/1] Fix detection of pwritev support for OSX.
|
List | pgsql-hackers |
James Hilliard <james.hilliard1@gmail.com> writes: > On Tue, Jan 19, 2021 at 10:17 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Ah, got it. So "xcrun --show-sdk-path" tells us the right thing (that >> is, it *does* give us a symlink to a 10.15 SDK) but by refusing to >> believe we've got the right thing, we end up picking MacOSX11.1.sdk. >> Drat. I suppose we could drop the heuristic about wanting a version >> number in the SDK path, but I really don't want to do that. Now I'm >> thinking about trying to dereference the symlink after the first step. > The MacOSX11.1.sdk can build for a 10.15 target just fine when passed > an appropriate MACOSX_DEPLOYMENT_TARGET, so that SDK should be > fine. But our out-of-the-box default should be to build for the current platform; we don't want users to have to set MACOSX_DEPLOYMENT_TARGET for that case. Besides, the problem we're having is exactly that Apple's definition of "builds for a 10.15 target just fine" is different from ours. They think you should use a run-time test not a compile-time test to discover whether preadv is available, and we don't want to do that. In almost all of the cases I've seen so far, Apple's compiler actually does default to using an SDK matching the platform. The problem we have is that we try to name the SDK explicitly, and the current method is failing to pick the right one in your case. There are several reasons for using an explicit -isysroot rather than just letting the compiler default: * We have seen cases in which the compiler acts as though it has *no* default sysroot, and we have to help it out. * The explicit root reduces version-skew build hazards for extensions that are not built at the same time as the core system. * There are a few tests in configure itself that need to know the sysroot path to check for files there. Anyway, the behavior you're seeing shows that 4823621db is still a bit shy of a load. I'm thinking about the attached as a further fix --- can you verify it helps for you? regards, tom lane diff --git a/src/template/darwin b/src/template/darwin index 1868c147cb..e14d53b601 100644 --- a/src/template/darwin +++ b/src/template/darwin @@ -7,13 +7,20 @@ if test x"$PG_SYSROOT" = x"" ; then # This is far more complicated than it ought to be. We first ask # "xcrun --show-sdk-path", which seems to match the default -isysroot - # setting of Apple's compilers. However, that may produce no result or - # a result that is not version-specific (i.e., just ".../SDKs/MacOSX.sdk"). - # Using a version-specific sysroot seems desirable, so if there are not - # digits in the directory name, try "xcrun --sdk macosx --show-sdk-path"; - # and if that still doesn't work, fall back to asking xcodebuild, - # which is often a good deal slower. + # setting of Apple's compilers. PG_SYSROOT=`xcrun --show-sdk-path 2>/dev/null` + # That may fail, or produce a result that is not version-specific (i.e., + # just ".../SDKs/MacOSX.sdk"). Using a version-specific sysroot seems + # desirable, so if the path is a non-version-specific symlink, expand it. + if test -L "$PG_SYSROOT"; then + if expr x"$PG_SYSROOT" : '.*[0-9]\.[0-9][^/]*$' >/dev/null ; then : okay + else + PG_SYSROOT=`expr "$PG_SYSROOT" : '\(.*\)/'`/`readlink "$PG_SYSROOT"` + fi + fi + # If there are still not digits in the directory name, try + # "xcrun --sdk macosx --show-sdk-path"; and if that still doesn't work, + # fall back to asking xcodebuild, which is often a good deal slower. if expr x"$PG_SYSROOT" : '.*[0-9]\.[0-9][^/]*$' >/dev/null ; then : okay else PG_SYSROOT=`xcrun --sdk macosx --show-sdk-path 2>/dev/null`
pgsql-hackers by date: