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

Jakob Egger <jakob@eggerapps.at> writes:
> Am 17.10.2018 um 16:28 schrieb Tom Lane <tgl@sss.pgh.pa.us>:
>> It's also very odd,
>> if the compiler will search the sysroot automatically, why that seemingly
>> works for tcl.h but not perl.h.  plperl definitely still fails if you
>> lobotomize the PG_SYSROOT logic.

> Because pl/tcl ends up using -iwithsysroot to specify the header search path and pl/perl uses -I

No, that's not it.  It occurred to me to investigate this by using
"gcc ... -E pltcl.c" to see where the compiler is finding the tcl.h
header file.  The answer is that if you use

-I
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/Tcl.framework/Versions/8.5/Headers

either explicitly or with a combination of -isysroot and -iwithsysroot,
then that directory is where it finds tcl.h.  But if you *don't* do that,
it still manages to find tcl.h here:

# 1
"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/tcl.h"
13 4 

So the true answer seems to be that the compiler's built-in search path
includes $SYSROOT/usr/include, and that pltcl works despite an "incorrect"
-I value on the command line because there is a copy of tcl.h there (it's
a symlink to the other one, actually).  On the other hand, Perl's headers
are *not* under that directory, so plperl doesn't work without an accurate
-I switch on the command line.

> See also: https://www.postgresql.org/message-id/153558865647.1483.573481613491501077%40wrigleys.postgresql.org

Yeah, it was my recollection of that discussion that led me to jump
to the conclusion that we had to use -isysroot, which we now see to
be not such a great idea.

> 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.  The missing bit
of info is that -I /System/... is taken as an absolute path that's not
affected by the sysroot.  You have to write -iwithsysroot /System/...
to have something that is taken relative to the sysroot.

I'm still a little confused by this, because my previous experiments
seemed to imply that we had to write -isysroot explicitly to get the
compiler to assume a sysroot path, ie there did not seem to be any
built-in default.  That never made much sense, and the results
I'm getting now contradict it.

So as far as pltcl is concerned, we don't really need the configure
hack to insert PG_SYSROOT into TCL_INCLUDE_SPEC; we could leave Apple's
value alone and it should work.  (Not that that gets pltcl out of
dependency on the sysroot entirely, because AFAICS there's still no way
to find tclConfig.sh without explicitly accounting for sysroot.  And
I'm not exactly convinced that using explicit sysroot to do that and
then leaving it out later is a hot idea.)

However, on the Perl side, we'd have to change -I to -iwithsysroot if
we wanted to avoid explicitly mentioning the sysroot path, and that
seems way more invasive than it's worth.

I'm inclined to leave things as they stand now; it makes for reasonably
consistent build behavior between pltcl and plperl.

            regards, tom lane