Re: [PATCH 1/1] Fix detection of pwritev support for OSX.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: James Hilliard <james(dot)hilliard1(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Sergey Shinderuk <s(dot)shinderuk(at)postgrespro(dot)ru>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: Re: [PATCH 1/1] Fix detection of pwritev support for OSX.
Date: 2021-01-19 20:54:38
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

James Hilliard <james(dot)hilliard1(at)gmail(dot)com> writes:
> On Tue, Jan 19, 2021 at 10:17 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

Attachment Content-Type Size
further-fix-sysroot-heuristics.patch text/x-diff 1.6 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2021-01-19 20:56:43 compression libraries and CF bot
Previous Message Alvaro Herrera 2021-01-19 20:49:03 Re: Some coverage for DROP OWNED BY with pg_default_acl