Re: PG vs macOS Mojave

I wrote:
> Then somebody who wants to build on a different SDK version still needs
> to do "make PG_SYSROOT=/proper/path", but only if they're trying to
> build PL/Perl or related extensions.  So this second way seems uglier
> in some sense but less likely to cause problems for most people.

> Either way I guess we'd need to document it rather than just hoping
> it's invisible.

Here's a proposed doc patch for this second approach.  It'd still mostly
work for the first approach, if we drop the sentence about it only
mattering for PL/Perl and PL/Tcl.

I failed to resist the temptation to mutter something about SIP while
at it.  AFAIK that problem isn't mentioned anywhere else.

            regards, tom lane

diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
index 4487d0c..1c87eef 100644
*** a/doc/src/sgml/installation.sgml
--- b/doc/src/sgml/installation.sgml
*************** PHSS_30849  s700_800 u2comp/be/plugin li
*** 2513,2518 ****
--- 2513,2559 ----
     </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=/desired/path
+ </programlisting>
+     To find out the appropriate path on your machine, run
+ <programlisting>
+ xcodebuild -version -sdk macosx Path
+ </programlisting>
+     Currently, this only affects Perl and Tcl header files, so it should
+     only matter if you're building PL/Perl, PL/Tcl, or a related extension.
+    </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>