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-20 01:37:08
Message-ID: 559755.1611106628@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

James Hilliard <james(dot)hilliard1(at)gmail(dot)com> writes:
> Actually, this looks path looks wrong in general, the value for
> "xcrun --sdk macosx --show-sdk-path" should take precedence over
> "xcrun --show-sdk-path" as the latter may be used for IOS potentially.

What is "potentially"? I've found no direct means to control the
SDK path at all, but so far it appears that "xcrun --show-sdk-path"
agrees with the compiler's default -isysroot path as seen in the
compiler's -v output. I suspect that this isn't coincidental,
but reflects xcrun actually being used in the compiler launch
process. If it were to flip over to using a IOS SDK, that would
mean that bare "cc" would generate nonfunctional executables,
which just about any onlooker would agree is broken.

I'm really not excited about trying to make the build work with
a non-native SDK as you are proposing. I think that's just going
to lead to a continuing stream of problems, because of Apple's
opinions about how cross-version compatibility should work.
It also seems like unnecessary complexity, because there is always
(AFAICS) a native SDK version available. We just need to find it.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2021-01-20 01:50:06 Re: Odd, intermittent failure in contrib/pageinspect
Previous Message tsunakawa.takay@fujitsu.com 2021-01-20 01:32:47 RE: Parallel INSERT (INTO ... SELECT ...)