Jakob Egger <ja...@eggerapps.at> writes: > 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).
Interesting. I'd not tested the intermediate state without the CLT update. > In any case, it looks like we can't rely on "-isysroot" being present. Yeah, that's becoming clear, even if it's not clear exactly when it's pre-supplied or not. > 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? Well, that's what #2 is, but the point is that #2 is a bit of a kluge that might not work for much longer anyway. If Apple has moved Perl's include files to only appear under the sysroot, what's the reason to think they will stop there? It's pretty clear from documentation already cited in this thread that they think specifying a sysroot path is good practice; so I fear it's likely that they will stop providing much of anything under /usr/include, except maybe the bare minimum required by POSIX. An example that's particularly likely to bite us soon is the headers for Secure Transport, which isn't POSIX. While we can get away with having separate include switches for Perl and Tcl, I don't think we're going to have an appetite for trying to apply a separate include switch for ST to just our SSL-related .c files. The bigger issue though is that on a machine with multiple sysroots installed, approach #2 creates a very severe risk that portions of Postgres will be built against a different sysroot than other portions. That will inevitably lead to ABI-compatibility issues. Debugging just one of those would waste far more time than anyone could ever save by being able to skip specifying the sysroot. > 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). Well, it's clear that anybody who's doing that and using a different sysroot version for their extension is taking their chances with ABI compatibility. I was willing to avoid breaking that case unnecessarily, but what we're now seeing is that doing so means exposing everybody else to those same ABI hazards. I think it's probably better to have the explicit sysroot setting, provide a way to override it at build time (as patch #1 does), and just make it clear that if you override it you are taking chances. regards, tom lane