database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-16 06:01:02 +03:00
Code Activity

Yet further rethinking of build changes for macOS Mojave.

Browse Source 
The solution arrived at in commit e74dd00f5 presumes that the compiler
has a suitable default -isysroot setting ... but further experience
shows that in many combinations of macOS version, XCode version, Xcode
command line tools version, and phase of the moon, Apple's compiler
will *not* supply a default -isysroot value.

We could potentially go back to the approach used in commit 68fc227dd,
but I don't have a lot of faith in the reliability or life expectancy of
that either.  Let's just revert to the approach already shipped in 11.0,
namely specifying an -isysroot switch globally.  As a partial response to
the concerns raised by Jakob Egger, adjust the contents of Makefile.global
to look like

CPPFLAGS = -isysroot $(PG_SYSROOT) ...
PG_SYSROOT = /path/to/sysroot

This allows overriding the sysroot path at build time in a relatively
painless way.

Add documentation to installation.sgml about how to use the PG_SYSROOT
option.  I also took the opportunity to document how to work around
macOS's "System Integrity Protection" feature.

As before, back-patch to all supported versions.

Discussion: https://postgr.es/m/20840.1537850987@sss.pgh.pa.us
This commit is contained in:
Tom Lane
2018-11-02 18:54:00 -04:00
parent 1ce4a807e2
commit 1440c461f7
5 changed files with 75 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

51
doc/src/sgml/installation.sgml
View File

@ -2513,6 +2513,57 @@ PHSS_30849 s700_800 u2comp/be/plugin library Patch
</para>
</sect2>
<sect2 id="installation-notes-macos">
<title>macOS</title>
<indexterm zone="installation-notes-macos">
<primary>macOS</primary>
<secondary>installation on</secondary>
</indexterm>
<para>
On recent <productname>macOS</productname> releases, it's necessary to
embed the <quote>sysroot</quote> path in the include switches used to
find some system header files. This results in the outputs of
the <application>configure</application> script varying depending on
which SDK version was used during <application>configure</application>.
That shouldn't pose any problem in simple scenarios, but if you are
trying to do something like building an extension on a different machine
than the server code was built on, you may need to force use of a
different sysroot path. To do that, set <varname>PG_SYSROOT</varname>,
for example
<programlisting>
make PG_SYSROOT=<replaceable>/desired/path</replaceable> all
</programlisting>
To find out the appropriate path on your machine, run
<programlisting>
xcodebuild -version -sdk macosx Path
</programlisting>
Note that building an extension using a different sysroot version than
was used to build the core server is not really recommended; in the
worst case it could result in hard-to-debug ABI inconsistencies.
</para>
<para>
You can also select a non-default sysroot path when configuring, by
specifying <varname>PG_SYSROOT</varname>
to <application>configure</application>:
<programlisting>
./configure ... PG_SYSROOT=<replaceable>/desired/path</replaceable>
</programlisting>
</para>
<para>
<productname>macOS</productname>'s <quote>System Integrity
Protection</quote> (SIP) feature breaks <literal>make check</literal>,
because it prevents passing the needed setting
of <literal>DYLD_LIBRARY_PATH</literal> down to the executables being
tested. You can work around that by doing <literal>make
install</literal> before <literal>make check</literal>.
Most Postgres developers just turn off SIP, though.
</para>
</sect2>
<sect2 id="installation-notes-mingw">
<title>MinGW/Native Windows</title>