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>
