Re: PG vs macOS Mojave - Mailing list pgsql-hackers

[ just when you thought it was safe to go back in the water ]

I wrote:
>> Jakob Egger <jakob@eggerapps.at> writes:
>>> I would assume that clang sets -isysroot automatically, but I have no idea why that didn't work for you previously.

>> [ experiments further ... ]  It looks like clang does default to assuming
>> -isysroot with the correct sysroot for its Xcode version.

So today I updated longfin's host to macOS 10.14.1 + Xcode 10.1,
and things promptly broke:

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=longfin&dt=2018-10-31%2013%3A49%3A50

It can't find Perl's headers anymore.  Investigation says that the reason
is that clang no longer has this as default:

  -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk

You can verify the thing's built-in settings with something like

$ echo >test.c
$ clang -v -E test.c

and on Xcode 10.0 I get

 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple
x86_64-apple-macosx10.14.0-Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -E -disable-free
-disable-llvm-verifier-discard-value-names -main-file-name test.c -mrelocation-model pic -pic-level 2 -mthread-model
posix-mdisable-fp-elim -fno-strict-return -masm-verbose -munwind-tables -target-cpu penryn -dwarf-column-info
-debugger-tuning=lldb-target-linker-version 409.12 -v -resource-dir
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0-isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk-I/usr/local/include
-fdebug-compilation-dir/Users/tgl -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks
-fencode-extended-block-signature-fobjc-runtime=macosx-10.14.0 -fmax-type-align=16 -fdiagnostics-show-option
-fcolor-diagnostics-o - -x c test.c 

while with Xcode 10.1's compiler:

 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple
x86_64-apple-macosx10.14.0-Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -E -disable-free
-disable-llvm-verifier-discard-value-names -main-file-name test.c -mrelocation-model pic -pic-level 2 -mthread-model
posix-mdisable-fp-elim -fno-strict-return -masm-verbose -munwind-tables -target-cpu penryn -dwarf-column-info
-debugger-tuning=lldb-target-linker-version 409.12 -v -resource-dir
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0
-fdebug-compilation-dir/Users/tgl -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks
-fencode-extended-block-signature-fobjc-runtime=macosx-10.14.0 -fmax-type-align=16 -fdiagnostics-show-option
-fcolor-diagnostics-o - -x c test.c 

No default sysroot at all.  So the immediate question is whether Apple
broke this in Xcode 10.1, or whether it was broken in Xcode 10.0 and
now they've "fixed" it.  Unfortunately, I'm afraid the answer is the
latter.  I do not any longer have a pre-10.0 Xcode handy to try, but
if those versions did not have any default sysroot, that would handily
explain the results I was getting before updating to Mojave.  Also,
some googling suggests that older Xcode versions had no default sysroot
setting; for instance see here:

https://langui.sh/2015/07/24/osx-clang-include-lib-search-paths/

In short, it looks like our current solution of expecting the compiler
to default to the correct -isysroot setting is just broken.  It
accidentally works on Xcode 10.0, but not earlier or later versions.

We don't have a lot of time to fix this, as our next quarterly
releases wrap on Monday.  Right now I think the only plausible
fix is to go back to adding "-isysroot $PG_SYSROOT" to CPPFLAGS.
Maybe we can fix things to make it relatively easy to override that
for cases like building against a different Xcode version, but it's
not going to just be automatic for that to work.

            regards, tom lane