|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Sergey Shinderuk <s(dot)shinderuk(at)postgrespro(dot)ru>|
|Cc:||Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: pg_preadv() and pg_pwritev()|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Sergey Shinderuk <s(dot)shinderuk(at)postgrespro(dot)ru> writes:
> On 15.01.2021 01:13, Tom Lane wrote:
>> Also, after re-reading  I am not at all excited about trying to
>> remove the -isysroot switches from our *FLAGS. What I propose to do
>> is keep that, but improve our mechanism for choosing a default value
>> for PG_SYSROOT. It looks like first trying "xcrun --show-sdk-path",
>> and falling back to "xcodebuild -version -sdk macosx Path" if that
>> doesn't yield a valid path, is more likely to give a working build
>> than relying entirely on xcodebuild. Maybe there's a case for trying
>> "xcrun --sdk macosx --show-sdk-path" in between; in my tests that
>> seemed noticeably faster than invoking xcodebuild, and I've not yet
>> seen a case where it gave a different answer.
> I spent quite some time trying to understand / reverse engineer the
> logic behind xcrun's default SDK selection.
Yeah, I wasted a fair amount of time on that too, going so far as
to ktrace xcrun (as I gather you did too). I'm not any more
enlightened than you are about exactly how it's making the choice.
> Oh, that's weird! Nevertheless I like you suggestion to call "xcrun"
> from "configure".
Anyway, after re-reading the previous thread, something I like about
the current behavior is that it tends to produce a version-numbered
sysroot path, ie something ending in "MacOSX11.1.sdk" or whatever.
One of the hazards we're trying to avoid is some parts of a PG
installation being built against one SDK version while other parts are
built against another. The typical behavior of "xcrun --show-sdk-path"
seems to be to produce a path ending in "MacOSX.sdk", which defeats that.
So I think we should accept the path only if it contains a version number,
and otherwise move on to the other probe commands.
Hence, I propose the attached. This works as far as I can tell
to fix the problem you're seeing.
regards, tom lane
|Next Message||Sergey Shinderuk||2021-01-15 01:53:46||Re: pg_preadv() and pg_pwritev()|
|Previous Message||Fujii Masao||2021-01-15 01:32:53||Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit|