Jakob Egger <ja...@eggerapps.at> writes: > Am 17.10.2018 um 16:28 schrieb Tom Lane <t...@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" 1 3 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
