BUG #15358: PostgreSQL fails to build on 10.14 when Perl is enabled.
От | PG Bug reporting form |
---|---|
Тема | BUG #15358: PostgreSQL fails to build on 10.14 when Perl is enabled. |
Дата | |
Msg-id | 153558865647.1483.573481613491501077@wrigleys.postgresql.org обсуждение исходный текст |
Ответы |
Re: BUG #15358: PostgreSQL fails to build on 10.14 when Perl is enabled.
Re: BUG #15358: PostgreSQL fails to build on 10.14 when Perl isenabled. |
Список | pgsql-bugs |
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.
В списке pgsql-bugs по дате отправления: