On Thu, Jan 14, 2021 at 6:45 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Sergey Shinderuk <s.shinde...@postgrespro.ru> writes: > > On 15.01.2021 01:13, Tom Lane wrote: > >> Also, after re-reading [1] 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. I don't think enforcing a specific naming scheme makes sense, the minimum OSX runtime version is effectively entirely separate from the SDK version.
The pwritev issue just seems to be caused by a broken configure check, I've fixed that here: https://postgr.es/m/20210119111625.20435-1-james.hilliard1%40gmail.com > > Hence, I propose the attached. This works as far as I can tell > to fix the problem you're seeing. > > regards, tom lane >
