• Tom Lane's avatar
    Improve our heuristic for selecting PG_SYSROOT on macOS. · 4823621d
    Tom Lane authored
    In cases where Xcode is newer than the underlying macOS version,
    asking xcodebuild for the SDK path will produce a pointer to the
    SDK shipped with Xcode, which may end up building code that does
    not work on the underlying macOS version.  It appears that in
    such cases, xcodebuild's answer also fails to match the default
    behavior of Apple's compiler: assuming one has installed Xcode's
    "command line tools", there will be an SDK for the OS's own version
    in /Library/Developer/CommandLineTools, and the compiler will
    default to using that.  This is all pretty poorly documented,
    but experimentation suggests that "xcrun --show-sdk-path" gives
    the sysroot path that the compiler is actually using, at least
    in some cases.  Hence, try that first, but revert to xcodebuild
    if xcrun fails (in very old Xcode, it is missing or lacks the
    --show-sdk-path switch).
    
    Also, "xcrun --show-sdk-path" may give a path that is valid but lacks
    any OS version identifier.  We don't really want that, since most
    of the motivation for wiring -isysroot into the build flags at all
    is to ensure that all parts of a PG installation are built against
    the same SDK, even when considering extensions built later and/or on
    a different machine.  Insist on finding "N.N" in the directory name
    before accepting the result.  (Adding "--sdk macosx" to the xcrun
    call seems to produce the same answer as xcodebuild, but usually
    more quickly because it's cached, so we also try that as a fallback.)
    
    The core reason why we don't want to use Xcode's default SDK in cases
    like this is that Apple's technology for introducing new syscalls
    does not play nice with Autoconf: for example, configure will think
    that preadv/pwritev exist when using a Big Sur SDK, even when building
    on an older macOS version where they don't exist.  It'd be nice to
    have a better solution to that problem, but this patch doesn't attempt
    to fix that.
    
    Per report from Sergey Shinderuk.  Back-patch to all supported versions.
    
    Discussion: https://postgr.es/m/ed3b8e5d-0da8-6ebd-fd1c-e0ac80a4b204@postgrespro.ru
    4823621d
darwin 1.87 KB