> Am 1. Nov. 2018 um 04:17 schrieb Tom Lane <t...@sss.pgh.pa.us>: > > 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.
I've tried to replicate your experiment, but I initially got the "-isysroot" flag for both Xcode 10 and Xcode 10.1. Then I upgraded the "Comand Line Tools for Xcode 10.1" using Software Update, and suddenly the "-isysroot" flag disappeared (for both Xcode 10 and Xcode 10.1). In any case, it looks like we can't rely on "-isysroot" being present. > Am 2. Nov. 2018 um 16:09 schrieb Tom Lane <t...@sss.pgh.pa.us>: > > Daniel Gustafsson <dan...@yesql.se <mailto:dan...@yesql.se>> writes: >>> On 2 Nov 2018, at 15:42, Tom Lane <t...@sss.pgh.pa.us >>> <mailto:t...@sss.pgh.pa.us>> wrote: >>> Anybody have an opinion about which approach to use? We need to choose >>> one, and PDQ too, if we want full buildfarm coverage on it before Monday's >>> wrap. > >> #1 is the option that appeals to me the most, mostly because it removes all >> possible ambiguity of when/if it’s required compared to #2. > > I'm sort of leaning in that direction too, after sleeping on it. > It's also closer to what we already shipped in 11.0 than #2 is. > > regards, tom lane I think I would prefer #2. I think it would work better for my use case (end users download a binary of the server but may build their own extensions). Regarding #1: Since -isysroot is only necessary for building pl/tcl and pl/perl, why do you add it to CPPFLAGS in the global makefile? Wouldn't it make more sense to just add it in the TCL and Perl makefiles? Best regards, Jakob