Thread: BUG #15358: PostgreSQL fails to build on 10.14 when Perl is enabled.

The following bug has been logged on the website:

Bug reference:      15358
Logged by:          Dominyk Tiller
Email address:      dominyktiller@gmail.com
PostgreSQL version: 10.5
Operating system:   macOS 10.14
Description:

As of macOS 10.14/Mojave the headers for Perl are no longer available inside
`/System`, which breaks several assumptions PostgreSQL makes during the
compile process. PostgreSQL uses `perl -MConfig -e 'print
$Config{archlibexp}'` + "CORE" to determine the location, and on macOS 10.14
this returns `/System/Library/Perl/5.18/darwin-thread-multi-2level` +
"CORE".

That location contains only `libperl.dylib` now, but the output is correct
as far as Apple are concerned because the usage of `-I` on Darwin is
erroneous when trying to build against system-provided tools; the advice is
for people to switch over to using `-iwithsysroot` in those circumstances.
The absolute minimal patch to achieve that is to replace the three calls of
`-I$perl_archlibexp/CORE` or `-I$(perl_archlibexp)/CORE` in `configure`,
`contrib/hstore_plperl/Makefile` and `src/pl/plperl/GNUmakefile` with
`-iwithsysroot $perl_archlibexp/CORE` or `-iwithsysroot
$(perl_archlibexp)/CORE` respectively, which clang understands as
`/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE`
or the Xcode equivalent of that path and thus PostgreSQL compiles
successfully.

That's the route we're going down in Homebrew to ensure Mojave support.
However, I'm assuming PostgreSQL wants to retain compatibility with using
non-system Perls on macOS, so the minimal patch wouldn't work in that case.
I would guess the sensible thing to do would be to check the path and use
`-iwithsysroot ` if the path returns `/System` on macOS and in all other
cases keep using `-I`, but I think there are a few different avenues
PostgreSQL could go down there, which is why I'm kinda leaving this to y'all
with a bug report rather than trying to file a patch. I'm happy to file a
patch if you wish, though.

As things stand in the 10.5 release, and I'm assuming prior versions of
PostgreSQL as well, the build errors out during configure with:
```
checking for perl.h... no
configure: error: header file <perl.h> is required for Perl
```

Please let me know if you need any further information; I fully appreciate
how bad I remain at writing coherent bug reports! Thanks for your time.

=?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> writes:
> As of macOS 10.14/Mojave the headers for Perl are no longer available inside
> `/System`, which breaks several assumptions PostgreSQL makes during the
> compile process. PostgreSQL uses `perl -MConfig -e 'print
> $Config{archlibexp}'` + "CORE" to determine the location, and on macOS 10.14
> this returns `/System/Library/Perl/5.18/darwin-thread-multi-2level` +
> "CORE".

Sigh.  Would you mind filing a bug with *Apple* not us?  There's no
good reason why they have to break this.  They are certainly free to
rearrange their installation however they like, but that doesn't
excuse them from updating $Config{archlibexp} to reflect it.

I realize of course that Cupertino is a bit impervious to suggestions
like that ... but if nobody even makes the suggestion, it's only partly
their fault.

            regards, tom lane

Dominyk Tiller <dominyktiller@gmail.com> writes:
> I'm afraid the decision to file a bug report with PostgreSQL was
> motivated by an extensive conversation with Apple, where they affirmed
> in detail things were behaving as expected on their end.

I've been an Apple fanboy since the eighties, but they're starting to
behave like Microsoft: rather than trying to support platform-independent
open source, they think they're big enough to demand everybody have a
bunch of Apple-specific workarounds.  It's about time to just say no.

            regards, tom lane

On 30/08/2018 02:24, PG Bug reporting form wrote:
> That location contains only `libperl.dylib` now, but the output is correct
> as far as Apple are concerned because the usage of `-I` on Darwin is
> erroneous when trying to build against system-provided tools; the advice is
> for people to switch over to using `-iwithsysroot` in those circumstances.
> The absolute minimal patch to achieve that is to replace the three calls of
> `-I$perl_archlibexp/CORE` or `-I$(perl_archlibexp)/CORE` in `configure`,
> `contrib/hstore_plperl/Makefile` and `src/pl/plperl/GNUmakefile` with
> `-iwithsysroot $perl_archlibexp/CORE` or `-iwithsysroot
> $(perl_archlibexp)/CORE` respectively, which clang understands as
> `/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE`
> or the Xcode equivalent of that path and thus PostgreSQL compiles
> successfully.

We also need to support gcc, so that's not going to work.  clang and gcc
appear to have an incompatible zoo of various "sysroot" options.  I
don't know how to consolidate that.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services