Re: PG vs macOS Mojave

Jakob Egger <jakob(at)eggerapps(dot)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