 @@ -1,2460 +1,2461 @@
-<!-- $NetBSD: fixes.xml,v 1.187 2023/07/21 08:29:56 nia Exp $ -->
+<!-- $NetBSD: fixes.xml,v 1.188 2023/07/22 12:20:37 nia Exp $ -->
 <chapter id="fixes"> <?dbhtml filename="fixes.html"?>
 <title>Making your package work</title>
 <sect1 id="general-operation">
   <title>General operation</title>
   <para>One appealing feature of pkgsrc is that it runs on many
   different platforms. As a result, it is important to ensure,
   where possible, that packages in pkgsrc are portable. This
   chapter mentions some particular details you should pay
   attention to while working on pkgsrc.</para>
   <sect2 id="pulling-vars-from-etc-mk.conf">
     <title>How to pull in user-settable variables from &mk.conf;</title>
     <para>The pkgsrc user can configure pkgsrc by overriding several
     variables in the file pointed to by <varname>MAKECONF</varname>,
     which is &mk.conf; by default. When you
     want to use those variables in the preprocessor directives of
     &man.make.1; (for example <literal>.if</literal> or
     <literal>.for</literal>), you need to include the file
     <filename>../../mk/bsd.prefs.mk</filename> before, which in turn
     loads the user preferences.</para>
     <para>But note that some variables may not be completely defined
     after <filename>../../mk/bsd.prefs.mk</filename> has been
     included, as they may contain references to variables that are
     not yet defined. In shell commands (the lines in
     <filename>Makefile</filename> that are indented with a tab) this
     is no problem, since variables are only expanded when they are
     used. But in the preprocessor directives mentioned above and in
     dependency lines (of the form <literal>target:
     dependencies</literal>) the variables are expanded at load
     time.</para>
     <note><para>To check whether a variable can be used at load time,
     run <command>pkglint -Wall</command> on your package.</para></note>
   </sect2>
   <sect2 id="user-interaction">
     <title>User interaction</title>
     <para>Occasionally, packages require interaction from the user,
     and this can be in a number of ways:</para>
     <itemizedlist>
       <listitem>
 	<para>When fetching the distfiles, some packages require user
 	interaction such as entering username/password or accepting a
 	license on a web page.</para>
       </listitem>
       <listitem>
 	<para>When extracting the distfiles, some packages may ask for
 	passwords.</para>
       </listitem>
       <listitem>
 	<para>help to configure the package before it is built</para>
       </listitem>
       <listitem>
 	<para>help during the build process</para>
       </listitem>
       <listitem>
 	<para>help during the installation of a package</para>
       </listitem>
     </itemizedlist>
     <para>A package can set the <varname>INTERACTIVE_STAGE</varname>
     variable to define which stages need interaction. This should be
     done in the package's <filename>Makefile</filename>, e.g.:</para>
 <programlisting>
 INTERACTIVE_STAGE=      configure install
 </programlisting>
     <para>The user can then decide to skip this package by setting the
     <varname>BATCH</varname> variable. Packages that require interaction
     are also excluded from bulk builds.</para>
   </sect2>
   <sect2 id="handling-licenses">
     <title>Handling licenses</title>
     <para>Authors of software can choose the licence under which software
     can be copied.  The Free Software Foundation has declared some
     licenses "Free", and the Open Source Initiative has a definition of
     "Open Source".</para>
     <para>By default, pkgsrc allows packages with Free or Open Source
     licenses to be built.  To allow packages with other licenses to be
     built as well, the pkgsrc user needs to add these licenses to the
     <varname>ACCEPTABLE_LICENSES</varname> variable in &mk.conf;.  Note
     that this variable only affects which packages may be
     <emphasis>built</emphasis>, while the license terms often also
     restrict the actual use of the package and its redistribution.</para>
     <para>One might want to only install packages with a BSD license,
     or the GPL, and not the other.  The free licenses are added to the
     default <varname>ACCEPTABLE_LICENSES</varname> variable.  The pkgsrc
     user can override the default by setting the
     <varname>ACCEPTABLE_LICENSES</varname> variable with "=" instead
     of "+=".  The licenses accepted by default are defined in the
     <varname>DEFAULT_ACCEPTABLE_LICENSES</varname> variable in the file
     <filename>pkgsrc/mk/license.mk</filename>.</para>
     <para>The license tag mechanism is intended to address
     copyright-related issues surrounding building, installing and
     using a package, and not to address redistribution issues (see
     <varname>RESTRICTED</varname> and
     <varname>NO_SRC_ON_FTP</varname>, etc.).
     Packages with redistribution restrictions should set these
     tags.</para>
     <para>Denoting that a package may be copied according to a
     particular license is done by placing the license in
     <filename>pkgsrc/licenses</filename> and setting the
     <varname>LICENSE</varname> variable to a string identifying the
     license, e.g. in <filename
     role="pkg">graphics/xv</filename>:</para>
 <programlisting>
 LICENSE=        xv-license
 </programlisting>
     <para>When trying to build, the user will get a notice that the
     package is covered by a license which has not been placed in the
     <varname>ACCEPTABLE_LICENSES</varname> variable:</para>
 <programlisting>
 &cprompt; <userinput>make</userinput>
 ===> xv-3.10anb9 has an unacceptable license: xv-license.
 ===>     To view the license, enter "/usr/bin/make show-license".
 ===>     To indicate acceptance, add this line to your /etc/mk.conf:
 ===>     ACCEPTABLE_LICENSES+=xv-license
 *** Error code 1
 </programlisting>
     <para>The license can be viewed with <command>make
     show-license</command>, and if the user so chooses, the line
     printed above can be added to &mk.conf; to
     convey to pkgsrc that it should not in the future fail because of
     that license:</para>
 <programlisting>
 ACCEPTABLE_LICENSES+=xv-license
 </programlisting>
     <para>The use of <varname>LICENSE=shareware</varname>,
     <varname>LICENSE=no-commercial-use</varname>, and similar language
     is deprecated because it does not crisply refer to a particular
     license text.  Another problem with such usage is that it does not
     enable a user to tell pkgsrc to proceed for a single package
     without also telling pkgsrc to proceed for all packages with that
     tag.</para>
   <sect3 id="new-license">
   <title>Adding a package with a new license</title>
     <para>When adding a package with a new license, the following steps
     are required:</para>
     <orderedlist>
     <listitem>
     <para>Check whether the license qualifies as Free or Open Source by
     referencing <ulink
     url="https://www.gnu.org/licenses/license-list.en.html">Various
     Licenses and Comments about Them</ulink> and <ulink
     url="https://opensource.org/licenses/alphabetical">Licenses by Name |
     Open Source Initiative</ulink>.  If this is the case, the filename in
     <filename>pkgsrc/licenses/</filename> does not need the
     <filename>-license</filename> suffix, and the license name should be
     added to:</para>
     <itemizedlist>
     <listitem><para>DEFAULT_ACCEPTABLE_LICENSES in
     <filename>pkgsrc/mk/license.mk</filename></para></listitem>
     <listitem><para>default_acceptable_licenses in
     <filename>pkgsrc/pkgtools/pkg_install/files/lib/license.c</filename></para></listitem>
     </itemizedlist>
     </listitem>
     <listitem><para>The license text should be added to
     <filename>pkgsrc/licenses</filename> for displaying.  A list of known
     licenses can be seen in this directory.</para></listitem>
     </orderedlist>
   </sect3>
   <sect3 id="change-license">
   <title>Change to the license</title>
     <para>When the license changes (in a way other than formatting),
     make sure that the new license has a different name (e.g.,
     append the version number if it exists, or the date).  Just
     because a user told pkgsrc to build programs under a previous
     version of a license does not mean that pkgsrc should build
     programs under the new licenses.  The higher-level point is that
     pkgsrc does not evaluate licenses for reasonableness; the only
     test is a mechanistic test of whether a particular text has been
     approved by either of two bodies (FSF or OSI).</para>
   </sect3>
   </sect2>
   <sect2 id="restricted-packages">
     <title>Restricted packages</title>
     <para>Some licenses restrict how software may be re-distributed.
     By declaring the restrictions, package tools can
     automatically refrain from e.g. placing binary packages on FTP
     sites.</para>
     <para>There are four possible restrictions, which are
     the cross product of sources (distfiles) and binaries not being
     placed on FTP sites and CD-ROMs.  Because this is rarely the exact
     language in any license, and because non-Free licenses tend to be
     different from each other, pkgsrc adopts a definition of FTP and
     CD-ROM.
     "FTP" means making the source or binary file available over the
     Internet at no charge.
     "CD-ROM" means making the source or binary available on some kind of
     media, together with other source and binary packages, which is sold
     for a distribution charge.
     </para>
     <para>In order to encode these restrictions, the package system
     defines five make variables that can be set to note these
     restrictions:</para>
     <itemizedlist>
       <listitem>
 	<para><varname>RESTRICTED</varname></para>
 	<para>This variable should be set whenever a restriction
 	exists (regardless of its kind).  Set this variable to a
 	string containing the reason for the restriction.  It should
 	be understood that those wanting to understand the restriction
 	will have to read the license, and perhaps seek advice of
 	counsel.</para>
       </listitem>
       <listitem>
 	<para><varname>NO_BIN_ON_CDROM</varname></para>
 	<para>Binaries may not be placed on CD-ROM containing other
 	binary packages, for which a distribution charge may be made.
 	In this case, set this variable to
 	<varname>${RESTRICTED}</varname>.</para>
       </listitem>
       <listitem>
 	<para><varname>NO_BIN_ON_FTP</varname></para>
 	<para>Binaries may not made available on the Internet without
 	charge.  In this case, set this variable to
 	<varname>${RESTRICTED}</varname>.  If this variable is set,
 	binary packages will not be included on ftp.NetBSD.org.</para>
       </listitem>
       <listitem>
 	<para><varname>NO_SRC_ON_CDROM</varname></para>
 	<para>Distfiles may not be placed on CD-ROM, together with
 	other distfiles, for which a fee may be charged.  In this
 	case, set this variable to <varname>${RESTRICTED}</varname>.
 	</para>
       </listitem>
       <listitem>
 	<para><varname>NO_SRC_ON_FTP</varname></para>
 	<para>Distfiles may not made available via FTP at no charge.
 	In this case, set this variable to
 	<varname>${RESTRICTED}</varname>.  If this variable is set,
 	the distfile(s) will not be mirrored on ftp.NetBSD.org.</para>
       </listitem>
     </itemizedlist>
     <para>Please note that packages will be removed from pkgsrc when the
     distfiles are not distributable and cannot be obtained for a period
     of one full quarter branch. Packages with manual/interactive fetch
     must have a maintainer and it is his/her responsibility to ensure
     this.</para>
   </sect2>
   <sect2 id="dependencies">
     <title>Handling dependencies</title>
     <para>Your package may depend on some other package being present,
     and there are various ways of expressing this dependency.
     pkgsrc supports the <varname>DEPENDS</varname>,
     <varname>BUILD_DEPENDS</varname>,
     <varname>TOOL_DEPENDS</varname>, and
     <varname>TEST_DEPENDS</varname> definitions, the
     <varname>USE_TOOLS</varname> definition, as well as dependencies
     via <filename>buildlink3.mk</filename>, which is the preferred way
     to handle dependencies, and which uses the variables named above.
     See <xref linkend="buildlink"/> for more information.</para>
     <para>The basic difference is that the <varname>DEPENDS</varname>
     definition registers that pre-requisite in the binary package so it
     will be pulled in when the binary package is later installed, whilst
     the <varname>BUILD_DEPENDS</varname>, <varname>TOOL_DEPENDS</varname>,
     and <varname>TEST_DEPENDS</varname> definitions do not, marking a
     dependency that is only needed for building or testing the resulting
     package. See also <xref linkend="creating"/> for more information.</para>
     <para>This means that if you only need a package present whilst
     you are building or testing, it should be noted as a
     <varname>TOOL_DEPENDS</varname>,
     <varname>BUILD_DEPENDS</varname>, or
     <varname>TEST_DEPENDS</varname>.  When cross-compiling,
     <varname>TOOL_DEPENDS</varname> are <emphasis>native</emphasis>
     packages, i.e. packages for the architecture where the package
     is built;
     <varname>BUILD_DEPENDS</varname> are <emphasis>target</emphasis>
     packages, i.e., packages for the architecture for which the package
     is built.</para>
     <para>The format for a <varname>DEPENDS</varname>,
     <varname>BUILD_DEPENDS</varname>, <varname>TOOL_DEPENDS</varname>,
     and <varname>TEST_DEPENDS</varname> definition is:</para>
 <programlisting>
 &lt;pre-req-package-name&gt;:../../&lt;category&gt;/&lt;pre-req-package&gt;
 </programlisting>
     <para>Please note that the <quote>pre-req-package-name</quote>
     may include any of the wildcard version numbers recognized by
     &man.pkg.info.1;.</para>
     <orderedlist>
       <listitem>
 	<para>If your package needs another package's binaries or
 	libraries to build and run, and if that package has a
 	<filename>buildlink3.mk</filename> file available, use it:</para>
 <programlisting>
 .include "../../graphics/jpeg/buildlink3.mk"
 </programlisting>
       </listitem>
       <listitem>
 	<para>If your package needs another package's binaries or
 	libraries only for building, and if that package has a
 	<filename>buildlink3.mk</filename> file available, use it:</para>
 <programlisting>
 .include "../../graphics/jpeg/buildlink3.mk"
 </programlisting>
 	<para>but set
 	<varname>BUILDLINK_DEPMETHOD.<replaceable>jpeg</replaceable>?=build</varname>
 	to make it a build dependency only. This case is rather
 	rare.</para>
       </listitem>
       <listitem>
 	<para>If your package needs binaries from another package to build,
 	use the <varname>TOOL_DEPENDS</varname> definition:</para>
 <programlisting>
 TOOL_DEPENDS+= itstool-[0-9]*:../../textproc/itstool
 </programlisting>
       </listitem>
       <listitem>
 	<para>If your package needs static libraries to link against, header
 	files to include, etc. from another package to build,
 	use the <varname>BUILD_DEPENDS</varname> definition.</para>
 <!--
 <programlisting>
 BUILD_DEPENDS+= TODO: find a good example
 </programlisting> -->
       </listitem>
       <listitem>
 	<para>If your package needs a library with which to link and
 	there is no <filename>buildlink3.mk</filename> file
 	available, create one. Using
 	<varname>DEPENDS</varname> won't be sufficient because the
 	include files and libraries will be hidden from the compiler.</para>
       </listitem>
       <listitem>
 	<para>If your package needs some executable to be able to run
 	correctly and if there's no
 	<filename>buildlink3.mk</filename> file, this is specified
 	using the <varname>DEPENDS</varname> variable. The
 	<filename role="pkg">print/lyx</filename> package needs to
 	be able to execute the latex binary from the tex-latex-bin package
 	when it runs, and that is specified:</para>
 <programlisting>
 DEPENDS+=        tex-latex-bin-[0-9]*:../../print/tex-latex-bin
 </programlisting>
       </listitem>
       <listitem>
         <para>If your package includes a test suite that has extra
         dependencies only required for this purpose (frequently this
         can be run as a <quote>make test</quote> target), use the
         <varname>TEST_DEPENDS</varname> variable.</para>
       </listitem>
       <listitem>
 	<para>You can use wildcards in package dependencies. Note that
 	such wildcard dependencies are retained when creating binary
 	packages. The dependency is checked when installing the binary
 	package and any package which matches the pattern will be
 	used. Wildcard dependencies should be used with care.</para>
 	<para>The <quote>-[0-9]*</quote> should be used instead of
 	<quote>-*</quote> to avoid potentially ambiguous matches
 	such as <quote>tk-postgresql</quote> matching a
 	<quote>tk-*</quote> <varname>DEPENDS</varname>.</para>
 	<para>Wildcards can also be used to specify that a package
 	will only build against a certain minimum version of a
 	pre-requisite:</para>
 <programlisting>
 DEPENDS+=       ImageMagick>=6.0:../../graphics/ImageMagick
 </programlisting>
 	<para>This means that the package will build using version 6.0
 	of ImageMagick or newer. Such a dependency may be warranted
 	if, for example, the command line options of an executable
 	have changed.</para>
 	<para>If you need to depend on minimum versions of libraries,
 	set
 	<varname>BUILDLINK_API_DEPENDS.<replaceable>pkg</replaceable></varname>
 	to the appropriate pattern before including its
 	<filename>buildlink3.mk</filename> file, e.g.</para>
 <programlisting>
 BUILDLINK_API_DEPENDS.jpeg+=    jpeg>=9.0
 .include "../../graphics/jpeg/buildlink3.mk"
 </programlisting>
 	<para>For security fixes, please update the package
 	vulnerabilities file. See <xref
 	linkend="security-handling"/> for more
 	information.</para>
       </listitem>
     </orderedlist>
     <para>If your package needs files from another package to build,
     add the relevant distribution files to
     <varname>DISTFILES</varname>, so they will be extracted
     automatically. See the <filename
     role="pkg">print/ghostscript</filename> package for an example.
     (It relies on the jpeg sources being present in source form
     during the build.)</para>
   </sect2>
   <sect2 id="conflicts">
     <title>Handling conflicts with other packages</title>
     <para>Your package may conflict with other packages users might
     already have installed on their system, e.g., if your package
     installs the same set of files as another package in the pkgsrc
     tree.</para>
     <para>For example, <filename role="pkg">x11/libXaw3d</filename>
     and <filename role="pkg">x11/Xaw-Xpm</filename>
     install the same shared library, thus you set in
     <filename>pkgsrc/x11/libXaw3d/Makefile</filename>:</para>
 <programlisting>
 CONFLICTS=      Xaw-Xpm-[0-9]*
 </programlisting>
     <para>and in <filename>pkgsrc/x11/Xaw-Xpm/Makefile</filename>:</para>
 <programlisting>
 CONFLICTS=      libXaw3d-[0-9]*
 </programlisting>
     <para>&man.pkg.add.1 is able to detect attempts to install packages
     that conflict with existing packages and abort. However, in many
     situations this is too late in the process. Binary package managers
     will not know about the conflict until they attempt to install the
     package after already downloading it and all its dependencies.
     Users may also waste time building a package and its dependencies
     only to find out at the end that it conflicts with another package
     they have installed.</para>
     <para>To avoid these issues <varname>CONFLICTS</varname> entries
     should be added in all cases where it is known that packages conflict
     with each other.  These <varname>CONFLICTS</varname> entries are
     exported in &man.pkg.summary.5 files and consumed by binary package
     managers to inform users that packages cannot be installed onto
     the target system.</para>
   </sect2>
   <sect2 id="not-building-packages">
     <title>Packages that cannot or should not be built</title>
     <para>There are several reasons why a package might be
     instructed to not build under certain circumstances.  If the
     package builds and runs on most platforms, the exceptions
     should be noted with <varname>BROKEN_ON_PLATFORM</varname>.  If
     the package builds and runs on a small handful of platforms,
     set <varname>BROKEN_EXCEPT_ON_PLATFORM</varname> instead.
     Both <varname>BROKEN_ON_PLATFORM</varname> and
     <varname>BROKEN_EXCEPT_ON_PLATFORM</varname> are OS triples
     (OS-version-platform) that can use glob-style
     wildcards.</para>
     <para>If a package is not appropriate for some platforms (as
     opposed to merely broken), a different set of variables should be
     used as this affects failure reporting and statistics.
     If the package is appropriate for most platforms, the exceptions
     should be noted with <varname>NOT_FOR_PLATFORM</varname>.  If
     the package is appropriate for only a small handful of platforms
     (often exactly one), set <varname>ONLY_FOR_PLATFORM</varname> instead.
     Both <varname>ONLY_FOR_PLATFORM</varname> and
     <varname>NOT_FOR_PLATFORM</varname> are OS triples
     (OS-version-platform) that can use glob-style
     wildcards.</para>
     <para>Some packages are tightly bound to a specific version of an
     operating system, e.g. LKMs or <filename
     role="pkg">sysutils/lsof</filename>.  Such binary packages are not
     backwards compatible with other versions of the OS, and should be
     uploaded to a version specific directory on the FTP server.  Mark
     these packages by setting <varname>OSVERSION_SPECIFIC</varname> to
     <quote>yes</quote>.  This variable is not currently used by any of
     the package system internals, but may be used in the
     future.</para>
     <para>If the package should be skipped (for example, because it
     provides functionality already provided by the system), set
     <varname>PKG_SKIP_REASON</varname> to a descriptive message.  If
     the package should fail because some preconditions are not met,
     set <varname>PKG_FAIL_REASON</varname> to a descriptive
     message.</para>
   </sect2>
   <sect2 id="undeletable-packages">
     <title>Packages which should not be deleted, once installed</title>
     <para>To ensure that a package may not be deleted, once it has been
     installed, the <varname>PKG_PRESERVE</varname> definition should
     be set in the package Makefile. This will be carried into any
     binary package that is made from this pkgsrc entry. A
     <quote>preserved</quote> package will
     not be deleted using &man.pkg.delete.1; unless the
     <quote>-f</quote> option is used.</para>
   </sect2>
   <sect2 id="security-handling">
     <title>Handling packages with security problems</title>
     <para>When a vulnerability is found, this should be noted in
     <filename>localsrc/security/advisories/pkg-vulnerabilities</filename>.
     Entries in that file consist of three parts:</para>
     <itemizedlist>
       <listitem><para>package version pattern</para></listitem>
       <listitem><para>type of vulnerability (please cut'n'paste an existing one where possible)</para></listitem>
       <listitem><para>URL providing additional information about the issue</para></listitem>
     </itemizedlist>
     <para>For the package version pattern please always use `&lt;' to
     mark an upper bound (not `&lt;='!). This will avoid possible
     problems due unrelated <varname>PKGREVISION</varname> bumps not
     related to security fixes. Lower bounds can be added too, using
     '&gt;' or '&gt;='. For example,
     <quote><literal>foo&gt;=1&lt;1.2</literal></quote> would mark
     versions 1.0 (included) to 1.2 (excluded) of
     <quote><literal>foo</literal></quote> as affected by the security
     issue.</para>
     <para>Entries should always be added at the bottom of the file.</para>
     <para>When fixing packages, please modify the upper bound of the
     corresponding entry. To continue the previous example, if a fix
     was backported to version 1.1nb2, change the previous pattern to
     <quote><literal>foo&gt;=1&lt;1.1nb2</literal></quote>.</para>
     <para>To locally test a package version pattern against a
     <varname>PKGNAME</varname> you can use the <command>pkg_admin
     pmatch</command> command.</para>
     <para>The URL should be as permanent as possible and provide as
     much information about the issue as possible.  CVE entries are
     preferred.</para>
     <para>After committing that file, ask pkgsrc-security@NetBSD.org to
     update the file on ftp.NetBSD.org.</para>
     <para>After fixing the vulnerability by a patch, its
     <varname>PKGREVISION</varname> should be increased (this is of
     course not necessary if the problem is fixed by using a newer
     release of the software), and the pattern in the
     pkg-vulnerabilities file must be updated.</para>
     <para>Also, if the fix should be applied to the stable pkgsrc
     branch, be sure to submit a pullup request!</para>
     <para>Binary packages already on ftp.NetBSD.org will be handled
     semi-automatically by a weekly cron job.</para>
     <para>In case a security issue is disputed, please contact
     pkgsrc-security@NetBSD.org.</para>
   </sect2>
   <sect2 id="bumping-pkgrevision">
     <title>How to handle incrementing versions when fixing an existing package</title>
     <para>When making fixes to an existing package it can be useful
     to change the version number in <varname>PKGNAME</varname>. To
     avoid conflicting with future versions by the original author, a
     <quote>nb1</quote>, <quote>nb2</quote>, ... suffix can be used
     on package versions by setting <varname>PKGREVISION=1</varname>
     (2, ...). The <quote>nb</quote> is treated like a
     <quote>.</quote> by the package tools. e.g.</para>
 <programlisting>
 DISTNAME=       foo-17.42
 PKGREVISION=    9
 </programlisting>
     <para>will result in a <varname>PKGNAME</varname> of
     <quote>foo-17.42nb9</quote>. If you want to use the original
     value of <varname>PKGNAME</varname> without the <quote>nbX</quote>
     suffix, e.g. for setting <varname>DIST_SUBDIR</varname>, use
     <varname>PKGNAME_NOREV</varname>.</para>
     <para>When a new release of the package is released, the
     <varname>PKGREVISION</varname> should be removed, e.g. on a new
     minor release of the above package, things should be like:</para>
 <programlisting>
 DISTNAME=       foo-17.43
 </programlisting>
     <para><varname>PKGREVISION</varname> should be incremented for any
     non-trivial change in the resulting binary package.  Without a
     <varname>PKGREVISION</varname> bump, someone with the previous
     version installed has no way of knowing that their package is out
     of date.  Thus, changes without increasing
     <varname>PKGREVISION</varname> are essentially labeled "this is so
     trivial that no reasonable person would want to upgrade", and this
     is the rough test for when increasing
     <varname>PKGREVISION</varname> is appropriate.  Examples of
     changes that do not merit increasing
     <varname>PKGREVISION</varname> are:</para>
     <itemizedlist>
       <listitem><para>Changing <varname>HOMEPAGE</varname>,
       <varname>MAINTAINER</varname>, <varname>OWNER</varname>, or
       comments in Makefile.</para></listitem>
       <listitem><para>Changing build variables if the resulting binary
       package is the same.</para></listitem>
       <listitem><para>Changing
       <filename>DESCR</filename>.</para></listitem>
       <listitem><para>Adding <varname>PKG_OPTIONS</varname> if the
       default options don't change.</para></listitem>
     </itemizedlist>
     <para>Examples of changes that do merit an increase to
     <varname>PKGREVISION</varname> include:</para>
     <itemizedlist>
       <listitem><para>Security fixes</para></listitem>
       <listitem><para>Changes or additions to a patch
       file</para></listitem>
       <listitem><para>Changes to the
       <filename>PLIST</filename></para></listitem>
       <listitem><para>A dependency is changed or
       renamed.</para></listitem>
     </itemizedlist>
     <para>PKGREVISION must also be incremented when dependencies have ABI
     changes.</para>
   </sect2>
 <sect2 id="fixes.subst">
 <title>Substituting variable text in the package files (the SUBST framework)</title>
 <para>When you want to replace the same text in multiple files, or
 multiple times in the same file, it is cumbersome to maintain a patch
 file for this. This is where the SUBST framework steps in. It provides an
 easy-to-use interface for replacing text in files. It just needs the
 following information:</para>
 <itemizedlist>
 <listitem><para>In which phase of the package build cycle should the
 replacement happen?</para></listitem>
 <listitem><para>In which files should the replacement
 happen?</para></listitem>
 <listitem><para>Which text should be replaced with
 what?</para></listitem>
 </itemizedlist>
 <para>This information is encoded in a block of <varname>SUBST</varname>
 variables. A minimal example is:</para>
 <programlisting>
 SUBST_CLASSES+=         paths
 SUBST_STAGE.paths=      pre-configure
 SUBST_FILES.paths=      src/*.c
 SUBST_SED.paths=        -e 's,/usr/local,${PREFIX},g'
 </programlisting>
 <para>Translated into English, it means: In the pre-configure stage (that
 is, after applying the patches from the patches/ directory and before
 running the configure script and the portability check), replace the text
 <literal>/usr/local</literal> with the content of the variable
 <varname>PREFIX</varname>.</para>
 <para>Each SUBST block starts by appending an identifier to
 <varname>SUBST_CLASSES</varname> (note the <literal>+=</literal>). This
 identifier can be chosen freely by the package. If there should ever be
 duplicate identifiers, the pkgsrc infrastructure will catch this and fail
 early, so don't worry about name collisions.</para>
 <para>Except for <varname>SUBST_CLASSES</varname>, all variables in a
 SUBST block are parameterized using this identifier. In the remainder of
 this section, these parameterized variables are written as
 <varname>SUBST_STAGE.*</varname>.</para>
 <programlisting>
 SUBST_CLASSES+=         paths
 SUBST_STAGE.paths=      pre-configure
 SUBST_MESSAGE.paths=    Fixing absolute paths.
 SUBST_FILES.paths=      src/*.c
 SUBST_FILES.paths+=     scripts/*.sh
 SUBST_SED.paths=        -e 's,"/usr/local,"${PREFIX},g'
 SUBST_SED.paths+=       -e 's,"/var/log,"${VARBASE}/log,g'
 SUBST_VARS.paths=       LOCALBASE PREFIX PKGVERSION
 </programlisting>
 <para>To get a complete picture about the SUBST substitutions, run
 <command>bmake show-all-subst</command>. If something doesn't work as
 expected, run pkglint on the package, which detects several typical
 mistakes surrounding the SUBST blocks. For any questions that might
 remain after this, have a look at
 <filename>mk/subst.mk</filename>.</para>
 <sect3 id="fixes.subst.when">
 <title>Choosing the time where the substitutions happen</title>
 <para>The <varname>SUBST_STAGE.*</varname> is one of
 {pre,do,post}-{extract,patch,configure,build,test,install}. Of these,
 <literal>pre-configure</literal> is used most often, by far. The most
 popular stages are, in chronological order:</para>
 <variablelist>
 <varlistentry><term><literal>post-extract</literal></term>
 <listitem><para>The substitutions are applied immediately after the
 distfiles are extracted. Running <command>bmake extract</command> on the
 package will leave no traces of the original files.</para>
 <para>When the substitution applies to files for which there is also a
 patch in the <filename>patches/</filename> directory, this means that the
 patches will be computed based on the result of the substitution. When
 these patches are sent to the upstream maintainer later, to be fixed in
 the upstream package, these patches may no longer match what the upstream
 author is used to. Because of this, <literal>pre-configure</literal> is
 often a better choice.</para></listitem></varlistentry>
 <varlistentry><term><literal>pre-configure</literal></term>
 <listitem><para>The substitutions are applied after the patches from the
 <filename>patches/</filename> directory. This makes it possible to run
 <command>bmake patch</command> on the package, after which the patches
 can be edited using the tools pkgvi and mkpatches from the <filename
 role="pkg">pkgtools/pkgdiff</filename> package.</para>
 <para>When updating the patches, it is helpful to explicitly separate the
 <command>bmake patch</command> from the <command>bmake
 configure</command>, and to only edit the patches between these commands.
 Otherwise the substitutions from the SUBST block will end up in the patch
 file. When this happens in really obvious ways, pkglint will complain
 about patches that contain a hard-coded <literal>/usr/pkg</literal>
 instead of the correct and intended <literal>@PREFIX@</literal>, but it
 can only detect these really obvious
 cases.</para></listitem></varlistentry>
 <varlistentry><term><literal>do-configure</literal></term>
 <listitem><para>This stage should only be used if the package defines a
 <literal>pre-configure</literal> action itself, and the substitution must
 happen after that. Typical examples are packages that use the
 <literal>pre-configure</literal> stage to regenerate the GNU configure
 script from
 <filename>configure.ac</filename>.</para></listitem></varlistentry>
 <varlistentry><term><literal>post-configure</literal></term>
 <listitem><para>This stage is used to fix up any mistakes by the
 configure stage.</para></listitem></varlistentry>
 <varlistentry><term><literal>pre-build</literal></term>
 <listitem><para>This stage should only be used for substitutions that are
 clearly related to building the package, not for fixing the
 configuration. Substitutions for pathnames (such as replacing
 <filename>/usr/local</filename> with <literal>${PREFIX}</literal>) or
 user names (such as replacing <literal>@MY_USER@</literal> with the
 actual username) belong in pre-configure or post-configure
 instead.</para></listitem></varlistentry>
 <varlistentry><term><literal>post-build</literal></term>
 <listitem><para>Just as with pre-build, this stage should only be used
 for substitutions that are clearly related to building the package, not
 for fixing the configuration. Substitutions for pathnames (such as
 replacing <filename>/usr/local</filename> with
 <literal>${PREFIX}</literal>) or user names (such as replacing
 <literal>@MY_USER@</literal> with the actual username) belong in
 pre-configure or post-configure instead.</para>
 <para>A typical use is to update pkg-config files to include the rpath
 compiler options.</para></listitem></varlistentry>
 <varlistentry><term><literal>pre-install</literal></term>
 <listitem><para>In general, the install phase should be as simple as
 possible. As with the pre-build and post-build stages, it should not be
 used to fix pathnames or user names, these belong in pre-configure
 instead. There are only few legitimate use cases for applying
 substitutions in this stage.</para></listitem></varlistentry>
 </variablelist>
 </sect3>
 <sect3 id="fixes.subst.where">
 <title>Choosing the files where the substitutions happen</title>
 <para>The <varname>SUBST_FILES.*</varname> variable contains a list of
 filename patterns. These patterns are relative to
 <varname>WRKSRC</varname> since that is where most substitutions happen.
 A typical example is:</para>
 <programlisting>
 SUBST_FILES.path=       Makefile */Makefile */*/Makefile *.[ch]
 </programlisting>
 <para>The above patterns, especially the last, are quite broad. The SUBST
 implementation checks that each filename pattern that is mentioned here
 has an effect. For example, if none of the
 <filename>*/*/Makefile</filename> files contains the patterns to be found
 and substituted, that filename pattern is redundant and should be left
 out. By default, the SUBST framework will complain with an error message.
 If the text to be substituted occurs in some of the files from a single
 pattern, but not in all of them, that is totally ok, and the SUBST
 framework will only print an INFO message for those files.</para>
 <para>If there is a good reason for having redundant filename patterns,
 set <varname>SUBST_NOOP_OK.*</varname> to <literal>yes</literal>.</para>
 <para>Another popular way of choosing the files for the substitutions is
 via a shell command, like this:</para>
 <programlisting>
 C_FILES_CMD=            cd ${WRKSRC} &amp;&amp; ${FIND} . -name '*.c'
 SUBST_FILES.path=       ${C_FILES_CMD:sh}
 </programlisting>
 <para>The variable name <varname>C_FILES_CMD</varname> in this example is
 freely chosen and independent of the SUBST framework.</para>
 <para>In this variant, the <varname>SUBST_FILES.*</varname> variable
 lists each file individually. Thereby chances are higher that there are
 filename patterns in which no substitution happens. Since the SUBST
 framework cannot know whether the filename patterns in
 <varname>SUBST_FILES.*</varname> have been explicitly listed in the
 Makefile (where any redundant filename pattern would be suspicious) or
 been generated by a shell command (in which redundant filename patterns
 are more likely and to be expected), it will complain about these
 redundant filename patterns. Therefore, SUBST blocks that use a shell
 command to generate the list of filename patterns often need to set
 <varname>SUBST_NOOP_OK.*</varname> to <literal>yes</literal>.</para>
 </sect3>
 <sect3 id="fixes.subst.what">
 <title>Choosing what to substitute</title>
 <para>In most cases, the substitutions are given using one or more
 &man.sed.1; commands, like this:</para>
 <programlisting>
 SUBST_SED.path=         -e 's|/usr/local|${PREFIX}|g'
 </programlisting>
 <para>Each of the sed commands needs to be preceded by the
 <literal>-e</literal> option and should be specified on a line of its
 own, to avoid hiding short sed commands at the end of a line.</para>
 <para>Since the sed commands often contain shell metacharacters as the
 separator (the <literal>|</literal> in the above example), it is common
 to enclose them in single quotes.</para>
 <para>A common substitution is to replace placeholders of the form
 <literal>@VARNAME@</literal> with their pkgsrc counterpart variable
 <literal>${VARNAME}</literal>. A typical example is:</para>
 <programlisting>
 SUBST_VARS.path=        PREFIX
 </programlisting>
 <para>This type of substitutions is typically done by the GNU configure
 scripts during the do-configure stage, but in some cases these need to be
 overridden. The same pattern is also used when a package defines patches
 that replace previously hard-coded paths like
 <literal>/usr/local</literal> with a <literal>@PREFIX@</literal>
 placeholder first, which then gets substituted by the actual
 <literal>${PREFIX}</literal> in the pre-configure stage. In many of these
 cases, it works equally well to just use the SUBST framework to directly
 replace <literal>/usr/local</literal> with <literal>${PREFIX}</literal>,
 thereby omitting the intermediate patch file.</para>
 <para>If the above is not flexible enough, it is possible to not use sed
 at all for the substitution but to specify an entirely different command,
 like this:</para>
 <programlisting>
 SUBST_FILTER_CMD.path=  LC_ALL=C ${TR} -d '\r'
 </programlisting>
 <para>This is used for the few remaining packages in which the
 distributed files use Windows-style line endings that need to be
 converted to UNIX-style line endings.</para>
 </sect3>
 <sect3 id="fixes.subst.other">
 <title>Other SUBST variables</title>
 <para>When a SUBST block is applied during a package build, a message is
 logged. The default message is fine for most purposes but can be
 overridden by setting <literal>SUBST_MESSAGE.*</literal> to an individual
 message.</para>
 </sect3>
 </sect2>
 </sect1>
 <sect1 id="fixes.fetch">
   <title>The <emphasis>fetch</emphasis> phase</title>
   <sect2 id="no-plain-download">
     <title>Packages whose distfiles aren't available for plain downloading</title>
     <para>If you need to download from a dynamic URL you can set
     <varname>DYNAMIC_MASTER_SITES</varname> and a <command>make
     fetch</command> will call <filename>files/getsite.sh</filename>
     with the name of each file to download as an argument, expecting
     it to output the URL of the directory from which to download
     it. <filename role="pkg">graphics/ns-cult3d</filename> is an
     example of this usage.</para>
     <para>If the download can't be automated, because the user must
     submit personal information to apply for a password, or must pay
     for the source, or whatever, you can set
     <varname>FETCH_MESSAGE</varname> to a list of lines that are
     displayed to the user before aborting the build. Example:</para>
 <programlisting>
 FETCH_MESSAGE=  "Please download the files"
 FETCH_MESSAGE+= "    "${DISTFILES:Q}
 FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"."
 </programlisting>
   </sect2>
   <sect2 id="modified-distfiles-same-name">
     <title>How to handle modified distfiles with the 'old' name</title>
     <para>Sometimes authors of a software package make some
     modifications after the software was released, and they put up a
     new distfile without changing the package's version number. If a
     package is already in pkgsrc at that time, the checksum will
     no longer match. The contents of the new distfile should be
     compared against the old one before changing anything, to make
     sure the distfile was really updated on purpose, and that
     no trojan horse or so crept in.
     Please mention that the distfiles were compared and what was found
     in your commit message.</para>
     <para>Then, the correct way to work around this is to set
     <varname>DIST_SUBDIR</varname> to a unique directory name, usually
     based on <varname>PKGNAME_NOREV</varname> (but take care with
     python or ruby packages, where <varname>PKGNAME</varname> includes
     a variable prefix). All <varname>DISTFILES</varname> and
     <varname>PATCHFILES</varname> for this package will be put in that
     subdirectory of the local distfiles directory. (See <xref
     linkend="bumping-pkgrevision"/> for more details.) In case this
     happens more often, <varname>PKGNAME</varname> can be used (thus
     including the <filename>nbX</filename> suffix) or a date stamp can
     be appended, like
     <varname>${PKGNAME_NOREV}-YYYYMMDD</varname>.</para>
     <para><varname>DIST_SUBDIR</varname> is also used when a distfile's
     name does not contain a version and the distfile is apt to change. In
     cases where the likelihood of this is very small,
     <varname>DIST_SUBDIR</varname> might not be required. Additionally,
     <varname>DIST_SUBDIR</varname> must not be removed unless the
     distfile name changes, even if a package is being moved or
     renamed.</para>
     <para>Do not forget regenerating the <filename>distinfo</filename> file
     after that, since it contains the <varname>DIST_SUBDIR</varname>
     path in the filenames.
     Also, increase the PKGREVISION if the installed package is different.
     Furthermore, a mail to the package's authors seems appropriate
     telling them that changing distfiles after releases without
     changing the file names is not good practice.</para>
   </sect2>
   <sect2 id="build.fetch.github">
     <title>Packages hosted on github.com</title>
     <para>Helper methods exist for packages hosted on github.com which
     will often have distfile names that clash with other packages, for
     example <filename>1.0.tar.gz</filename>. Use one of the three recipes
     from below:</para>
     <sect3 id="build.fetch.github.tag">
       <title>Fetch based on a tagged release</title>
       <para>If your distfile URL looks similar to
       <literal>https://github.com/username/example/archive/v1.0.zip</literal>,
       then you are packaging a tagged release.</para>
 <programlisting>
 DISTNAME=       example-1.0
 MASTER_SITES=   ${MASTER_SITE_GITHUB:=username/}
 #GITHUB_PROJECT= example    # can be omitted if same as DISTNAME
 GITHUB_TAG=     v${PKGVERSION_NOREV}
 EXTRACT_SUFX=   .zip
 </programlisting>
     <para>Here, DISTNAME combined with use of GITHUB_TAG leads the
     file fetching infrastructure to save the resulting file locally as
     <literal>example-1.0.zip</literal>.</para>
     </sect3>
     <sect3 id="build.fetch.github.commit.prerelease">
       <title>Fetch based on a specific commit before the first release</title>
       <para>If your distfile looks similar to
       <literal>https://github.com/username/example/archive/988881adc9fc3655077dc2d4d757d480b5ea0e11</literal> and is from a commit before the first
       release, then set the package version to 0.0.0.N, where N is the number
       of commits to the repository, and set GITHUB_TAG to the commit hash.
       This will (almost) ensure that the first tagged release will have a
       version greater than this one so that package upgrades will function
       properly.</para>
 <programlisting>
 DISTNAME=       example-0.0.0.347
 MASTER_SITES=   ${MASTER_SITE_GITHUB:=username/}
 #GITHUB_PROJECT= example    # can be omitted if same as DISTNAME
 GITHUB_TAG=     988881adc9fc3655077dc2d4d757d480b5ea0e11
 </programlisting>
     </sect3>
     <sect3 id="build.fetch.github.commit.postrelease">
       <title>Fetch based on a specific commit after a release</title>
       <para>If your distfile looks similar to
       <literal>https://github.com/username/example/archive/988881adc9fc3655077dc2d4d757d480b5ea0e11</literal> and is from a commit after a release,
       then include the last release version and the commit count since that
       release in the package version and set GITHUB_TAG to the commit hash.
       The latest release and commit count are shown in the output of
       "git describe --tags":
       </para>
 <screen>
 # git clone https://github.com/username/example
 # cd example
 # git describe --tags
 .2.3-5-g988881a
 </screen>
 <programlisting>
 DISTNAME=       example-1.2.3.5
 MASTER_SITES=   ${MASTER_SITE_GITHUB:=username/}
 #GITHUB_PROJECT= example    # can be omitted if same as DISTNAME
 GITHUB_TAG=     988881adc9fc3655077dc2d4d757d480b5ea0e11
 </programlisting>
     </sect3>
     <sect3 id="build.fetch.github.release">
       <title>Fetch based on release</title>
       <para>If your distfile URL looks similar to
       <literal>https://github.com/username/example/releases/download/rel-1.6/offensive-1.6.zip</literal>,
       then you are packaging a release.</para>
 <programlisting>
 DISTNAME=       offensive-1.6
 PKGNAME=        ${DISTNAME:S/offensive/proper/}
 MASTER_SITES=   ${MASTER_SITE_GITHUB:=username/}
 GITHUB_PROJECT= example
 GITHUB_RELEASE= rel-${PKGVERSION_NOREV} # usually just set this to ${DISTNAME}
 EXTRACT_SUFX=   .zip
 </programlisting>
     </sect3>
   </sect2>
 </sect1>
 <sect1 id="fixes.configure">
   <title>The <emphasis>configure</emphasis> phase</title>
   <sect2 id="fixes.libtool">
     <title>Shared libraries - libtool</title>
     <para>pkgsrc supports many different machines, with different
     object formats like a.out and ELF, and varying abilities to do
     shared library and dynamic loading at all. To accompany this,
     varying commands and options have to be passed to the
     compiler, linker, etc. to get the Right Thing, which can be
     pretty annoying especially if you don't have all the machines
     at your hand to test things.  The
     <filename role="pkg">devel/libtool</filename> pkg
     can help here, as it just <quote>knows</quote> how to build
     both static and dynamic libraries from a set of source files,
     thus being platform-independent.</para>
     <para>Here's how to use libtool in a package in seven simple
     steps:</para>
     <orderedlist>
       <listitem>
 	<para>Add <varname>USE_LIBTOOL=yes</varname> to the package
 	Makefile.</para>
       </listitem>
       <listitem>
 	<para>For library objects, use <quote>${LIBTOOL} --mode=compile
 	${CC}</quote> in place of <quote>${CC}</quote>. You could even
 	add it to the definition of <varname>CC</varname>, if only
 	libraries are being built in a given Makefile. This one command
 	will build both PIC and non-PIC library objects, so you need not
 	have separate shared and non-shared library rules.</para>
       </listitem>
       <listitem>
 	<para>For the linking of the library, remove any
 	<quote>ar</quote>, <quote>ranlib</quote>, and <quote>ld
 	-Bshareable</quote> commands, and instead use:</para>
 <programlisting>
 ${LIBTOOL} --mode=link \
     ${CC} -o ${.TARGET:.a=.la} \
         ${OBJS:.o=.lo} \
         -rpath ${PREFIX}/lib \
         -version-info major:minor
 </programlisting>
 	<para>Note that the library is changed to have a
 	<filename>.la</filename> extension, and the objects are
 	changed to have a <filename>.lo</filename>
 	extension. Change <varname>OBJS</varname> as
 	necessary. This automatically creates all of the
 	<filename>.a</filename>,
 	<filename>.so.major.minor</filename>, and ELF symlinks (if
 	necessary) in the build directory. Be sure to include
 	<quote>-version-info</quote>, especially when major and
 	minor are zero, as libtool will otherwise strip off the
 	shared library version.</para>
 	<para>From the libtool manual:</para>
 <programlisting>
 So, libtool library versions are described by three integers:
 CURRENT
 The most recent interface number that this library implements.
 REVISION
 The implementation number of the CURRENT interface.
 AGE
 The difference between the newest and oldest interfaces that
 this library implements.  In other words, the library implements
 all the interface numbers in the range from number `CURRENT -
 AGE' to `CURRENT'.
 If two libraries have identical CURRENT and AGE numbers, then the
 dynamic linker chooses the library with the greater REVISION number.
 </programlisting>
 	<para>The <quote>-release</quote> option will produce
 	different results for a.out and ELF (excluding symlinks)
 	in only one case. An ELF library of the form
 	<quote>libfoo-release.so.<emphasis>x</emphasis>.<emphasis>y</emphasis></quote>
 	will have a symlink of
 	<quote>libfoo.so.<emphasis>x</emphasis>.<emphasis>y</emphasis></quote>
 	on an a.out platform. This is handled
 	automatically.</para>
 	<para>The <quote>-rpath argument</quote> is the install
 	directory of the library being built.</para>
 	<para>In the <filename>PLIST</filename>, include only the
 	<filename>.la</filename> file, the other files will be
 	added automatically.</para>
       </listitem>
       <listitem>
 	<para>When linking shared object (<filename>.so</filename>)
 	files, i.e. files that are loaded via &man.dlopen.3;, NOT
 	shared libraries, use <quote>-module
 	-avoid-version</quote> to prevent them getting version
 	tacked on.</para>
 	<para>The <filename>PLIST</filename> file gets the
 	<filename>foo.so</filename> entry.</para>
       </listitem>
       <listitem>
 	<para>When linking programs that depend on these libraries
 	<emphasis>before</emphasis> they are installed, preface
 	the &man.cc.1; or &man.ld.1; line with <quote>${LIBTOOL}
 	--mode=link</quote>, and it will find the correct
 	libraries (static or shared), but please be aware that
 	libtool will not allow you to specify a relative path in
 	-L (such as <quote>-L../somelib</quote>), because it
 	expects you to change that argument to be the
 	<filename>.la</filename> file. e.g.</para>
 <programlisting>
 ${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib
 </programlisting>
 	<para>should be changed to:</para>
 <programlisting>
 ${LIBTOOL} --mode=link ${CC} -o <replaceable>someprog</replaceable> <replaceable>../somelib/somelib.la</replaceable>
 </programlisting>
 	<para>and it will do the right thing with the libraries.</para>
       </listitem>
       <listitem>
 	<para>When installing libraries, preface the &man.install.1;
 	or &man.cp.1; command with <quote>${LIBTOOL}
 	--mode=install</quote>, and change the library name to
 	<filename>.la</filename>. e.g.</para>
 <programlisting>
 ${LIBTOOL} --mode=install ${BSD_INSTALL_LIB} ${SOMELIB:.a=.la} ${PREFIX}/lib
 </programlisting>
 	<para>This will install the static <filename>.a</filename>,
 	shared library, any needed symlinks, and run
 	&man.ldconfig.8;.</para>
       </listitem>
       <listitem>
 	<para>In your <filename>PLIST</filename>, include only
 	the <filename>.la</filename>
 	file (this is a change from previous behaviour).</para>
       </listitem>
     </orderedlist>
   </sect2>
   <sect2 id="using-libtool">
     <title>Using libtool on GNU packages that already support libtool</title>
     <para>Add <varname>USE_LIBTOOL=yes</varname> to the
     package Makefile. This will override the package's own libtool
     in most cases.  For older libtool using packages,  libtool is
     made by ltconfig script during the do-configure step; you can
     check the libtool script location by doing <command>make
     configure; find work*/ -name libtool</command>.</para>
     <para><varname>LIBTOOL_OVERRIDE</varname> specifies which libtool
     scripts, relative to <varname>WRKSRC</varname>, to override.  By
     default, it is set to <quote>libtool */libtool
     */*/libtool</quote>.  If this does not match the location of the
     package's libtool script(s), set it as appropriate.</para>
     <para>If you do not need <filename>*.a</filename> static
     libraries built and installed, then use
     <varname>SHLIBTOOL_OVERRIDE</varname> instead.</para>
     <para>If your package makes use of the platform-independent library
     for loading dynamic shared objects, that comes with libtool
     (libltdl), you should include devel/libltdl/buildlink3.mk.</para>
     <para>Some packages use libtool incorrectly so that the package
     may not work or build in some circumstances. Some of the more
     common errors are:</para>
     <itemizedlist>
       <listitem>
 	<para>The inclusion of a shared object (-module) as a dependent library in an
 	executable or library. This in itself isn't a problem if one of two things
 	has been done:</para>
 	<orderedlist>
 	  <listitem>
 	    <para>The shared object is named correctly, i.e.
 	    <filename>libfoo.la</filename>, not
 	    <filename>foo.la</filename></para>
 	  </listitem>
 	  <listitem>
 	    <para>The -dlopen option is used when linking an executable.</para>
 	  </listitem>
 	</orderedlist>
       </listitem>
       <listitem>
 	<para>The use of libltdl without the correct calls to initialisation routines.
 	The function lt_dlinit() should be called and the macro
 	<varname>LTDL_SET_PRELOADED_SYMBOLS</varname> included in
 	executables.</para>
       </listitem>
     </itemizedlist>
   </sect2>
   <sect2 id="autoconf-automake">
     <title>GNU Autoconf/Automake</title>
     <para>If a package needs GNU autoconf or automake to be executed
     to regenerate the
     <filename>configure</filename>
     script and <filename>Makefile.in</filename> makefile
     templates from <filename>configure.ac</filename> and
     <filename>Makefile.am</filename>,
     then they should be executed in a pre-configure target:</para>
 <programlisting>
 USE_TOOLS+=	autoconf automake autoreconf
 GNU_CONFIGURE=	yes
 ...
 pre-configure:
         set -e; cd ${WRKSRC} && autoreconf -fi
 ...
 </programlisting>
     <para>Packages which use GNU Automake will sometimes
     require GNU Make (<literal>gmake</literal> in
     <varname>USE_TOOLS</varname>),
     but not always.  Note that autoreconf
     only needs to be executed if <filename>configure.ac</filename>
     or Makefiles are modified, or <filename>configure</filename>
     is not present.</para>
     <para>There are times when the configure process makes
     additional changes to the generated files, which then causes
     the build process to try to re-execute the automake sequence.
     This is prevented by touching various files in the configure
     stage. If this causes problems with your package you can set
     <varname>AUTOMAKE_OVERRIDE=NO</varname> in the package
     Makefile.</para>
   </sect2>
   <sect2 id="meson">
     <title>Meson / ninja</title>
     <para>Packages using Meson to configure need to include:
 <programlisting>
 .include "../../devel/meson/build.mk"
 </programlisting></para>
     <para>In nearly all cases (any program with dependencies),
     pkg-config needs to be added to
     <varname>USE_TOOLS</varname>.  If the package installs
     translation files for non-English languages, also
     add msgfmt and xgettext:
 <programlisting>
 USE_TOOLS+=	pkg-config msgfmt xgettext
 </programlisting></para>
     <para>If any options need to be passed to Meson, use
     <varname>MESON_ARGS</varname> instead of
     <varname>CONFIGURE_ARGS</varname>:
 <programlisting>
 MESON_ARGS+=	-Dx11=false
 </programlisting></para>
   </sect2>
 </sect1>
 <sect1 id="programming-languages">
   <title>Programming languages</title>
   <sect2 id="basic-programming-languages">
     <title>C, C++, and Fortran</title>
     <para>Compilers for the C and C++ languages comes with
     the NetBSD base system.  By default, pkgsrc assumes that a package
     is written in C and will hide all other compilers (via the wrapper
     framework, see <xref linkend="buildlink" />).</para>
     <para>To declare which languages should be made available through
     pkgsrc's compiler wrappers, use
     the <varname>USE_LANGUAGES</varname> variable. Allowed values
     currently are:
 <programlisting>
 c99, c++, c++03, gnu++03, c++0x, gnu++0x, c++11, gnu++11,
 c++14, gnu++14, c++17, gnu++17, c++20, gnu++20, fortran,
 fortran77, java, objc, obj-c++, and ada.
 </programlisting>
     (and any combination).  The default is
     <quote>c</quote>.  Packages using GNU configure scripts, even if
     written in C++, usually need a C compiler for the configure
     phase.
     Language variants like <literal>c++11</literal>
     can be specified if the package does not explicitly set
     <literal>-std=...</literal> when compiling (i.e. the package
     assumes the compiler defaults to C++11 or some other standard).
     This is a common bug in upstream build systems.</para>
     <para>To declare which features a package requies from the
     compiler, set either <varname>USE_CC_FEATURES</varname>
     or <varname>USE_CXX_FEATURES</varname>. Allowed values for
     <varname>USE_CC_FEATURES</varname> are currently:
 <programlisting>
 c11, c99, has_include
 </programlisting>
     Allowed values for <varname>USE_CXX_FEATURES</varname> are
     currently:
 <programlisting>
 c++11, c++14, c++17, c++20, has_include, regex, filesystem,
-charconv, parallelism_ts, unique_ptr, put_time
+charconv, parallelism_ts, unique_ptr, put_time,
 is_trivially_copy_constructible
 </programlisting>
     .</para>
     </para>
   </sect2>
   <sect2 id="java-programming-language">
     <title>Java</title>
     <para>If a program is written in Java, use the Java framework in
     pkgsrc.  The package must include
     <filename>../../mk/java-vm.mk</filename>.  This Makefile fragment
     provides the following variables:</para>
     <itemizedlist>
       <listitem><para><varname>USE_JAVA</varname> defines if a build
       dependency on the JDK is added.  If
       <varname>USE_JAVA</varname> is set to <quote>run</quote>, then
       there is only a runtime dependency on the JDK.  The default is
       <quote>yes</quote>, which also adds a build dependency on the
       JDK.</para></listitem>
       <listitem><para>Set <varname>USE_JAVA2</varname> to declare that
       a package needs a Java2 implementation.  The supported values
       are <quote>yes</quote>, <quote>1.4</quote>, and
       <quote>1.5</quote>.  <quote>yes</quote> accepts any Java2
       implementation, <quote>1.4</quote> insists on versions 1.4 or
       above, and <quote>1.5</quote> only accepts versions 1.5 or
       above. This variable is not set by default.</para></listitem>
       <listitem><para><varname>PKG_JAVA_HOME</varname> is
       automatically set to the runtime location of the used Java
       implementation dependency. It may be used to set
       <varname>JAVA_HOME</varname> to a good value if the program
       needs this variable to be defined.
       </para></listitem>
       <!-- XXX: describe PKG_JVM_DEFAULT and PKG_JVMS_ACCEPTED, but
 	   not here -->
     </itemizedlist>
   </sect2>
   <sect2 id="go-programming-language">
     <title>Go</title>
     <para>If a program is written in Go and has any dependencies on
     other Go modules, have the package include
     <filename>../../lang/go/go-module.mk</filename>.</para>
     <orderedlist>
       <listitem><para>Generate a list of those dependencies with
       <command>make clean && make patch && make show-go-modules >
       go-modules.mk</command>.</para></listitem>
       <listitem><para>Prepend
       <literal>.include "go-modules.mk"</literal> to any other
       <literal>.include</literal>s.</para></listitem>
       <listitem><para>Incorporate these modules in
       <filename>distinfo</filename> with <command>make
       makesum</command>.</para></listitem>
     </orderedlist>
   </sect2>
   <sect2 id="rust-programming-language">
     <title>Rust</title>
     <para>If a program is written in Rust and uses Cargo to build,
     have the package include
     <filename>../../lang/rust/cargo.mk</filename>.</para>
     <orderedlist>
       <listitem><para>Generate a list of those dependencies with
       <command>make CARGO_ARGS="build --release" build &&
       make print-cargo-depends > cargo-depends.mk</command>.</para></listitem>
       <listitem><para>Prepend
       <literal>.include "cargo-depends.mk"</literal> to any other
       <literal>.include</literal>s.</para></listitem>
       <listitem><para>Incorporate these modules in
       <filename>distinfo</filename> with <command>make
       makesum</command>.</para></listitem>
     </orderedlist>
   </sect2>
   <sect2 id="perl-scripts">
     <title>Packages containing Perl scripts</title>
     <para>If your package contains interpreted Perl scripts, add
     <quote>perl</quote> to the <varname>USE_TOOLS</varname> variable
     and set <varname>REPLACE_PERL</varname> to ensure that the proper
     interpreter path is set. <varname>REPLACE_PERL</varname> should
     contain a list of scripts, relative to <varname>WRKSRC</varname>,
     that you want adjusted. Every occurrence of
     <filename>*/bin/perl</filename> in a she-bang line will be
     replaced with the full path to the Perl executable.</para>
     <para>If a particular version of Perl is needed, set the
     <varname>PERL5_REQD</varname> variable to the version number.  The
     default is <quote>5.0</quote>.</para>
     <para>See <xref linkend="perl-modules" /> for information
     about handling Perl modules.</para>
     <para>There is also the <varname>REPLACE_PERL6</varname> variable
     for the language now known as Raku.</para>
   </sect2>
   <sect2 id="shell-scripts">
     <title>Packages containing shell scripts</title>
     <para><varname>REPLACE_SH</varname>,
     <varname>REPLACE_BASH</varname>, <varname>REPLACE_CSH</varname>,
     and <varname>REPLACE_KSH</varname> can be used to replace shell
     she-bangs in files. Please use the appropriate one, preferring
     <varname>REPLACE_SH</varname> when this shell is sufficient.
     Each should contain a list of scripts, relative to
     <varname>WRKSRC</varname>, that you want adjusted. Every
     occurrence of the matching shell in a she-bang line will be
     replaced with the full path to the shell executable.
     When using <varname>REPLACE_BASH</varname>, don't forget to add
     <filename>bash</filename> to <varname>USE_TOOLS</varname>.</para>
   </sect2>
   <sect2 id="other-programming-languages">
     <title>Other programming languages</title>
     <para>There are further similar REPLACE variables available, e.g.,
     <varname>REPLACE_AWK</varname> for packages containing awk scripts,
     and <varname>REPLACE_R</varname> for R. These two, like the others
     noted above, have their actions defined centrally in
     <filename>mk/configure/replace-interpreter.mk</filename>. Other
     languages define the actions of these variables within their own
     dedicated part of the tree, e.g., <varname>REPLACE_PHP</varname> is
     actioned in <filename>lang/php/phpversion.mk</filename>, and
     <varname>REPLACE_PYTHON</varname> is actioned in
     <filename>lang/python/application.mk</filename>. For other languages,
     consult the mk files found within their specific directories (the
     naming convention varies), or check the list found in
     <xref linkend="help-topics" />.</para>
     <para>Currently, special handling for other languages varies
     in pkgsrc.  If a compiler package provides a
     <filename>buildlink3.mk</filename> file, include that, otherwise
     just add a (build) dependency on the appropriate compiler
     package.</para>
   </sect2>
 </sect1>
 <sect1 id="fixes.build">
   <title>The <emphasis>build</emphasis> phase</title>
 	<para>The most common failures when building a package are that
 	some platforms do not provide certain header files, functions or
 	libraries, or they provide the functions in a library that the
 	original package author didn't know. To work around this, you
 	can rewrite the source code in most cases so that it does not
 	use the missing functions or provides a replacement function.</para>
 <sect2 id="fixes.build.cpp">
 <title>Compiling C and C++ code conditionally</title>
 	<para>If a package already comes with a GNU configure script, the
 	preferred way to fix the build failure is to change the
 	configure script, not the code. In the other cases, you can
 	utilize the C preprocessor, which defines certain macros
 	depending on the operating system and hardware architecture it
 	compiles for. These macros can be queried using for example
 	<varname>#if defined(__i386)</varname>. Almost every operating
 	system, hardware architecture and compiler has its own macro.
 	For example, if the macros <varname>__GNUC__</varname>,
 	<varname>__i386__</varname> and <varname>__NetBSD__</varname>
 	are all defined, you know that you are using NetBSD on an i386
 	compatible CPU, and your compiler is GCC.</para>
 	<para>The list of the following macros for hardware and
 	operating system depends on the compiler that is used. For
 	example, if you want to conditionally compile code on Solaris,
 	don't use <varname>__sun__</varname>, as the SunPro compiler
 	does not define it. Use <varname>__sun</varname> instead.</para>
 <sect3 id="fixes.build.cpp.os">
 <title>C preprocessor macros to identify the operating system</title>
         <para>To distinguish between specific NetBSD versions,
         you should use the following code.</para>
 <programlisting>
 #ifdef __NetBSD__
 #include &lt;sys/param.h&gt;
 #if __NetBSD_Prereq__(9,99,17)
 /* use a newer feature */
 #else
 /* older code */
 #endif
 #endif
 #ifndef _WIN32
 /* Unix-like specific code */
 #endif
 </programlisting>
         <para>To distinguish between 4.4 BSD-derived systems and the
         rest of the world, you should use the following code.</para>
 <programlisting>
 #include &lt;sys/param.h&gt;
 #if (defined(BSD) &amp;&amp; BSD &gt;= 199306)
 /* BSD-specific code goes here */
 #else
 /* non-BSD-specific code goes here */
 #endif
 </programlisting>
         <para>You can also test for the following macros:</para>
 <programlisting>
 Cygwin      __CYGWIN__
 DragonFly   __DragonFly__
 FreeBSD     __FreeBSD__
 Haiku       __HAIKU__
 Interix     __INTERIX
 IRIX        __sgi (TODO: get a definite source for this)
 Linux       __linux
 Mac OS X    __APPLE__
 MirBSD      __MirBSD__ (__OpenBSD__ is also defined)
 Minix3      __minix
 NetBSD      __NetBSD__
 OpenBSD     __OpenBSD__
 Solaris     sun, __sun
 </programlisting>
 </sect3>
 <sect3 id="fixes.build.cpp.arch">
 <title>C preprocessor macros to identify the hardware architecture</title>
 <programlisting>
 i386        i386, __i386, __i386__
 x86-64      __amd64__, __x86_64__
 ARM         __arm__
 MIPS        __mips
 SPARC       sparc, __sparc
 PowerPC     __powerpc
 </programlisting>
 </sect3>
 <sect3 id="fixes.build.cpp.compiler">
 <title>C preprocessor macros to identify the compiler</title>
 <programlisting>
 GCC         __GNUC__ (major version), __GNUC_MINOR__
 MIPSpro     _COMPILER_VERSION (0x741 for MIPSpro 7.41)
 SunPro      __SUNPRO_C (0x570 for Sun C 5.7)
 SunPro C++  __SUNPRO_CC (0x580 for Sun C++ 5.8)
 </programlisting>
 </sect3>
 </sect2>
 <sect2 id="compiler-bugs">
 <title>How to handle compiler bugs</title>
 	<para>Some source files trigger bugs in the compiler, based on
         combinations of compiler version and architecture and almost
         always relation to optimisation being enabled.  Common symptoms
         are gcc internal errors or never finishing compiling a
 	file.</para>
 	<para>Typically, a workaround involves testing the
         <varname>MACHINE_ARCH</varname> and compiler version, disabling
         optimisation for that combination of file,
 	<varname>MACHINE_ARCH</varname> and compiler.</para>
 	<para>This used to be a big problem in the past, but is rarely
 	needed now as compiler technology has matured. If you still need
 	to add a compiler specific workaround, please do so in the file
 	<filename>hacks.mk</filename> and describe the symptom and
 	compiler version as detailed as possible.</para>
 </sect2>
 <sect2 id="fixes.build.header">
 <title>No such file or directory</title>
 <para>Compilation sometimes fails with an error message like this:</para>
 <programlisting>
 .../x11/gtk3/work/gtk+-3.24.12/gdk/gdktypes.h:35:10:
     fatal error: pango/pango.h: No such file or directory
 </programlisting>
 <para>The proper way to fix this problem depends on the type of the
 header, which is described in the following sections.</para>
 <sect3 id="fixes.build.header.bl3">
 <title>Headers from other packages</title>
 <para>If the header name looks like it comes from a different package,
 that other package should be included via the buildlink3
 framework.</para>
 <para>First, look whether the header is somewhere in the buildlink3
 directory below <varname>WRKDIR</varname>. In the above case of
 the missing Pango header:</para>
 <programlisting>
 &uprompt; find work/.buildlink/ -print | grep -F pango/pango.h
 </programlisting>
 <para>In the case of Pango, the output is:</para>
 <programlisting>
 work/.buildlink/include/pango-1.0/pango/pango.h
 </programlisting>
 <para>If the <filename>pango/pango.h</filename> file were placed directly
 in the <filename>.buildlink</filename> directory, it would have been
 found automatically. There is an extra <filename>pango-1.0</filename>
 path component though, which means that the compiler command line must
 contain an option of the form
 <literal>-I${BUILDLINK3_PREFIX.pango}/include/pango-1.0</literal>. In
 most cases this option is generated by the configure script, which can be examined using:</para>
 <programlisting>
 &uprompt; $ grep -o '[-]I[^[:space:]]*/pango[^[:space:]]*' work/*/Makefile
 -I/usr/pkg/include/pango-1.0
 -I/usr/pkg/include/pango-1.0
 -I/usr/pkg/include/pango-1.0
 -I/usr/pkg/include/pango-1.0
 -I/usr/pkg/include/pango-1.0
 </programlisting>
 <para>This looks good. These options are transformed by the buildlink
 wrapper to refer to the correct path inside
 <filename>work/.buildlink</filename>.</para>
 <para>Since the compilation fails though, examine the compiler command
 lines in <filename>work/.work.log</filename> to see whether the
 <literal>-I</literal> option is included in the particular command
 line.</para>
 <para>To further analyze the situation, run <command>bmake
 build-env</command>, which sets up an interactive, realistic environment
 including all the pkgsrc wrapper commands and environment variables. From
 there, try to compile some simple example programs that use the
 header.</para>
 </sect3>
 <sect3 id="fixes.build.header.gen">
 <title>Headers generated during the build</title>
 <para>If the name of the header seems to come from the package itself,
 and if the build is run with parallel jobs, the package may have some
 undeclared dependencies between the <filename>.c</filename> and the
 <filename>.h</filename> files, and a C file is compiled before its
 required header is generated.</para>
 <para>To see whether the build runs with parallel jobs, run
 <command>bmake show-all-build | grep JOBS</command>. Its output looks
 like this:</para>
 <programlisting>
   usr   MAKE_JOBS=              7
   pkg   MAKE_JOBS_SAFE          # undefined
   def   _MAKE_JOBS_N=           7
 </programlisting>
 <para>In this case the pkgsrc user has asked pkgsrc to build packages
 with 7 jobs in parallel (<varname>MAKE_JOBS</varname>). The
 package could have disabled parallel builds by setting
 <varname>MAKE_JOBS_SAFE</varname> to <literal>no</literal>, but
 in this case it hasn't.</para>
 <para>To see whether the build failure is caused by parallel builds,
 first save the exact error message and a bit of context, maybe you need
 it later for reporting a bug. Next, run:</para>
 <programlisting>
 MAKE_JOBS_SAFE=no bmake clean build
 </programlisting>
 <para>If that succeeds, <ulink
 url="https://www.NetBSD.org/cgi-bin/sendpr.cgi?gndb=netbsd">file a bug
 report</ulink> against the pkgsrc package, including the exact error
 message and the contents of your &mk.conf; file.</para>
 </sect3>
 <sect3 id="fixes.build.header.symlink">
 <title>Symlinks</title>
 <para>Pkgsrc does not work reliably if any of
 <varname>LOCALBASE</varname>, <varname>VARBASE</varname> or
 <varname>WRKDIR</varname> contains a symlink. Since 2019Q2, the pkgsrc
 bootstrap program prevents installing pkgsrc in symlink-based
 directories. Existing pkgsrc installations are not checked for symlinks
 though.</para>
 <para>The "No such file or directory" error messages are a typical
 symptom of symlinks, and it's quite difficult to find out that this is
 the actual cause.</para>
 </sect3>
 <sect3 id="fixes.build.header.stale">
 <title>Stale working directories</title>
 <para>When building a hierarchy of packages, it may happen that one
 package is built and then pkgsrc is updated. This situation can provoke
 various hard to diagnose build errors. To clean up the situation:</para>
 <programlisting>
 &uprompt; (cd ../../ && cat mk/bsd.pkg.mk >/dev/null && rm -rf */*/work)
 </programlisting>
 <para>(The only purpose of the <filename>bsd.pkg.mk</filename> is to
 prevent running this command in the wrong directory.)</para>
 <para>If you have set <varname>WRKOBJDIR</varname> in &mk.conf;, remove
 that directory as well.</para>
 </sect3>
 <sect3 id="fixes.build.header.misc">
 <title>Other possible reasons</title>
 <para>On platforms other than BSD, third-party packages are installed in
 <filename>/usr/include</filename>, together with the base system. This
 means that pkgsrc cannot distinguish between headers provided by the base
 system (which it needs) and headers from third-party packages (which are
 often included in pkgsrc as well). This can lead to subtle version
 mismatches.</para>
 <para>In pkgsrc installations that have been active for several years, it
 may happen that some files are manually deleted. To exclude this unlikely
 reason, run <command>pkg_admin check</command>.</para>
 <para>It may help to run <command>pkg_admin rebuild-tree</command> to
 check/fix dependencies.</para>
 <para>If all of the above doesn't help, see <xref linkend="help-user"/>
 for contact information. Be prepared to describe what you have tried so
 far and what any error messages were.</para>
 </sect3>
 </sect2>
 <sect2 id="undefined-reference">
 <title>Undefined reference to <quote>...</quote></title>
 	<para>This error message often means that a package did not
 	link to a shared library it needs. The following functions are
 	known to cause this error message over and over.</para>
     <informaltable id="undefined-reference-functions">
       <tgroup cols="3">
 	<thead><row><entry>Function</entry><entry>Library</entry><entry>Affected platforms</entry></row></thead>
 	<tbody>
 	  <row><entry>accept, bind, connect</entry><entry>-lsocket</entry><entry>Solaris</entry></row>
 	  <row><entry>crypt</entry><entry>-lcrypt</entry><entry>DragonFly, NetBSD</entry></row>
 	  <row><entry>dlopen, dlsym</entry><entry>-ldl</entry><entry>Linux</entry></row>
 	  <row><entry>gethost*</entry><entry>-lnsl</entry><entry>Solaris</entry></row>
 	  <row><entry>inet_aton</entry><entry>-lresolv</entry><entry>Solaris</entry></row>
 	  <row><entry>nanosleep, sem_*, timer_*</entry><entry>-lrt</entry><entry>Solaris</entry></row>
 	  <row><entry>openpty</entry><entry>-lutil</entry><entry>Linux</entry></row>
 	</tbody>
       </tgroup>
     </informaltable>
     <para>To fix these linker errors, it is often sufficient to add
     <literal>LIBS.<replaceable>OperatingSystem</replaceable>+=
     -l<replaceable>foo</replaceable></literal> to the package
     <filename>Makefile</filename> and then run <command>bmake clean;
     bmake</command>.</para>
 <sect3 id="undefined-reference-sunpro">
 <title>The SunPro compiler and inline functions</title>
 <para>When you are using the SunPro compiler, there is another
 possibility. That compiler cannot handle the following code:</para>
 <programlisting>
 extern int extern_func(int);
 static inline int
 inline_func(int x)
+{
         return extern_func(x);
+}
 int main(void)
+{
         return 0;
+}
 </programlisting>
 <para>It generates the code for <function>inline_func</function> even if
 that function is never used. This code then refers to
 <function>extern_func</function>, which can usually not be resolved. To
 solve this problem you can try to tell the package to disable inlining
 of functions.</para>
 </sect3>
 <sect3 id="undefined-reference-atomic">
   <title>Missing atomic functions</title>
   <para>When building for older machine architectures (e.g., i386, PowerPC),
   builds may fail because the package expects modern 64-bit atomic functions
   which the underlying hardware either doesn't support, or will only support
   with specific compiler flags. This is generally handled via inclusion of
   mk/atomic64.mk.</para>
 </sect3>
 </sect2>
   <sect2 id="out-of-memory">
     <title>Running out of memory</title>
     <para>Sometimes packages fail to build because the compiler runs
     into an operating system specific soft limit.  With the
     <varname>UNLIMIT_RESOURCES</varname> variable pkgsrc can be told
     to unlimit the resources.  The allowed values are any combination of
     <quote>cputime</quote>,
     <quote>datasize</quote>,
     <quote>memorysize</quote>,
     <quote>stacksize</quote> and
     <quote>virtualsize</quote>.
     Setting this variable is similar to running the shell builtin
     <command>ulimit</command> command to raise the maximum data
     segment size or maximum stack size of a process, respectively, to
     their hard limits.</para>
   </sect2>
 </sect1>
 <sect1 id="fixes.install">
   <title>The <emphasis>install</emphasis> phase</title>
   <sect2 id="install-scripts">
     <title>Creating needed directories</title>
     <para>The BSD-compatible <command>install</command> supplied
     with some operating systems cannot create more than one
     directory at a time. As such, you should call
     <literal>${INSTALL_*_DIR}</literal> like this:</para>
 <programlisting>
 ${INSTALL_DATA_DIR} ${PREFIX}/dir1
 ${INSTALL_DATA_DIR} ${PREFIX}/dir2
 </programlisting>
     <para>Instead of running the <command>install</command> commands
     directly, you can also append <quote><literal>dir1
     dir2</literal></quote> to the <varname>INSTALLATION_DIRS</varname>
     variable, which will automatically do the right thing.</para>
   </sect2>
   <sect2 id="where-to-install-documentation">
     <title>Where to install documentation</title>
     <para>In general, documentation should be installed into
     <filename>${PREFIX}/share/doc/${PKGBASE}</filename> or
     <filename>${PREFIX}/share/doc/${PKGNAME_NOREV}</filename> (the latter
     includes the version number of the package).</para>
     <para>Many modern packages using GNU autoconf allow to set the
     directory where HTML documentation is installed with the
     <quote>--with-html-dir</quote> option. Sometimes using this flag is
     needed because otherwise the documentation ends up in
     <filename>${PREFIX}/share/doc/html</filename> or other places. In
     pkgsrc, the HTML documentation should go into the package-specific
     directory, just like any other documentation.</para>
     <para>An exception to the above is that library API documentation
     generated with the <filename
     role="pkg">textproc/gtk-doc</filename> tools, for use by special
     browsers (devhelp) should be left at their default location, which
     is <filename>${PREFIX}/share/gtk-doc</filename>.  Such
     documentation can be recognized from files ending in
     <filename>.devhelp</filename> or <filename>.devhelp2</filename>.
     (It is also acceptable to install such files in
     <filename>${PREFIX}/share/doc/${PKGBASE}</filename> or
     <filename>${PREFIX}/share/doc/${PKGNAME}</filename>; the
     <filename>.devhelp*</filename> file must be directly in that
     directory then, no additional subdirectory level is allowed in
     this case. This is usually achieved by using
     <quote>--with-html-dir=${PREFIX}/share/doc</quote>.
     <filename>${PREFIX}/share/gtk-doc</filename> is preferred
     though.)</para>
   </sect2>
   <sect2 id="installing-score-files">
     <title>Installing highscore files</title>
     <para>Certain packages, most of them in the games category, install
     a score file that allows all users on the system to record their
     highscores.  In order for this to work, the binaries need to be
     installed setgid and the score files owned by the appropriate
     group and/or owner (traditionally the "games" user/group).  Set
     <varname>USE_GAMESGROUP</varname> to yes to support this. The
     following variables, documented in more detail in
     <filename>mk/defaults/mk.conf</filename>, control this
     behaviour: <varname>GAMEDATAMODE</varname>,
     <varname>GAMEDIRMODE</varname>, <varname>GAMES_GROUP</varname>,
     <varname>GAMEMODE</varname>, <varname>GAME_USER</varname>.
     Other useful variables are: <varname>GAMEDIR_PERMS</varname>,
     <varname>GAMEDATA_PERMS</varname> and
     <varname>SETGID_GAMES_PERMS</varname>.</para>
     <para>An example that illustrates some of the variables described above is
     <filename>games/moon-buggy</filename>. <varname>OWN_DIRS_PERMS</varname> is
     used to properly set directory permissions of the directory where the
     scorefile is saved, <varname>REQD_FILES_PERMS</varname> is used to create a
     dummy scorefile (<filename>mbscore</filename>) with the proper permissions
     and <varname>SPECIAL_PERMS</varname> is used to install setgid the game
     binary:</para>
 <programlisting>
 USE_GAMESGROUP=         yes
 BUILD_DEFS+=            VARBASE
 OWN_DIRS_PERMS+=        ${VARBASE}/games/moon-buggy ${GAMEDIR_PERMS}
 REQD_FILES_PERMS+=      /dev/null ${VARBASE}/games/moon-buggy/mbscore ${GAMEDATA_PERMS}
 SPECIAL_PERMS+=         ${PREFIX}/bin/moon-buggy ${SETGID_GAMES_PERMS}
 </programlisting>
     <para>Various <varname>INSTALL_*</varname> variables are also available:
     <varname>INSTALL_GAME</varname> to install setgid game binaries,
     <varname>INSTALL_GAME_DIR</varname> to install game directories that are
     needed to be accessed by setgid games and
     <varname>INSTALL_GAME_DATA</varname> to install scorefiles.</para>
     <para>A package should therefore never hard code file ownership or
     access permissions but rely on <varname>*_PERMS</varname> as described above
     or alternatively on <varname>INSTALL_GAME</varname>,
     <varname>INSTALL_GAME_DATA</varname> and
     <varname>INSTALL_GAME_DIR</varname> to set these correctly.</para>
   </sect2>
   <sect2 id="destdir-support">
     <title>Adding DESTDIR support to packages</title>
     <para><varname>DESTDIR</varname> support means that a package
     installs into a staging directory, not the final location of the
     files. Then a binary package is created which can be used for
     installation as usual. There are two ways: Either the package must
     install as root (<quote>destdir</quote>) or the package can
     install as non-root user (<quote>user-destdir</quote>).</para>
     <itemizedlist>
       <listitem><para><varname>PKG_DESTDIR_SUPPORT</varname> has to be
       set to <quote>destdir</quote> or <quote>user-destdir</quote>.
       By default <varname>PKG_DESTDIR_SUPPORT</varname>
       is set to <quote>user-destdir</quote> to help catching more
       potential packaging problems. If bsd.prefs.mk is included in the Makefile,
       <varname>PKG_DESTDIR_SUPPORT</varname> needs to be set before
       the inclusion.</para></listitem>
       <listitem><para>All installation operations have to be prefixed with
       <filename>${DESTDIR}</filename>.</para></listitem>
       <listitem><para>automake gets this DESTDIR mostly right
       automatically. Many manual rules and pre/post-install often are
       incorrect; fix them.</para></listitem>
       <listitem><para>If files are installed with special owner/group
       use <varname>SPECIAL_PERMS</varname>.</para></listitem>
       <listitem><para>In general, packages should support
       <varname>UNPRIVILEGED</varname> to be able to use
       DESTDIR.</para></listitem>
     </itemizedlist>
   </sect2>
   <sect2 id="hardcoded-paths">
     <title>Packages with hardcoded paths to other interpreters</title>
     <para>Your package may also contain scripts with hardcoded paths to
       other interpreters besides (or as well as) Perl.  To correct the
       full pathname to the script interpreter, you need to set the
       following definitions in your <filename>Makefile</filename> (we
     shall use <command>tclsh</command> in this example):</para>
 <programlisting>
 REPLACE_INTERPRETER+=   tcl
 REPLACE.tcl.old=        .*/bin/tclsh
 REPLACE.tcl.new=        ${PREFIX}/bin/tclsh
 REPLACE_FILES.tcl=      # list of tcl scripts which need to be fixed,
 # relative to ${WRKSRC}, just as in REPLACE_PERL
 </programlisting>
   </sect2>
   <sect2 id="perl-modules">
     <title>Packages installing Perl modules</title>
     <para>Makefiles of packages providing perl5 modules should include
     the Makefile fragment
     <filename>../../lang/perl5/module.mk</filename>.  It provides a
     <command>do-configure</command> target for the standard perl
     configuration for such modules as well as various hooks to tune
     this configuration.  See comments in this file for
     details.</para>
     <para>Perl5 modules will install into different places depending
     on the version of perl used during the build process.  To
     address this, pkgsrc will append lines to the
     <filename>PLIST</filename> corresponding to the files listed in
     the installed <filename>.packlist</filename> file generated by
     most perl5 modules.  This is invoked by defining
     <varname>PERL5_PACKLIST</varname> to a space-separated list of
     packlist files relative to <varname>PERL5_PACKLIST_DIR</varname>
     (<varname>PERL5_INSTALLVENDORARCH</varname> by default),
     e.g.:</para>
 <programlisting>
 PERL5_PACKLIST= auto/Pg/.packlist
 </programlisting>
     <para>The perl5 config variables
     <varname>installarchlib</varname>,
     <varname>installscript</varname>,
     <varname>installvendorbin</varname>,
     <varname>installvendorscript</varname>,
     <varname>installvendorarch</varname>,
     <varname>installvendorlib</varname>,
     <varname>installvendorman1dir</varname>, and
     <varname>installvendorman3dir</varname> represent those
     locations in which components of perl5 modules may be installed,
     provided as variable with uppercase and prefixed with
     <varname>PERL5_</varname>, e.g. <varname>PERL5_INSTALLARCHLIB</varname>
     and may be used by perl5 packages that don't have a packlist.
     These variables are also substituted for in the
     <filename>PLIST</filename> as uppercase prefixed with
     <varname>PERL5_SUB_</varname>.</para>
   </sect2>
   <sect2 id="faq.info-files">
     <title>Packages installing info files</title>
     <para>Some packages install info files or use the
     <quote>makeinfo</quote>  or <quote>install-info</quote>
     commands.  <varname>INFO_FILES</varname> should be defined in
     the package Makefile so that <filename>INSTALL</filename> and
     <filename>DEINSTALL</filename> scripts will be generated to
     handle registration of the info files in the Info directory
     file. The <quote>install-info</quote> command used for the info
     files registration is either provided by the system, or by a
     special purpose package automatically added as dependency if
     needed.</para>
     <para><varname>PKGINFODIR</varname> is the directory under
     <filename>${PREFIX}</filename> where info files are primarily
     located. <varname>PKGINFODIR</varname> defaults to
     <quote>info</quote> and can be overridden by the user.</para>
     <para>The info files for the package should be listed in the
     package <filename>PLIST</filename>; however any split info files
     need not be listed.</para>
     <para>A package which needs the <quote>makeinfo</quote> command
     at build time must add <quote>makeinfo</quote> to
     <varname>USE_TOOLS</varname> in its Makefile. If a minimum
     version of the <quote>makeinfo</quote> command is needed it
     should be noted with the <varname>TEXINFO_REQD</varname>
     variable in the package <filename>Makefile</filename>. By
     default, a minimum version of 3.12 is required. If the system
     does not provide a <command>makeinfo</command> command or if it
     does not match the required minimum, a build dependency on the
     <filename role="pkg">devel/gtexinfo</filename> package will
     be added automatically.</para>
     <para>The build and installation process of the software provided
     by the package should not use the
     <command>install-info</command> command as the registration of
     info files is the task of the package
     <filename>INSTALL</filename> script, and it must use the
     appropriate <command>makeinfo</command> command.</para>
     <para>To achieve this goal, the pkgsrc infrastructure creates
     overriding scripts for the <command>install-info</command> and
     <command>makeinfo</command> commands in a directory listed early
     in <varname>PATH</varname>.</para>
     <para>The script overriding <command>install-info</command> has
     no effect except the logging of a message. The script overriding
     <command>makeinfo</command> logs a message and according to the
     value of <varname>TEXINFO_REQD</varname> either runs the appropriate
     <command>makeinfo</command> command or exit on error.</para>
   </sect2>
   <sect2 id="manpages">
     <title>Packages installing man pages</title>
     <para>All packages that install manual pages should install them
     into the same directory, so that there is one common place to look
     for them. In pkgsrc, this place is
     <literal>${PREFIX}/${PKGMANDIR}</literal>, and this expression
     should be used in packages. The default for
     <varname>PKGMANDIR</varname> is
     <quote><filename>man</filename></quote>. Another often-used value
     is <quote><filename>share/man</filename></quote>.</para>
     <note><para>The support for a custom <varname>PKGMANDIR</varname>
     is far from complete.</para></note>
     <para>The <filename>PLIST</filename> files can just use
     <filename>man/</filename> as the top level directory for the man
     page file entries, and the pkgsrc framework will convert as
     needed. In all other places, the correct
     <varname>PKGMANDIR</varname> must be used.</para>
     <para>Packages that are
     configured with <varname>GNU_CONFIGURE</varname> set as
     <quote>yes</quote>, by default will use the
     <filename>./configure</filename>
     --mandir switch to set where the man pages should be installed.
     The path is <varname>GNU_CONFIGURE_MANDIR</varname> which defaults
     to <varname>${PREFIX}/${PKGMANDIR}</varname>.</para>
     <para>Packages that use <varname>GNU_CONFIGURE</varname> but do not
     use --mandir, can set <varname>CONFIGURE_HAS_MANDIR</varname>
     to <quote>no</quote>.
     Or if the <filename>./configure</filename> script uses
     a non-standard use of --mandir, you can set
     <varname>GNU_CONFIGURE_MANDIR</varname> as needed.</para>
     <para>See <xref linkend="manpage-compression"/> for
     information on installation of compressed manual pages.</para>
   </sect2>
   <sect2 id="x11-fonts">
     <title>Packages installing X11 fonts</title>
     <para>If a package installs font files, you will need to rebuild
     the fonts database in the directory where they get installed at
     installation and deinstallation time.  This can be automatically
     done by using the pkginstall framework.</para>
     <para>You can list the directories where fonts are installed in the
     <varname>FONTS_DIRS.<replaceable>type</replaceable></varname>
     variables, where <replaceable>type</replaceable> can be one of
     <quote>ttf</quote>, <quote>type1</quote> or <quote>x11</quote>.
     Also make sure that the database file
     <filename>fonts.dir</filename> is not listed in the PLIST.</para>
     <para>Note that you should not create new directories for fonts;
     instead use the standard ones to avoid that the user needs to
     manually configure his X server to find them.</para>
   </sect2>
   <sect2 id="sgml-xml-data">
     <title>Packages installing SGML or XML data</title>
     <para>If a package installs SGML or XML data files that need to be
     registered in system-wide catalogs (like DTDs, sub-catalogs,
     etc.), you need to take some extra steps:</para>
     <orderedlist>
       <listitem>
 	<para>Include
 	<filename>../../textproc/xmlcatmgr/catalogs.mk</filename> in
 	your <filename>Makefile</filename>, which takes care of
 	registering those files in system-wide catalogs at
 	installation and deinstallation time.</para>
       </listitem>
       <listitem>
 	<para>Set <varname>SGML_CATALOGS</varname> to the full path of
 	any SGML catalogs installed by the package.</para>
       </listitem>
       <listitem>
 	<para>Set <varname>XML_CATALOGS</varname> to the full path of
 	any XML catalogs installed by the package.</para>
       </listitem>
       <listitem>
 	<para>Set <varname>SGML_ENTRIES</varname> to individual entries
 	to be added to the SGML catalog.  These come in groups of
 	three strings; see xmlcatmgr(1) for more information
 	(specifically, arguments recognized by the 'add' action).
 	Note that you will normally not use this variable.</para>
       </listitem>
       <listitem>
 	<para>Set <varname>XML_ENTRIES</varname> to individual entries
 	to be added to the XML catalog.  These come in groups of three
 	strings; see xmlcatmgr(1) for more information (specifically,
 	arguments recognized by the 'add' action).  Note that you will
 	normally not use this variable.</para>
       </listitem>
     </orderedlist>
   </sect2>
   <sect2 id="mime-database">
     <title>Packages installing extensions to the MIME database</title>
     <para>If a package provides extensions to the MIME database by
     installing <filename>.xml</filename> files inside
     <filename>${PREFIX}/share/mime/packages</filename>, you
     need to take some extra steps to ensure that the database is kept
     consistent with respect to these new files:</para>
     <orderedlist>
       <listitem>
 	<para>Include
 	<filename>../../databases/shared-mime-info/mimedb.mk</filename>
 	(avoid using the <filename>buildlink3.mk</filename> file from
 	this same directory, which is reserved for inclusion from
 	other <filename>buildlink3.mk</filename> files).  It takes
 	care of rebuilding the MIME database at installation and
 	deinstallation time, and disallows any access to it directly
 	from the package.</para>
       </listitem>
       <listitem>
 	<para>Check the PLIST and remove any entries under the
 	<filename>share/mime</filename> directory,
 	<emphasis>except</emphasis> for files saved under
 	<filename>share/mime/packages</filename>.  The former are
 	handled automatically by
 	the update-mime-database program, but the latter are
 	package-dependent and must be removed by the package that
 	installed them in the first place.</para>
       </listitem>
       <listitem>
 	<para>Remove any <filename>share/mime/*</filename> directories
 	from the PLIST.  They will be handled by the shared-mime-info
 	package.</para>
       </listitem>
     </orderedlist>
   </sect2>
   <sect2 id="intltool">
     <title>Packages using intltool</title>
     <para>If a package uses intltool during its build, add
     <literal>intltool</literal> to the <varname>USE_TOOLS</varname>,
     which forces it to use the intltool package provided by pkgsrc,
     instead of the one bundled with the distribution file.</para>
     <para>This tracks intltool's build-time dependencies and uses the
     latest available version; this way, the package benefits of any
     bug fixes that may have appeared since it was released.</para>
   </sect2>
   <sect2 id="startup-scripts">
     <title>Packages installing startup scripts</title>
     <para>If a package contains a rc.d script, it won't be copied into
     the startup directory by default, but you can enable it, by adding
     the option <varname>PKG_RCD_SCRIPTS=YES</varname> in
     &mk.conf;. This option will copy the scripts
     into <filename>/etc/rc.d</filename> when a package is installed, and
     it will automatically remove the scripts when the package is
     deinstalled.</para>
   </sect2>
   <sect2 id="tex-packages">
     <title>Packages installing TeX modules</title>
     <para>If a package installs TeX packages into the texmf tree,
     the <filename>ls-R</filename> database of the tree needs to be
     updated.</para>
     <note><para>Except the main TeX packages such as kpathsea,
     packages should install files
     into <filename>${PREFIX}/share/texmf-dist</filename>,
     not <filename>${PREFIX}/share/texmf</filename>.</para></note>
     <orderedlist>
       <listitem><para>Include
       <filename>../../print/kpathsea/texmf.mk</filename>.  This
       takes care of rebuilding the <filename>ls-R</filename>
       database at installation and deinstallation time.</para>
       </listitem>
       <listitem><para>If your package installs files into a texmf
       tree other than the one
       at <filename>${PREFIX}/share/texmf-dist</filename>,
       set <varname>TEX_TEXMF_DIRS</varname> to the list of all texmf
       trees that need database update.</para>
       <para>If your package also installs font map files that need
       to be registered using <command>updmap</command>,
       include <filename>../../print/tex-tetex/map.mk</filename> and
       set <varname>TEX_MAP_FILES</varname> and/or
       <varname>TEX_MIXEDMAP_FILES</varname> to the list of all
       such font map files.  Then <command>updmap</command> will

 @@ -1,1124 +1,1128 @@
-# $NetBSD: gcc.mk,v 1.256 2023/07/21 08:29:56 nia Exp $
+# $NetBSD: gcc.mk,v 1.257 2023/07/22 12:20:37 nia Exp $
+#
 # This is the compiler definition for the GNU Compiler Collection.
+#
 # User-settable variables:
+#
 # GCCBASE
 #	If using a native GCC and the compiler is not in $PATH then
 #	this should be set to the base installation directory.
+#
 # USE_NATIVE_GCC
 #	When set to "yes", the native gcc is used, no matter which
 #	compiler version a package requires.
+#
 # USE_PKGSRC_GCC
 #	When set to "yes", use an appropriate version of GCC from
 #	pkgsrc based on GCC_REQD instead of the native compiler.
+#
 # USE_PKGSRC_GCC_RUNTIME
 #	When set to "yes", the runtime gcc libraries (libgcc, libstdc++
 #	etc) will be used from pkgsrc rather than the native compiler.
+#
 # GCC_VERSION_SUFFIX
 #	Optional suffix for GCC binaries, i.e. if the installed names are like
 #	/usr/bin/g++-5, /usr/bin/gcc-5 etc.
 # Package-settable variables:
+#
 # GCC_REQD
 #	The minimum version of the GNU Compiler Collection that is
 #	required to build this package. Setting this variable doesn't
 #	change the compiler that is used for building packages. See
 #	ONLY_FOR_COMPILER for that purpose. This is a list of version
 #	numbers, of which the maximum version is the definitive one.
+#
 #	This variable can also be set by the user when USE_PKGSRC_GCC
 #	is in effect to ensure that a specific compiler is used for
 #	packages which do not specify a higher version.
+#
 # USE_GCC_RUNTIME
 #	Packages which build shared libraries but do not use libtool to
 #	do so should define this variable.  It is used to determine whether
 #	the gcc runtime should be depended upon when a user has enabled
 #	USE_PKGSRC_GCC_RUNTIME.
+#
 # System-defined variables:
+#
 # CC_VERSION
 #	A string of the form "gcc-4.3.2"
+#
 # CC_VERSION_STRING
 #	The same(?) as CC_VERSION. FIXME: What's the difference between
 #	the two?
+#
 # Keywords: gcc
+#
 .if !defined(COMPILER_GCC_MK)
 COMPILER_GCC_MK=	defined
 _VARGROUPS+=	gcc
 _USER_VARS.gcc=	\
 	USE_NATIVE_GCC USE_PKGSRC_GCC USE_PKGSRC_GCC_RUNTIME \
 	GCCBASE GCC_VERSION_SUFFIX \
 	TOOLS_USE_CROSS_COMPILE \
 	PKGSRC_USE_FORTIFY PKGSRC_USE_RELRO PKGSRC_USE_SSP \
 	COMPILER_USE_SYMLINKS CC
 _PKG_VARS.gcc=	\
 	GCC_REQD USE_GCC_RUNTIME USE_LANGUAGES
 _SYS_VARS.gcc=	\
 	CC_VERSION CC_VERSION_STRING LANGUAGES.gcc \
 	CCPATH CPPPATH CXXPATH F77PATH FCPATH \
 	PKG_CC PKG_CPP PKG_CXX PKG_FC FC PKGSRC_FORTRAN \
 	ADAPATH GMKPATH GLKPATH GBDPATH CHPPATH GLSPATH GNTPATH PRPPATH
 _DEF_VARS.gcc=	\
 	MAKEFLAGS IMAKEOPTS \
 	CFLAGS LDFLAGS \
 	PREPEND_PATH \
 	COMPILER_INCLUDE_DIRS COMPILER_LIB_DIRS \
 	CWRAPPERS_APPEND.cc CWRAPPERS_APPEND.cxx CWRAPPERS_APPEND.ld \
 	PKG_ADA PKG_GMK PKG_GLK PKG_GBD PKG_CHP PKG_GNT PKG_GLS PKG_PRP \
 	PKGSRC_ADA PKGSRC_GMK PKGSRC_GLK PKGSRC_GBD PKGSRC_CHP PKGSRC_GNT PKGSRC_GLS PKGSRC_PRP \
 	_CC _COMPILER_RPATH_FLAG _COMPILER_STRIP_VARS \
 	_GCCBINDIR _GCC_ARCHDIR _GCC_BIN_PREFIX _GCC_CFLAGS \
 	_GCC_CC _GCC_CPP _GCC_CXX _GCC_DEPENDENCY _GCC_DEPENDS \
 	_GCC_DIST_NAME _GCC_DIST_VERSION \
 	_GCC_FC _GCC_LDFLAGS _GCC_LIBDIRS _GCC_PKG \
 	_GCC_PKGBASE _GCC_PKGSRCDIR _GCC_PKG_SATISFIES_DEP \
 	_GCC_PREFIX _GCC_REQD _GCC_STRICTEST_REQD _GCC_SUBPREFIX \
 	_GCC_TEST_DEPENDS _GCC_NEEDS_A_FORTRAN _GCC_VARS _GCC_VERSION \
 	_GCC_VERSION_STRING \
 	_GCC_ADA _GCC_GMK _GCC_GLK _GCC_GBD _GCC_CHP _GCC_GLS _GCC_GNT _GCC_PRP \
 	_IGNORE_GCC \
 	_IS_BUILTIN_GCC \
 	_LANGUAGES.gcc \
 	_LINKER_RPATH_FLAG \
 	_NEED_GCC6 _NEED_GCC7 _NEED_GCC8 _NEED_GCC9 \
 	_NEED_GCC10 _NEED_GCC12 _NEED_GCC13 \
 	_NEED_GCC_AUX _NEED_NEWER_GCC \
 	_PKGSRC_GCC_VERSION \
 	_USE_GCC_SHLIB _USE_PKGSRC_GCC \
 	_WRAP_EXTRA_ARGS.CC \
 	_EXTRA_CC_DIRS \
 	_C_STD_VERSIONS \
 	${_C_STD_VERSIONS:@std@_C_STD_FLAG.${std}@} \
 	_CXX_STD_VERSIONS \
 	${_CXX_STD_VERSIONS:@std@_CXX_STD_FLAG.${std}@} \
 	_MKPIE_CFLAGS.gcc _MKPIE_LDFLAGS \
 	_FORTIFY_CFLAGS _RELRO_LDFLAGS _STACK_CHECK_CFLAGS \
 	_CTF_CFLAGS \
 	_GCC_DIR \
 	_ALIASES.CC _ALIASES.CPP _ALIASES.CXX _ALIASES.FC \
 	_ALIASES.ADA _ALIASES.GMK _ALIASES.GLK _ALIASES.GBD \
 	_ALIASES.CHP _ALIASES.PRP _ALIASES.GLS _ALIASES.GNT \
 	_COMPILER_ABI_FLAG.32 _COMPILER_ABI_FLAG.64 \
 	_COMPILER_ABI_FLAG.n32 _COMPILER_ABI_FLAG.o32 \
 	_SSP_CFLAGS \
 	_CXX_STD_FLAG.c++03 _CXX_STD_FLAG.gnu++03
 _USE_VARS.gcc=	\
 	MACHINE_ARCH PATH DRAGONFLY_CCVER OPSYS TOOLBASE \
 	USE_LIBTOOL \
 	LIBABISUFFIX \
 	COMPILER_RPATH_FLAG \
 	MACHINE_GNU_PLATFORM \
 	WRKDIR MACHINE_PLATFORM PKGPATH \
 	_PKGSRC_MKPIE _PKGSRC_MKREPRO _MKREPRO_CFLAGS.gcc \
 	_PKGSRC_USE_FORTIFY _PKGSRC_USE_RELRO _PKGSRC_USE_STACK_CHECK \
 	_OPSYS_INCLUDE_DIRS _OPSYS_LIB_DIRS
 _IGN_VARS.gcc=	\
 	_GCC6_PATTERNS _GCC7_PATTERNS _GCC8_PATTERNS _GCC9_PATTERNS \
 	_GCC10_PATTERNS _GCC12_PATTERNS _GCC13_PATTERNS _GCC_AUX_PATTERNS
 _LISTED_VARS.gcc= \
 	MAKEFLAGS IMAKEOPTS LDFLAGS PREPEND_PATH
 .include "../../mk/bsd.prefs.mk"
 USE_NATIVE_GCC?=	no
 USE_PKGSRC_GCC?=	no
 USE_PKGSRC_GCC_RUNTIME?=no
+#
 # Each successive GCC_REQD has an associated cost below when executing
 # pkg_admin to determine if it's suitable, so only add these incredibly
 # old versions if we haven't already set one.
+#
 .if !defined(GCC_REQD)
 .  if !empty(USE_LANGUAGES:Mc99) || ${MACHINE_ARCH} == "x86_64"
 GCC_REQD+=	3.0
 .  else
 GCC_REQD+=	2.8.0
 .  endif
 .endif
+#
 # Most of the time, GCC adds support for features of new C and C++
 # standards incrementally, so USE_CXX_FEATURES=	c++XX is for
 # establishing an idealistic baseline, usually based on compiler
 # versions shipped with NetBSD.
+#
 # Resources:
 # https://gcc.gnu.org/projects/cxx-status.html
 # https://gcc.gnu.org/wiki/C11Status
 # https://gcc.gnu.org/c99status.html
+#
 .if !empty(USE_CXX_FEATURES:Mc++20)
 # GCC 10 is chosen because it is planned to be shipped with NetBSD 10,
 # so is fairly battle-hardened with pkgsrc.
+#
 # We hope that it remains OK for most C++20 in the future...
 GCC_REQD+=	10
 .endif
 .if !empty(USE_CXX_FEATURES:Mc++17)
 # GCC 7 is chosen because it shipped with NetBSD 9, so is fairly
 # battle-hardened with pkgsrc.
 GCC_REQD+=	7
 .endif
 .if !empty(USE_CXX_FEATURES:Mc++14)
 # GCC 5 is chosen because it shipped with NetBSD 8, so is fairly
 # battle-hardened with pkgsrc.
 GCC_REQD+=	5
 .endif
 .if !empty(USE_CXX_FEATURES:Mc++11)
 # While gcc "technically" added experimental C++11 support earlier
 # (and there was previously a lot of cargo-culted GCC_REQD in pkgsrc
 # as a result), earlier compiler versions are not so well-tested any more.
+#
 # GCC 4.8 was the version shipped with NetBSD 7 and CentOS 7, so is fairly
 # battle-hardened with pkgsrc.
+#
 # Versions before GCC 4.7 do not accept -std=c++11.
 GCC_REQD+=	4.8
 .endif
 .if !empty(USE_CXX_FEATURES:Mhas_include) || \
     !empty(USE_CC_FEATURES:Mhas_include)
 GCC_REQD+=	5
 .endif
 .if !empty(USE_CC_FEATURES:Mc99)
 GCC_REQD+=	3
 .endif
 .if !empty(USE_CC_FEATURES:Mc11)
 GCC_REQD+=	4.9
 .endif
 .if !empty(USE_CXX_FEATURES:Munique_ptr)
 GCC_REQD+=	4.9
 .endif
 .if !empty(USE_CXX_FEATURES:Mregex)
 GCC_REQD+=	4.9
 .endif
 .if !empty(USE_CXX_FEATURES:Mput_time)
 GCC_REQD+=	5
 .endif
 .if !empty(USE_CXX_FEATURES:Mis_trivially_copy_constructible)
 GCC_REQD+=	5
 .endif
 .if !empty(USE_CXX_FEATURES:Mfilesystem)
 GCC_REQD+=	8
 .endif
 .if !empty(USE_CXX_FEATURES:Mparallelism_ts)
 GCC_REQD+=	10
 .endif
 .if !empty(USE_CXX_FEATURES:Mcharconv)
 GCC_REQD+=	8
 .endif
 # Only one compiler defined here supports Ada: lang/gcc6-aux
 # If the Ada language is requested, force lang/gcc6-aux to be selected
 .if !empty(USE_LANGUAGES:Mada)
 GCC_REQD+=	20160822
 .endif
 # _GCC_DIST_VERSION is the highest version of GCC installed by the pkgsrc
 # without the PKGREVISIONs.
 _GCC_DIST_NAME:=	gcc13
 .include "../../lang/${_GCC_DIST_NAME}/version.mk"
 _GCC_DIST_VERSION:=	${${_GCC_DIST_NAME:tu}_DIST_VERSION}
 # _GCC6_PATTERNS matches N s.t. N < 7.
 _GCC6_PATTERNS= 5 6 [0-6].*
 # _GCC7_PATTERNS matches N s.t. 7.0 <= N < 8.
 _GCC7_PATTERNS= 7 7.*
 # _GCC8_PATTERNS matches N s.t. 8.0 <= N < 9.
 _GCC8_PATTERNS= 8 8.*
 # _GCC9_PATTERNS matches N s.t. 9.0 <= N < 10.
 _GCC9_PATTERNS= 9 9.*
 # _GCC10_PATTERNS matches N s.t. 10.0 <= N < 11.
 _GCC10_PATTERNS= 10 10.*
 # _GCC12_PATTERNS matches N s.t. 12.0 <= N < 13.
 # gcc 11.x is not packaged, so depend on gcc12 in that case too
 _GCC12_PATTERNS= 11 11.* 12 12.*
 # _GCC13_PATTERNS matches N s.t. 13.0 <= N < 14.
 _GCC13_PATTERNS= 13 13.*
 # _GCC_AUX_PATTERNS matches 8-digit date YYYYMMDD*
 _GCC_AUX_PATTERNS= 20[1-2][0-9][0-1][0-9][0-3][0-9]*
 # Override the default from sys.mk if necessary.
 .if ${CC} == cc && ${GCCBASE:U} && !exists(${GCCBASE}/bin/${CC}) && exists(${GCCBASE}/bin/gcc)
 CC=	gcc
 .endif
 # _CC is the full path to the compiler named by ${CC} if it can be found.
 .if !defined(_CC)
 _CC:=	${CC:[1]}
 .  if !empty(GCCBASE) && exists(${GCCBASE}/bin)
 _EXTRA_CC_DIRS=	${GCCBASE}/bin
 .  endif
 .  for _dir_ in ${_EXTRA_CC_DIRS} ${PATH:C/\:/ /g}
 .    if empty(_CC:M/*)
 .      if exists(${_dir_}/${CC:[1]})
 _CC:=	${_dir_}/${CC:[1]}
 .      endif
 .    endif
 .  endfor
 .  if ${TOOLS_USE_CROSS_COMPILE:tl} == "no"
 # Pass along _CC only if we're working on native packages -- don't pass
 # the cross-compiler on to submakes for building native packages.
 MAKEFLAGS+=	_CC=${_CC:Q}
 .  endif
 .endif
 .if !defined(_GCC_VERSION)
+#
 # FIXME: Ideally we'd use PKGSRC_SETENV here, but not enough of the tools
 # infrastructure is loaded for SETENV to be defined when mk/compiler.mk is
 # included first.  LC_ALL is required here for similar reasons, as ALL_ENV
 # is not defined at this stage.
+#
 _GCC_VERSION_STRING!=	\
 	( env LC_ALL=C ${_CC} -v 2>&1 | ${GREP} 'gcc version') 2>/dev/null || ${ECHO} 0
 .  if !empty(_GCC_VERSION_STRING:Megcs*)
 _GCC_VERSION=	2.8.1		# egcs is considered to be gcc-2.8.1.
 .  elif !empty(DRAGONFLY_CCVER) && ${OPSYS} == "DragonFly"
 _GCC_VERSION!= env CCVER=${DRAGONFLY_CCVER} ${_CC} -dumpversion
 .  elif !empty(_GCC_VERSION_STRING:Mgcc*)
 _GCC_VERSION!=	${_CC} -dumpversion
 .  else
 _GCC_VERSION=	0
 .  endif
 .endif
 _GCC_PKG=	gcc-${_GCC_VERSION:C/-.*$//}
 .for _version_ in ${_C_STD_VERSIONS}
 _C_STD_FLAG.${_version_}?=	-std=${_version_}
 .endfor
 # XXX: pkgsrc historically hardcoded c99=gnu99 so we retain that for now, but
 # we should look at removing this and be explicit in packages where required.
 _C_STD_FLAG.c99=	-std=gnu99
 .for _version_ in ${_CXX_STD_VERSIONS}
 _CXX_STD_FLAG.${_version_}?=	-std=${_version_}
 .endfor
 .if !empty(_GCC_VERSION:M[34].[1234].*)
 _CXX_STD_FLAG.c++03=	-std=c++0x
 _CXX_STD_FLAG.gnu++03=	-std=gnu++0x
 .endif
 .if !empty(_CC:M${TOOLBASE}/*)
 _IS_BUILTIN_GCC=	NO
 GCC_REQD+=		${_GCC_VERSION}
 .else
 .  if !empty(_CC:M/*)
+#
 # GCC in older versions of Darwin report "Apple Computer ... based on gcc
 # version ...", so we can't just grep for "^gcc".
+#
 .    if ${_GCC_VERSION} != "0"
 _IS_BUILTIN_GCC=	YES
 .    else
 _IS_BUILTIN_GCC=	NO
 .    endif
 .  else
 _IS_BUILTIN_GCC=	NO
 .  endif
 .endif
 # Distill the GCC_REQD list into a single _GCC_REQD value that is the
 # highest version of GCC required.
+#
 _GCC_STRICTEST_REQD?=	none
 .for _version_ in ${GCC_REQD}
 .  for _pkg_ in gcc-${_version_}
 .    if ${_GCC_STRICTEST_REQD} == "none"
 _GCC_PKG_SATISFIES_DEP=		YES
 .      for _vers_ in ${GCC_REQD}
 .        if !empty(_GCC_PKG_SATISFIES_DEP:M[yY][eE][sS])
 _GCC_PKG_SATISFIES_DEP!=	\
 	if ${PKG_ADMIN} pmatch 'gcc>=${_vers_}' ${_pkg_} 2>/dev/null; then \
 		${ECHO} "YES";						\
 	else								\
 		${ECHO} "NO";						\
 	fi
 .        endif
 .      endfor
 .      if !empty(_GCC_PKG_SATISFIES_DEP:M[yY][eE][sS])
 _GCC_STRICTEST_REQD=	${_version_}
 .      endif
 .    endif
 .  endfor
 .endfor
 _GCC_REQD=	${_GCC_STRICTEST_REQD}
 # Determine which GCC version is required by examining _GCC_REQD.
 _NEED_GCC6?=	no
 .for _pattern_ in ${_GCC6_PATTERNS}
 .  if !empty(_GCC_REQD:M${_pattern_})
 # XXX this won't work without adjustments elsewhere because of how
 # _GCC_REQD is processed.
 #.    if ${OPSYS} == "NetBSD" && ${OPSYS_VERSION} < 089937
 #USE_PKGSRC_GCC=		yes
 #USE_PKGSRC_GCC_RUNTIME=	yes
 #.    endif
 _NEED_GCC6=	yes
 .    if ${ALLOW_NEWER_COMPILER:tl} != "yes"
 PKG_FAIL_REASON+=	"Package requires at least gcc 6 to build"
 .    endif
 .  endif
 .endfor
 _NEED_GCC7?=	no
 .for _pattern_ in ${_GCC7_PATTERNS}
 .  if !empty(_GCC_REQD:M${_pattern_})
 .    if ${OPSYS} == "NetBSD" && ${OPSYS_VERSION} < 089937
 USE_PKGSRC_GCC=		yes
 USE_PKGSRC_GCC_RUNTIME=	yes
 .    endif
 .    if ${ALLOW_NEWER_COMPILER:tl} != "yes"
 PKG_FAIL_REASON+=	"Package requires at least gcc 7 to build"
 .    endif
 _NEED_GCC7=	yes
 .  endif
 .endfor
 _NEED_GCC8?=	no
 .for _pattern_ in ${_GCC8_PATTERNS}
 .  if !empty(_GCC_REQD:M${_pattern_})
 .    if ${OPSYS} == "NetBSD" && ${OPSYS_VERSION} < 099917
 USE_PKGSRC_GCC=		yes
 USE_PKGSRC_GCC_RUNTIME=	yes
 .    endif
 .    if ${ALLOW_NEWER_COMPILER:tl} != "yes"
 PKG_FAIL_REASON+=	"Package requires at least gcc 8 to build"
 .    endif
 _NEED_GCC8=	yes
 .  endif
 .endfor
 _NEED_GCC9?=	no
 .for _pattern_ in ${_GCC9_PATTERNS}
 .  if !empty(_GCC_REQD:M${_pattern_})
 .    if ${OPSYS} == "NetBSD" && ${OPSYS_VERSION} < 099976
 USE_PKGSRC_GCC=		yes
 USE_PKGSRC_GCC_RUNTIME=	yes
 .    endif
 .    if ${ALLOW_NEWER_COMPILER:tl} != "yes"
 PKG_FAIL_REASON+=	"Package requires at least gcc 9 to build"
 .    endif
 _NEED_GCC9=	yes
 .  endif
 .endfor
 _NEED_GCC10?=	no
 .for _pattern_ in ${_GCC10_PATTERNS}
 .  if !empty(_GCC_REQD:M${_pattern_})
 .    if ${OPSYS} == "NetBSD" && ${OPSYS_VERSION} < 099982
 USE_PKGSRC_GCC=		yes
 USE_PKGSRC_GCC_RUNTIME=	yes
 .    endif
 .    if ${ALLOW_NEWER_COMPILER:tl} != "yes"
 PKG_FAIL_REASON+=	"Package requires at least gcc 10 to build"
 .    endif
 _NEED_GCC10=	yes
 .  endif
 .endfor
 _NEED_GCC12?=	no
 .for _pattern_ in ${_GCC12_PATTERNS}
 .  if !empty(_GCC_REQD:M${_pattern_})
 .    if ${ALLOW_NEWER_COMPILER:tl} != "yes"
 PKG_FAIL_REASON+=	"Package requires at least gcc 12 to build"
 .    endif
 _NEED_GCC12=	yes
 .  endif
 .endfor
 _NEED_GCC13?=	no
 .for _pattern_ in ${_GCC13_PATTERNS}
 .  if !empty(_GCC_REQD:M${_pattern_})
 .    if ${ALLOW_NEWER_COMPILER:tl} != "yes"
 PKG_FAIL_REASON+=	"Package requires at least gcc 13 to build"
 .    endif
 _NEED_GCC13=	yes
 .  endif
 .endfor
 _NEED_GCC_AUX?=	no
 .for _pattern_ in ${_GCC_AUX_PATTERNS}
 .  if !empty(_GCC_REQD:M${_pattern_})
 _NEED_GCC_AUX=	yes
 _NEED_NEWER_GCC=NO
 .  endif
 .endfor
 .if !empty(_NEED_GCC6:M[nN][oO]) && !empty(_NEED_GCC7:M[nN][oO]) && \
     !empty(_NEED_GCC8:M[nN][oO]) && !empty(_NEED_GCC9:M[nN][oO]) && \
     !empty(_NEED_GCC10:M[nN][oO]) && !empty(_NEED_GCC12:M[nN][oO]) && \
     !empty(_NEED_GCC13:M[nN][oO]) && !empty(_NEED_GCC_AUX:M[nN][oO])
 _NEED_GCC8=	yes
 .endif
 # April 2022: GCC below 10 from pkgsrc is broken on 32-bit arm NetBSD.
 .if !empty(MACHINE_PLATFORM:MNetBSD-*-earm*) && \
     ${OPSYS_VERSION} < 099900 && \
     (${_NEED_GCC8:tl} == "yes" || ${_NEED_GCC9:tl} == "yes")
 _NEED_GCC6=	no
 _NEED_GCC7=	no
 _NEED_GCC8=	no
 _NEED_GCC9=	no
 _NEED_GCC10=	yes
 _NEED_GCC12=	yes
 _NEED_GCC13=	yes
 .endif
 # Assume by default that GCC will only provide a C compiler.
 LANGUAGES.gcc?=	c
 .if !empty(_NEED_GCC6:M[yY][eE][sS])
 LANGUAGES.gcc=	c c++ fortran fortran77 go java objc obj-c++
 .elif !empty(_NEED_GCC7:M[yY][eE][sS])
 LANGUAGES.gcc=	c c++ fortran fortran77 go java objc obj-c++
 .elif !empty(_NEED_GCC8:M[yY][eE][sS])
 LANGUAGES.gcc=	c c++ fortran fortran77 go java objc obj-c++
 .elif !empty(_NEED_GCC9:M[yY][eE][sS])
 LANGUAGES.gcc=	c c++ fortran fortran77 go java objc obj-c++
 .elif !empty(_NEED_GCC10:M[yY][eE][sS])
 LANGUAGES.gcc=	c c++ fortran fortran77 go java objc obj-c++
 .elif !empty(_NEED_GCC12:M[yY][eE][sS])
 LANGUAGES.gcc=	c c++ fortran fortran77 go java objc obj-c++
 .elif !empty(_NEED_GCC13:M[yY][eE][sS])
 LANGUAGES.gcc=	c c++ fortran fortran77 go java objc obj-c++
 .elif !empty(_NEED_GCC_AUX:M[yY][eE][sS])
 LANGUAGES.gcc=	c c++ fortran fortran77 objc ada
 .endif
 _LANGUAGES.gcc=		# empty
 .for _lang_ in ${USE_LANGUAGES}
 _LANGUAGES.gcc+=	${LANGUAGES.gcc:M${_lang_}}
 .endfor
 _WRAP_EXTRA_ARGS.cc+=	-fcommon
 CWRAPPERS_PREPEND.cc+=	-fcommon
 .if ${_PKGSRC_MKPIE} == "yes"
 _MKPIE_CFLAGS.gcc=	-fPIC
 _MKPIE_FCFLAGS.gcc=	-fPIC
 # for libraries a sink wrapper around gcc is required and used instead
 _MKPIE_LDFLAGS=		-pie
 .  if ${PKGSRC_OVERRIDE_MKPIE:tl} == "no"
 _GCC_CFLAGS+=		${_MKPIE_CFLAGS.gcc}
 _GCC_FCFLAGS+=		${_MKPIE_FCFLAGS.gcc}
 CWRAPPERS_APPEND.cc+=	${_MKPIE_CFLAGS.gcc}
 CWRAPPERS_APPEND.cxx+=	${_MKPIE_CFLAGS.gcc}
 CWRAPPERS_APPEND.f77+=	${_MKPIE_FCFLAGS.gcc}
 .  endif
 .endif
 .if ${_PKGSRC_MKREPRO} == "yes"
 .export WRKDIR
 # XXX the dollar sign should not be expanded by the shell
 _GCC_CFLAGS+=		-fdebug-prefix-map=$$$$WRKDIR/=
 .endif
 .if ${_PKGSRC_MKREPRO} == "yes"
 _GCC_CFLAGS+=		${_MKREPRO_CFLAGS.gcc}
 CWRAPPERS_APPEND.cc+=	${_MKREPRO_CFLAGS.gcc}
 .endif
 # The user can choose the level of FORTIFY.
 .if ${PKGSRC_USE_FORTIFY} == "weak"
 _FORTIFY_CFLAGS=	-D_FORTIFY_SOURCE=1
 .else
 _FORTIFY_CFLAGS=	-D_FORTIFY_SOURCE=2
 .endif
 .if ${_PKGSRC_USE_FORTIFY} == "yes"
 _GCC_CFLAGS+=		${_FORTIFY_CFLAGS}
 CWRAPPERS_APPEND.cc+=	${_FORTIFY_CFLAGS}
 .endif
 # The user or package can choose the level of RELRO.
 .if ${PKGSRC_USE_RELRO} != "partial" && \
     ${RELRO_SUPPORTED:Uyes:tl} != "partial"
 _RELRO_LDFLAGS=		-Wl,-zrelro -Wl,-znow
 .else
 _RELRO_LDFLAGS=		-Wl,-zrelro
 .endif
 .if !empty(_RELRO_LDFLAGS) && !empty(MACHINE_PLATFORM:MNetBSD-*-*mips*)
 _RELRO_LDFLAGS+=	-Wl,-z,common-page-size=0x10000
 .endif
 .if ${_PKGSRC_USE_STACK_CHECK} == "yes"
 _STACK_CHECK_CFLAGS=	-fstack-check
 _GCC_CFLAGS+=		${_STACK_CHECK_CFLAGS}
 .elif ${_PKGSRC_USE_STACK_CHECK} == "stack-clash"
 _STACK_CHECK_CFLAGS=	-fstack-clash-protection
 _GCC_CFLAGS+=		${_STACK_CHECK_CFLAGS}
 .endif
 _CTF_CFLAGS=		-gdwarf-2
 # GCC has this annoying behaviour where it advocates in a multi-line
 # banner the use of "#include" over "#import" when including headers.
 # This generates a huge number of warnings when building practically all
 # Objective-C code where it is convention to use "#import".  Suppress
 # the warning if we're building Objective-C code using GCC.
+#
 .if !empty(_LANGUAGES.gcc:Mobjc)
 CFLAGS+=	-Wno-import
 .endif
 CFLAGS+=	${_GCC_CFLAGS}
 FCFLAGS+=	${_GCC_FCFLAGS}
 .if !empty(_NEED_GCC6:M[yY][eE][sS])
+#
 # We require gcc-6.x in the lang/gcc6-* directory.
+#
 _GCC_PKGBASE=		gcc6
 .  if ${PKGPATH} == lang/gcc6
 _IGNORE_GCC=		yes
 MAKEFLAGS+=		_IGNORE_GCC=yes
 .  endif
 .  if !defined(_IGNORE_GCC) && !empty(_LANGUAGES.gcc)
 _GCC_PKGSRCDIR=		../../lang/gcc6
 _GCC_DEPENDENCY=	gcc6>=${_GCC_REQD}:../../lang/gcc6
 .    if !empty(_LANGUAGES.gcc:Mc++) || \
         !empty(_LANGUAGES.gcc:Mfortran) || \
         !empty(_LANGUAGES.gcc:Mfortran77) || \
         !empty(_LANGUAGES.gcc:Mgo) || \
         !empty(_LANGUAGES.gcc:Mobjc) || \
         !empty(_LANGUAGES.gcc:Mobj-c++)
 _USE_GCC_SHLIB?=	yes
 .    endif
 .  endif
 .elif !empty(_NEED_GCC7:M[yY][eE][sS])
+#
 # We require gcc-7.x in the lang/gcc7-* directory.
+#
 _GCC_PKGBASE=		gcc7
 .  if ${PKGPATH} == lang/gcc7
 _IGNORE_GCC=		yes
 MAKEFLAGS+=		_IGNORE_GCC=yes
 .  endif
 .  if !defined(_IGNORE_GCC) && !empty(_LANGUAGES.gcc)
 _GCC_PKGSRCDIR=		../../lang/gcc7
 _GCC_DEPENDENCY=	gcc7>=${_GCC_REQD}:../../lang/gcc7
 .    if !empty(_LANGUAGES.gcc:Mc++) || \
         !empty(_LANGUAGES.gcc:Mfortran) || \
         !empty(_LANGUAGES.gcc:Mfortran77) || \
         !empty(_LANGUAGES.gcc:Mgo) || \
         !empty(_LANGUAGES.gcc:Mobjc) || \
         !empty(_LANGUAGES.gcc:Mobj-c++)
 _USE_GCC_SHLIB?=	yes
 .    endif
 .  endif
 .elif !empty(_NEED_GCC8:M[yY][eE][sS])
+#
 # We require gcc-8.x in the lang/gcc8-* directory.
+#
 _GCC_PKGBASE=		gcc8
 .  if ${PKGPATH} == lang/gcc8
 _IGNORE_GCC=		yes
 MAKEFLAGS+=		_IGNORE_GCC=yes
 .  endif
 .  if !defined(_IGNORE_GCC) && !empty(_LANGUAGES.gcc)
 _GCC_PKGSRCDIR=		../../lang/gcc8
 _GCC_DEPENDENCY=	gcc8>=${_GCC_REQD}:../../lang/gcc8
 .    if !empty(_LANGUAGES.gcc:Mc++) || \
         !empty(_LANGUAGES.gcc:Mfortran) || \
         !empty(_LANGUAGES.gcc:Mfortran77) || \
         !empty(_LANGUAGES.gcc:Mgo) || \
         !empty(_LANGUAGES.gcc:Mobjc) || \
         !empty(_LANGUAGES.gcc:Mobj-c++)
 _USE_GCC_SHLIB?=	yes
 .    endif
 .  endif
 .elif !empty(_NEED_GCC9:M[yY][eE][sS])
+#
 # We require gcc-9.x in the lang/gcc9-* directory.
+#
 _GCC_PKGBASE=		gcc9
 .  if ${PKGPATH} == lang/gcc9
 _IGNORE_GCC=		yes
 MAKEFLAGS+=		_IGNORE_GCC=yes
 .  endif
 .  if !defined(_IGNORE_GCC) && !empty(_LANGUAGES.gcc)
 _GCC_PKGSRCDIR=		../../lang/gcc9
 _GCC_DEPENDENCY=	gcc9>=${_GCC_REQD}:../../lang/gcc9
 .    if !empty(_LANGUAGES.gcc:Mc++) || \
         !empty(_LANGUAGES.gcc:Mfortran) || \
         !empty(_LANGUAGES.gcc:Mfortran77) || \
         !empty(_LANGUAGES.gcc:Mgo) || \
         !empty(_LANGUAGES.gcc:Mobjc) || \
         !empty(_LANGUAGES.gcc:Mobj-c++)
 _USE_GCC_SHLIB?=	yes
 .    endif
 .  endif
 .elif !empty(_NEED_GCC10:M[yY][eE][sS])
+#
 # We require gcc-10.x in the lang/gcc10-* directory.
+#
 _GCC_PKGBASE=		gcc10
 .  if ${PKGPATH} == lang/gcc10
 _IGNORE_GCC=		yes
 MAKEFLAGS+=		_IGNORE_GCC=yes
 .  endif
 .  if !defined(_IGNORE_GCC) && !empty(_LANGUAGES.gcc)
 _GCC_PKGSRCDIR=		../../lang/gcc10
 _GCC_DEPENDENCY=	gcc10>=${_GCC_REQD}:../../lang/gcc10
 .    if !empty(_LANGUAGES.gcc:Mc++) || \
         !empty(_LANGUAGES.gcc:Mfortran) || \
         !empty(_LANGUAGES.gcc:Mfortran77) || \
         !empty(_LANGUAGES.gcc:Mgo) || \
         !empty(_LANGUAGES.gcc:Mobjc) || \
         !empty(_LANGUAGES.gcc:Mobj-c++)
 _USE_GCC_SHLIB?=	yes
 .    endif
 .  endif
 .elif !empty(_NEED_GCC12:M[yY][eE][sS])
+#
 # We require gcc-12.x in the lang/gcc12-* directory.
+#
 _GCC_PKGBASE=		gcc12
 .  if ${PKGPATH} == lang/gcc12
 _IGNORE_GCC=		yes
 MAKEFLAGS+=		_IGNORE_GCC=yes
 .  endif
 .  if !defined(_IGNORE_GCC) && !empty(_LANGUAGES.gcc)
 _GCC_PKGSRCDIR=		../../lang/gcc12
 _GCC_DEPENDENCY=	gcc12>=${_GCC_REQD}:../../lang/gcc12
 .    if !empty(_LANGUAGES.gcc:Mc++) || \
         !empty(_LANGUAGES.gcc:Mfortran) || \
         !empty(_LANGUAGES.gcc:Mfortran77) || \
         !empty(_LANGUAGES.gcc:Mgo) || \
         !empty(_LANGUAGES.gcc:Mobjc) || \
         !empty(_LANGUAGES.gcc:Mobj-c++)
 _USE_GCC_SHLIB?=	yes
 .    endif
 .  endif
 .elif !empty(_NEED_GCC13:M[yY][eE][sS])
+#
 # We require gcc-13.x in the lang/gcc13-* directory.
+#
 _GCC_PKGBASE=		gcc13
 .  if ${PKGPATH} == lang/gcc13
 _IGNORE_GCC=		yes
 MAKEFLAGS+=		_IGNORE_GCC=yes
 .  endif
 .  if !defined(_IGNORE_GCC) && !empty(_LANGUAGES.gcc)
 _GCC_PKGSRCDIR=		../../lang/gcc13
 _GCC_DEPENDENCY=	gcc13>=${_GCC_REQD}:../../lang/gcc13
 .    if !empty(_LANGUAGES.gcc:Mc++) || \
         !empty(_LANGUAGES.gcc:Mfortran) || \
         !empty(_LANGUAGES.gcc:Mfortran77) || \
         !empty(_LANGUAGES.gcc:Mgo) || \
         !empty(_LANGUAGES.gcc:Mobjc) || \
         !empty(_LANGUAGES.gcc:Mobj-c++)
 _USE_GCC_SHLIB?=	yes
 .    endif
 .  endif
 .elif !empty(_NEED_GCC_AUX:M[yY][eE][sS])
+#
 # We require Ada-capable compiler in the lang/gcc6-aux directory.
+#
 _GCC_PKGBASE=		gcc6-aux
 .  if ${PKGPATH} == lang/gcc6-aux
 _IGNORE_GCC=		yes
 MAKEFLAGS+=		_IGNORE_GCC=yes
 .  endif
 .  if !defined(_IGNORE_GCC) && !empty(_LANGUAGES.gcc)
 _GCC_PKGSRCDIR=		../../lang/gcc6-aux
 _GCC_DEPENDENCY=	gcc6-aux>=${_GCC_REQD}:../../lang/gcc6-aux
 .    if !empty(_LANGUAGES.gcc:Mc++) || \
         !empty(_LANGUAGES.gcc:Mfortran) || \
         !empty(_LANGUAGES.gcc:Mfortran77) || \
         !empty(_LANGUAGES.gcc:Mada) || \
         !empty(_LANGUAGES.gcc:Mobjc)
 _USE_GCC_SHLIB?=	yes
 .    endif
 .  endif
 .endif
 _GCC_DEPENDS=		${_GCC_PKGBASE}>=${_GCC_REQD}
 # When not using the GNU linker, gcc will always link shared libraries against
 # the shared version of libgcc, and so _USE_GCC_SHLIB needs to be enabled on
 # platforms with non-GNU linkers, such as SunOS.
+#
 # However, we cannot simply do this by default as it will create circular
 # dependencies in packages which are required to build gcc itself, and so we
 # enable it based on USE_LIBTOOL for the majority of packages, and support
 # USE_GCC_RUNTIME for packages which create shared libraries but do not use
 # libtool to do so.
+#
 .if (${OPSYS} == "Darwin" || ${OPSYS} == "SunOS") && \
     (defined(USE_LIBTOOL) || defined(USE_GCC_RUNTIME))
 _USE_GCC_SHLIB= yes
 .endif
 .if !empty(USE_NATIVE_GCC:M[yY][eE][sS]) && !empty(_IS_BUILTIN_GCC:M[yY][eE][sS])
 _USE_PKGSRC_GCC=	no
 .elif !empty(USE_PKGSRC_GCC:M[yY][eE][sS])
 # For environments where there is an external gcc too, but pkgsrc
 # should use the pkgsrc one for consistency.
 _USE_PKGSRC_GCC=	yes
 .endif
 .if defined(_IGNORE_GCC)
 _USE_PKGSRC_GCC=	NO
 .endif
 .if !defined(_USE_PKGSRC_GCC)
 _USE_PKGSRC_GCC=	YES
 .  if !empty(_IS_BUILTIN_GCC:M[yY][eE][sS])
 _GCC_TEST_DEPENDS=	gcc>=${_GCC_REQD}
 _USE_PKGSRC_GCC!=	\
 	if ${PKG_ADMIN} pmatch '${_GCC_TEST_DEPENDS}' ${_GCC_PKG} 2>/dev/null; then \
 		${ECHO} "NO";						\
 	else								\
 		${ECHO} "YES";						\
 	fi
 .  endif
 .endif
 # Check if any of the versions of GCC in pkgsrc can satisfy the _GCC_REQD
 # requirement.
+#
 .if !defined(_NEED_NEWER_GCC)
 _PKGSRC_GCC_VERSION=	${_GCC_PKGBASE}-${_GCC_DIST_VERSION}
 _NEED_NEWER_GCC!=	\
 	if ${PKG_ADMIN} pmatch '${_GCC_DEPENDS}' ${_PKGSRC_GCC_VERSION} 2>/dev/null; then \
 		${ECHO} "NO";						\
 	else								\
 		${ECHO} "YES";						\
 	fi
 #MAKEFLAGS+=	_NEED_NEWER_GCC=${_NEED_NEWER_GCC}
 .endif
 .if !empty(_USE_PKGSRC_GCC:M[yY][eE][sS]) && \
     !empty(_NEED_NEWER_GCC:M[yY][eE][sS])
 PKG_FAIL_REASON+=	"Unable to satisfy dependency: ${_GCC_DEPENDS}"
 .endif
 # GNU ld option used to set the rpath
 _LINKER_RPATH_FLAG=	-R
 # GCC passes rpath directives to the linker using "-Wl,-R".
 _COMPILER_RPATH_FLAG=	-Wl,${_LINKER_RPATH_FLAG}
 .if !empty(_USE_PKGSRC_GCC:M[yY][eE][sS])
+#
 # Ensure that the correct rpath is passed to the linker if we need to
 # link against gcc shared libs.
+#
 # XXX cross-compilation -- is this TOOLBASE or LOCALBASE?
+#
 _GCC_SUBPREFIX!=	\
 	if ${PKG_INFO} -qe ${_GCC_PKGBASE}; then			\
 		${PKG_INFO} -f ${_GCC_PKGBASE} |			\
 		${GREP} "File:.*bin/gcc" |				\
 		${GREP} -v "/gcc[0-9][0-9]*-.*" |			\
 		${SED} -e "s/.*File: *//;s/bin\/gcc.*//;q";		\
 	else								\
 		case ${_CC} in						\
 		${LOCALBASE}/*)						\
 			subprefix="${_CC:H:S/\/bin$//:S/${LOCALBASE}\///:S/${LOCALBASE}//}"; \
 			case "$${subprefix}" in				\
 			"")	${ECHO} "$${subprefix}" ;;		\
 			*)	${ECHO} "$${subprefix}/" ;;		\
 			esac;						\
 			;;						\
 		*)							\
 			${ECHO} "_GCC_SUBPREFIX_not_found/";		\
 			;;						\
 		esac;							\
 	fi
 _GCC_PREFIX=		${LOCALBASE}/${_GCC_SUBPREFIX}
 _GCC_ARCHDIR!=		\
 	if [ -x ${_GCC_PREFIX}bin/gcc ]; then				\
 		${DIRNAME} `${_GCC_PREFIX}bin/gcc -print-libgcc-file-name 2>/dev/null`; \
 	else								\
 		${ECHO} "_GCC_ARCHDIR_not_found";			\
 	fi
 _GCC_LIBDIRS=	${_GCC_ARCHDIR}
 .  if empty(USE_PKGSRC_GCC_RUNTIME:M[Yy][Ee][Ss])
 _GCC_LIBDIRS+=	${_GCC_PREFIX}lib${LIBABISUFFIX}
 .  endif
 _GCC_LDFLAGS=	# empty
 .  for _dir_ in ${_GCC_LIBDIRS:N*not_found*}
 _GCC_LDFLAGS+=	-L${_dir_} ${COMPILER_RPATH_FLAG}${_dir_}
 .  endfor
 .endif
 .if ${_PKGSRC_USE_RELRO} == "yes"
 _GCC_LDFLAGS+=		${_RELRO_LDFLAGS}
 CWRAPPERS_PREPEND.cc+=	${_RELRO_LDFLAGS}
 CWRAPPERS_PREPEND.cxx+=	${_RELRO_LDFLAGS}
 .endif
 LDFLAGS+=	${_GCC_LDFLAGS}
 # Point the variables that specify the compiler to the installed
 # GCC executables.
+#
 _GCC_DIR=	${WRKDIR}/.gcc
 _GCC_VARS=	# empty
 .if !empty(_USE_PKGSRC_GCC:M[yY][eE][sS])
 _GCCBINDIR=	${_GCC_PREFIX}bin
 .elif !empty(_IS_BUILTIN_GCC:M[yY][eE][sS])
 _GCCBINDIR=	${_CC:H}
 .endif
 .if !empty(TOOLS_USE_CROSS_COMPILE:M[yY][eE][sS])
 _GCC_BIN_PREFIX=	${MACHINE_GNU_PLATFORM}-
 .endif
 _GCC_BIN_PREFIX?=	# empty
 GCC_VERSION_SUFFIX?=	# empty
 .if exists(${_GCCBINDIR}/${_GCC_BIN_PREFIX}gcc${GCC_VERSION_SUFFIX})
 _GCC_VARS+=	CC
 _GCC_CC=	${_GCC_DIR}/bin/${_GCC_BIN_PREFIX}gcc${GCC_VERSION_SUFFIX}
 _ALIASES.CC=	cc gcc
 CCPATH=		${_GCCBINDIR}/${_GCC_BIN_PREFIX}gcc${GCC_VERSION_SUFFIX}
 PKG_CC:=	${_GCC_CC}
 .endif
 .if exists(${_GCCBINDIR}/${_GCC_BIN_PREFIX}cpp${GCC_VERSION_SUFFIX})
 _GCC_VARS+=	CPP
 _GCC_CPP=	${_GCC_DIR}/bin/${_GCC_BIN_PREFIX}cpp${GCC_VERSION_SUFFIX}
 _ALIASES.CPP=	cpp
 CPPPATH=	${_GCCBINDIR}/${_GCC_BIN_PREFIX}cpp${GCC_VERSION_SUFFIX}
 PKG_CPP:=	${_GCC_CPP}
 .endif
 .if exists(${_GCCBINDIR}/${_GCC_BIN_PREFIX}g++${GCC_VERSION_SUFFIX})
 _GCC_VARS+=	CXX
 _GCC_CXX=	${_GCC_DIR}/bin/${_GCC_BIN_PREFIX}g++${GCC_VERSION_SUFFIX}
 _ALIASES.CXX=	c++ g++
 CXXPATH=	${_GCCBINDIR}/${_GCC_BIN_PREFIX}g++${GCC_VERSION_SUFFIX}
 PKG_CXX:=	${_GCC_CXX}
 .endif
 .if exists(${_GCCBINDIR}/${_GCC_BIN_PREFIX}g77${GCC_VERSION_SUFFIX})
 _GCC_VARS+=	FC
 _GCC_FC=	${_GCC_DIR}/bin/${_GCC_BIN_PREFIX}g77${GCC_VERSION_SUFFIX}
 _ALIASES.FC=	f77 g77
 FC=		g77
 FCPATH=		${_GCCBINDIR}/${_GCC_BIN_PREFIX}g77${GCC_VERSION_SUFFIX}
 F77PATH=	${_GCCBINDIR}/${_GCC_BIN_PREFIX}g77${GCC_VERSION_SUFFIX}
 PKG_FC:=	${_GCC_FC}
 PKGSRC_FORTRAN?=	g77
 .endif
 .if exists(${_GCCBINDIR}/${_GCC_BIN_PREFIX}gfortran${GCC_VERSION_SUFFIX})
 _GCC_VARS+=	FC
 _GCC_FC=	${_GCC_DIR}/bin/${_GCC_BIN_PREFIX}gfortran${GCC_VERSION_SUFFIX}
 _ALIASES.FC=	gfortran
 FC=		gfortran
 FCPATH=		${_GCCBINDIR}/${_GCC_BIN_PREFIX}gfortran${GCC_VERSION_SUFFIX}
 F77PATH=	${_GCCBINDIR}/${_GCC_BIN_PREFIX}gfortran${GCC_VERSION_SUFFIX}
 PKG_FC:=	${_GCC_FC}
 PKGSRC_FORTRAN?=	gfortran
 .endif
 .if exists(${_GCCBINDIR}/${_GCC_BIN_PREFIX}ada)
 _GCC_VARS+=	ADA GMK GLK GBD CHP PRP GLS GNT
 _GCC_ADA=	${_GCC_DIR}/bin/${_GCC_BIN_PREFIX}ada
 _GCC_GMK=	${_GCC_DIR}/bin/${_GCC_BIN_PREFIX}gnatmake
 _GCC_GLK=	${_GCC_DIR}/bin/${_GCC_BIN_PREFIX}gnatlink
 _GCC_GBD=	${_GCC_DIR}/bin/${_GCC_BIN_PREFIX}gnatbind
 _GCC_CHP=	${_GCC_DIR}/bin/${_GCC_BIN_PREFIX}gnatchop
 _GCC_PRP=	${_GCC_DIR}/bin/${_GCC_BIN_PREFIX}gnatprep
 _GCC_GLS=	${_GCC_DIR}/bin/${_GCC_BIN_PREFIX}gnatls
 _GCC_GNT=	${_GCC_DIR}/bin/${_GCC_BIN_PREFIX}gnat
 _ALIASES.ADA=	ada
 _ALIASES.GMK=	gnatmake
 _ALIASES.GLK=	gnatlink
 _ALIASES.GBD=	gnatbind
 _ALIASES.CHP=	gnatchop
 _ALIASES.PRP=	gnatprep
 _ALIASES.GLS=	gnatls
 _ALIASES.GNT=	gnat
 ADAPATH=	${_GCCBINDIR}/${_GCC_BIN_PREFIX}ada
 GMKPATH=	${_GCCBINDIR}/${_GCC_BIN_PREFIX}gnatmake
 GLKPATH=	${_GCCBINDIR}/${_GCC_BIN_PREFIX}gnatlink
 GBDPATH=	${_GCCBINDIR}/${_GCC_BIN_PREFIX}gnatbind
 CHPPATH=	${_GCCBINDIR}/${_GCC_BIN_PREFIX}gnatchop
 PRPPATH=	${_GCCBINDIR}/${_GCC_BIN_PREFIX}gnatprep
 GLSPATH=	${_GCCBINDIR}/${_GCC_BIN_PREFIX}gnatls
 GNTPATH=	${_GCCBINDIR}/${_GCC_BIN_PREFIX}gnat
 PKG_ADA:=	${_GCC_ADA}
 PKG_GMK:=	${_GCC_GMK}
 PKG_GLK:=	${_GCC_GLK}
 PKG_GBD:=	${_GCC_GBD}
 PKG_CHP:=	${_GCC_CHP}
 PKG_PRP:=	${_GCC_PRP}
 PKG_GLS:=	${_GCC_GLS}
 PKG_GNT:=	${_GCC_GNT}
 PKGSRC_ADA?=	ada
 PKGSRC_GMK?=	gnatmake
 PKGSRC_GLK?=	gnatlink
 PKGSRC_GBD?=	gnatbind
 PKGSRC_CHP?=	gnatchop
 PKGSRC_PRP?=	gnatprep
 PKGSRC_GLS?=	gnatls
 PKGSRC_GNT?=	gnat
 .endif
 _COMPILER_STRIP_VARS+=	${_GCC_VARS}
 # Pass the required flags to imake to tell it we're using gcc on Solaris.
 .if ${OPSYS} == "SunOS"
 IMAKEOPTS+=	-DHasGcc2=YES -DHasGcc2ForCplusplus=YES
 .endif
 .if ${OPSYS} == "AIX"
 # On AIX the GCC toolchain recognizes -maix32 and -maix64,
 # -m32 or -m64 are not recognized.
 _COMPILER_ABI_FLAG.32=	-maix32
 _COMPILER_ABI_FLAG.64=	-maix64
 # On HP-UX the GCC toolchain must be specifically targeted to an ABI,
 # -m32 or -m64 are not recognized.
 .elif ${OPSYS} == "HPUX"
 _COMPILER_ABI_FLAG.32=	# empty
 _COMPILER_ABI_FLAG.64=	# empty
 .elif !empty(MACHINE_ARCH:Mmips*)
 _COMPILER_ABI_FLAG.32=	-mabi=n32	# ABI == "32" == "n32"
 _COMPILER_ABI_FLAG.n32=	-mabi=n32
 _COMPILER_ABI_FLAG.o32=	-mabi=32
 _COMPILER_ABI_FLAG.64=	-mabi=64
 .elif !empty(MACHINE_ARCH:Maarch64*)
 _COMPILER_ABI_FLAG.32=	-m32
 _COMPILER_ABI_FLAG.64=	# empty
 .else
 _COMPILER_ABI_FLAG.32=	-m32
 _COMPILER_ABI_FLAG.64=	-m64
 .endif
 .if !empty(_USE_PKGSRC_GCC:M[yY][eE][sS])
 .  if exists(${CCPATH})
 CC_VERSION_STRING!=	${CCPATH} -v 2>&1
 CC_VERSION!=		\
 	if ${CCPATH} -dumpversion > /dev/null 2>&1; then		\
 		${ECHO} "gcc-`${CCPATH} -dumpversion`";			\
 	else								\
 		${ECHO} "gcc-${_GCC_REQD}";				\
 	fi
 .  else
 CC_VERSION_STRING=	${CC_VERSION}
 CC_VERSION=		gcc-${_GCC_REQD}
 .  endif
 .else
 CC_VERSION_STRING=	${CC_VERSION}
 CC_VERSION=		${_GCC_PKG}
 .endif
 # The user can choose the level of stack smashing protection.
 .if empty(CC_VERSION:Mgcc-[1-3].*)
 .  if ${PKGSRC_USE_SSP} == "all"
 _SSP_CFLAGS=		-fstack-protector-all
 .  elif ${PKGSRC_USE_SSP} == "strong"
 _SSP_CFLAGS=		-fstack-protector-strong
 .  else
 _SSP_CFLAGS=		-fstack-protector
 .  endif
 .endif
 # Prepend the path to the compiler to the PATH.
 .if !empty(_LANGUAGES.gcc)
 PREPEND_PATH+=	${_GCC_DIR}/bin
 .endif
 # Add the dependency on GCC.
 .if !empty(_USE_PKGSRC_GCC:M[yY][eE][sS])
 .  for _dir_ in ${_GCC_PKGSRCDIR}
 .    include "${_dir_}/buildlink3.mk"
 .  endfor
 .endif
 # Add dependency on GCC libraries if requested.
 .if (defined(_USE_GCC_SHLIB) && !empty(_USE_GCC_SHLIB:M[Yy][Ee][Ss])) && !empty(USE_PKGSRC_GCC_RUNTIME:M[Yy][Ee][Ss])
 #  Special case packages which are themselves a dependency of gcc runtime.
 .  if ${PKGPATH} != devel/libtool-base && ${PKGPATH} != devel/binutils && \
       empty(PKGPATH:Mlang/gcc4?) && empty(PKGPATH:Mlang/gcc[5-9]) && \
       empty(PKGPATH:Mlang/gcc10) && empty(PKGPATH:Mlang/gcc12) && \
       empty(PKGPATH:Mlang/gcc13)
 .    if !empty(_GCC_PKGBASE:Mgcc6)
 .      include "../../lang/gcc6-libs/buildlink3.mk"
 .    elif !empty(_GCC_PKGBASE:Mgcc7)
 .      include "../../lang/gcc7-libs/buildlink3.mk"
 .    elif !empty(_GCC_PKGBASE:Mgcc8)
 .      include "../../lang/gcc8-libs/buildlink3.mk"
 .    elif !empty(_GCC_PKGBASE:Mgcc9)
 .      include "../../lang/gcc9-libs/buildlink3.mk"
 .    elif !empty(_GCC_PKGBASE:Mgcc10)
 .      include "../../lang/gcc10-libs/buildlink3.mk"
 .    elif !empty(_GCC_PKGBASE:Mgcc12)
 .      include "../../lang/gcc12-libs/buildlink3.mk"
 .    elif !empty(_GCC_PKGBASE:Mgcc13)
 .      include "../../lang/gcc13-libs/buildlink3.mk"
 .    else
 PKG_FAIL_REASON+=	"No USE_PKGSRC_GCC_RUNTIME support for ${CC_VERSION}"
 .    endif
 .  endif
 .endif
 .for _var_ in ${_GCC_VARS}
 .  if !target(${_GCC_${_var_}})
 override-tools: ${_GCC_${_var_}}
 ${_GCC_${_var_}}:
 	${RUN}${MKDIR} ${.TARGET:H}
 .    if !empty(COMPILER_USE_SYMLINKS:M[Yy][Ee][Ss])
 	${RUN}${RM} -f ${.TARGET}
 	${RUN}${LN} -s ${_GCCBINDIR}/${.TARGET:T} ${.TARGET}
 .    else
 	${RUN}					\
 	(${ECHO} '#!${TOOLS_SHELL}';					\
 	 ${ECHO} 'exec ${_GCCBINDIR}/${.TARGET:T} "$$@"';		\
 	) > ${.TARGET}
 	${RUN}${CHMOD} +x ${.TARGET}
 .    endif
 .    for _alias_ in ${_ALIASES.${_var_}:S/^/${.TARGET:H}\//}
 	${RUN}					\
 	if [ ! -x "${_alias_}" ]; then					\
 		${LN} -f -s ${.TARGET:T} ${_alias_};			\
 	fi
 .    endfor
 .  endif
 .endfor
 # On systems without a Fortran compiler, pull one in if needed.
 PKGSRC_FORTRAN?=gfortran
 _GCC_NEEDS_A_FORTRAN=	no
 .if empty(_USE_PKGSRC_GCC:M[yY][eE][sS]) && !(defined(FCPATH) && exists(${FCPATH}))
 _GCC_NEEDS_A_FORTRAN=	yes
 .else
 .  for _pattern_ in 0.* 1.[0-4] 1.[0-4].*
 .    if !empty(MACHINE_PLATFORM:MNetBSD-${_pattern_}-*)
 _GCC_NEEDS_A_FORTRAN=	yes
 .    endif
 .  endfor
 .endif
 .if !empty(_GCC_NEEDS_A_FORTRAN:M[yY][eE][sS])
 .  include "../../mk/compiler/${PKGSRC_FORTRAN}.mk"
 .endif
 .if ${OPSYS} == "Interix" && !empty(_GCCBINDIR:M/opt/gcc.*)
 COMPILER_INCLUDE_DIRS=	${_GCCBINDIR:H}/include ${_OPSYS_INCLUDE_DIRS}
 COMPILER_LIB_DIRS=	${_GCCBINDIR:H}/lib ${_OPSYS_LIB_DIRS}
 .endif
 #.READONLY: GCC_REQD
 _GCC_REQD_EFFECTIVE:=	${GCC_REQD}
 .endif	# COMPILER_GCC_MK

 @@ -1,329 +1,329 @@
-# $NetBSD: compiler.mk,v 1.101 2023/07/21 08:29:56 nia Exp $
+# $NetBSD: compiler.mk,v 1.102 2023/07/22 12:20:37 nia Exp $
+#
 # This Makefile fragment implements handling for supported C/C++/Fortran
 # compilers.
+#
 # The following variables may be set by the pkgsrc user in mk.conf:
+#
 # PKGSRC_COMPILER
 #	A list of values specifying the chain of compilers to be used by
 #	pkgsrc to build packages.
+#
 #	Valid values are:
 #		ccc		Compaq C Compilers (Tru64)
 #		ccache		compiler cache (chainable)
 #		clang		Clang C and Objective-C compiler
 #		distcc		distributed C/C++ (chainable)
 #		f2c		Fortran 77 to C compiler (chainable)
 #		icc		Intel C++ Compiler (Linux)
 #		ido		SGI IRIS Development Option cc (IRIX 5)
 #		gcc		GNU
 #		hp		HP-UX C/aC++ compilers
 #		mipspro		Silicon Graphics, Inc. MIPSpro (n32/n64)
 #		mipspro-ucode	Silicon Graphics, Inc. MIPSpro (o32)
 #		pcc		Portable C Compiler
 #		sunpro		Sun Microsystems, Inc. WorkShip/Forte/Sun
 #				ONE Studio
 #		xlc		IBM's XL C/C++ compiler suite (Darwin/MacOSX)
+#
 #	The default is "gcc".  You can use ccache and/or distcc with
 #	an appropriate PKGSRC_COMPILER setting, e.g. "ccache distcc
 #	gcc".  You can also use "f2c" to overlay the lang/f2c package
 #	over the C compiler instead of using the system Fortran
 #	compiler.  The chain should always end in a real compiler.
 #	This should only be set in /etc/mk.conf.
+#
 # COMPILER_USE_SYMLINKS
 #	If set to yes, use symlinks for the compiler drivers, otherwise
 #	shell scripts are created.  The default is yes.
+#
 # CHECK_COMPILER
 #	If set to yes, fail early if the compiler.mk variables are not
 #	set correctly.
+#
 # ALLOW_NEWER_COMPILER
 #	If set to no, fail early if a package requires newer compiler
 #	features than supported by the system's compiler. If set to
 #	yes (the default), pkgsrc may attempt to build a newer compiler
 #	to use instead.
+#
 # The following variables may be set by a package:
+#
 # USE_LANGUAGES
 #	Declares the languages that should be made available via
 #	pkgsrc's compiler wrappers.
+#
 #	If the package assumes the compiler defaults to a specific
 #	language version, the USE_LANGUAGES variable can also be used
 #	to force the inclusion of flags such as -std=c++11. In this case,
 #	USE_CC_FEATURES/USE_CXX_FEATURES should also be set.
+#
 #	Valid values are: c, c99, gnu99, c11, gnu11, c17, gnu17, c++, c++03,
 #	gnu++03, c++0x, gnu++0x, c++11, gnu++11, c++14, gnu++14, c++17,
 #	gnu++17, c++20, gnu++20, fortran, fortran77, java, objc, obj-c++, ada.
+#
 #	The default is "c".
+#
 # USE_CC_FEATURES
+#
 # 	Declares the C compiler features required by the package.
+#
 #	This is used to (optionally) install a newer compiler
 #	than provided by the system, or to skip building the package.
+#
 #	Valid values are: c11, c99, has_include.
+#
 # USE_CXX_FEATURES
+#
 # 	Declares the C++ compiler features required by the package.
+#
 #	This is used to (optionally) install a newer compiler
 #	than provided by the system, to or skip building the package.
+#
 #	Valid values are: c++11, c++14, c++17, c++20, has_include,
 #	regex, filesystem, unique_ptr, charconv, parallelism_ts,
-#	put_time.
+#	put_time, is_trivially_copy_constructible.
+#
 # The following variables are defined, and available for testing in
 # package Makefiles:
+#
 # CC_VERSION
 #	The compiler and version being used, e.g.,
+#
 #	.include "../../mk/compiler.mk"
+#
 #	.if !empty(CC_VERSION:Mgcc-3*)
 #	...
 #	.endif
+#
 # Keywords: compiler
 .if !defined(BSD_COMPILER_MK)
 BSD_COMPILER_MK=	defined
 _VARGROUPS+=		compiler
 _USER_VARS.compiler=	PKGSRC_COMPILER USE_PKGSRC_GCC ABI COMPILER_USE_SYMLINKS
 _PKG_VARS.compiler=	USE_LANGUAGES GCC_REQD NOT_FOR_COMPILER ONLY_FOR_COMPILER
 _SYS_VARS.compiler=	CC_VERSION
 .include "bsd.fast.prefs.mk"
 # Since most packages need a C compiler, this is the default value.
 USE_LANGUAGES?=	c
 _C_STD_VERSIONS=	c99 gnu99 c11 gnu11 c17 gnu17
 .for _version_ in ${_C_STD_VERSIONS}
 .  if !empty(USE_LANGUAGES:M${_version_})
 USE_LANGUAGES+=		c
 .  endif
 .endfor
 _CXX_STD_VERSIONS=	gnu++20 c++20 gnu++17 c++17 gnu++14 c++14 gnu++11 c++11 gnu++0x c++0x gnu++03 c++03
 .for _version_ in ${_CXX_STD_VERSIONS}
 .  if !empty(USE_LANGUAGES:M${_version_})
 USE_LANGUAGES+=		c++
 .  endif
 .endfor
 #.READONLY: USE_LANGUAGES
 _USE_LANGUAGES_EFFECTIVE:=	${USE_LANGUAGES}
 COMPILER_USE_SYMLINKS?=	yes
 _COMPILERS=		ccc clang gcc hp icc ido \
 			mipspro mipspro-ucode pcc sunpro xlc
 _PSEUDO_COMPILERS=	ccache distcc f2c g95
 .if defined(NOT_FOR_COMPILER) && !empty(NOT_FOR_COMPILER)
 .  for _compiler_ in ${_COMPILERS}
 .    if ${NOT_FOR_COMPILER:M${_compiler_}} == ""
 _ACCEPTABLE_COMPILERS+=	${_compiler_}
 .    endif
 .  endfor
 .elif defined(ONLY_FOR_COMPILER) && !empty(ONLY_FOR_COMPILER)
 .  for _compiler_ in ${_COMPILERS}
 .    if ${ONLY_FOR_COMPILER:M${_compiler_}} != ""
 _ACCEPTABLE_COMPILERS+=	${_compiler_}
 .    endif
 .  endfor
 .else
 _ACCEPTABLE_COMPILERS+=	${_COMPILERS}
 .endif
 # Currently only gcc-based compilers support Ada
 # Override PKGSRC_COMPILER if Ada language specified
 .if !empty(USE_LANGUAGES:Mada)
 PKGSRC_COMPILER=	gcc
 .endif
 .if defined(_ACCEPTABLE_COMPILERS)
 .  for _acceptable_ in ${_ACCEPTABLE_COMPILERS}
 .    for _compiler_ in ${PKGSRC_COMPILER}
 .      if !empty(_ACCEPTABLE_COMPILERS:M${_compiler_}) && !defined(_COMPILER)
 _COMPILER=	${_compiler_}
 .      endif
 .    endfor
 .  endfor
 .endif
 .if !defined(_COMPILER)
 PKG_FAIL_REASON+=	"No acceptable compiler found for ${PKGNAME}."
 .endif
 .for _compiler_ in ${PKGSRC_COMPILER}
 .  if !empty(_PSEUDO_COMPILERS:M${_compiler_})
 _PKGSRC_COMPILER:=	${_compiler_} ${_PKGSRC_COMPILER}
 .  endif
 .endfor
 _PKGSRC_COMPILER:=	${_COMPILER} ${_PKGSRC_COMPILER}
 _COMPILER_STRIP_VARS=	# empty
 .for _compiler_ in ${_PKGSRC_COMPILER}
 .  include "compiler/${_compiler_}.mk"
 .endfor
 .undef _compiler_
 .if !defined(PKG_CPP)
 PKG_CPP:=${CPP}
 .endif
 # Ensure the Solaris linker is used by default.
 .if ${OPSYS} == "SunOS"
 .  if exists(/usr/ccs/bin/ld)
 PKG_LD?=       /usr/ccs/bin/ld
 .  elif exists(/usr/bin/ld)
 PKG_LD?=       /usr/bin/ld
 .  endif
 .endif
 # Strip the leading paths from the toolchain variables since we manipulate
 # the PATH to use the correct executable.
+#
 .for _var_ in ${_COMPILER_STRIP_VARS}
 .  if empty(${_var_}:C/^/_asdf_/1:N_asdf_*)
 ${_var_}:=	${${_var_}:C/^/_asdf_/1:M_asdf_*:S/^_asdf_//:T}
 .  else
 ${_var_}:=	${${_var_}:C/^/_asdf_/1:M_asdf_*:S/^_asdf_//:T} ${${_var_}:C/^/_asdf_/1:N_asdf_*}
 .  endif
 .endfor
 # Pass the compiler flag based on the most recent version of the C or C++
 # standard required.  We currently assume that each standard is a superset of
 # all that come after it.
+#
 _C_VERSION_REQD=
 .for _version_ in ${_C_STD_VERSIONS}
 .  if empty(_C_VERSION_REQD) && !empty(USE_LANGUAGES:M${_version_})
 _C_VERSION_REQD=	${_version_}
 _WRAP_EXTRA_ARGS.CC+=	${_C_STD_FLAG.${_C_VERSION_REQD}}
 CWRAPPERS_PREPEND.cc+=	${_C_STD_FLAG.${_C_VERSION_REQD}}
 .  endif
 .endfor
 _CXX_VERSION_REQD=
 .for _version_ in ${_CXX_STD_VERSIONS}
 .  if empty(_CXX_VERSION_REQD) && !empty(USE_LANGUAGES:M${_version_})
 _CXX_VERSION_REQD=	${_version_}
 _WRAP_EXTRA_ARGS.CXX+=	${_CXX_STD_FLAG.${_CXX_VERSION_REQD}}
 CWRAPPERS_PREPEND.cxx+=	${_CXX_STD_FLAG.${_CXX_VERSION_REQD}}
 .  endif
 .endfor
 .if defined(ABI) && !empty(ABI)
 _WRAP_EXTRA_ARGS.CC+=	${_COMPILER_ABI_FLAG.${ABI}}
 _WRAP_EXTRA_ARGS.CXX+=	${_COMPILER_ABI_FLAG.${ABI}}
 _WRAP_EXTRA_ARGS.FC+=	${_COMPILER_ABI_FLAG.${ABI}}
 CWRAPPERS_PREPEND.cc+=	${_COMPILER_ABI_FLAG.${ABI}}
 CWRAPPERS_PREPEND.cxx+=	${_COMPILER_ABI_FLAG.${ABI}}
 CWRAPPERS_PREPEND.f77+=	${_COMPILER_ABI_FLAG.${ABI}}
 .endif
 # Enable SSP if the user has chosen to and the compiler supports it.
+#
 .if ${_PKGSRC_USE_SSP} == "yes" && defined(_SSP_CFLAGS)
 _WRAP_EXTRA_ARGS.CC+=	${_SSP_CFLAGS}
 _WRAP_EXTRA_ARGS.CXX+=	${_SSP_CFLAGS}
 CWRAPPERS_APPEND.cc+=	${_SSP_CFLAGS}
 CWRAPPERS_APPEND.cxx+=	${_SSP_CFLAGS}
 CWRAPPERS_APPEND.f77+=	${_SSP_CFLAGS}
 .endif
 # Add debug flags if the user has requested CTF and the compiler supports it.
+#
 .if ${_PKGSRC_USE_CTF} == "yes" && defined(_CTF_CFLAGS)
 _WRAP_EXTRA_ARGS.CC+=	${_CTF_CFLAGS}
 CWRAPPERS_APPEND.cc+=	${_CTF_CFLAGS}
 .endif
 # Add sysroot if using cross-compilation tools.
+#
 .if !empty(TOOLS_USE_CROSS_COMPILE:M[yY][eE][sS])
 CWRAPPERS_PREPEND.cc+=	--sysroot=${TOOLS_CROSS_DESTDIR:Q}
 CWRAPPERS_PREPEND.cxx+=	--sysroot=${TOOLS_CROSS_DESTDIR:Q}
 CWRAPPERS_PREPEND.ld+=	--sysroot=${TOOLS_CROSS_DESTDIR:Q}
 # XXX cross fortran
 .endif
 # If the languages are not requested, force them not to be available
 # in the generated wrappers.
+#
 _FAIL_WRAPPER.CC=	${WRKDIR}/.compiler/bin/c-fail-wrapper
 _FAIL_WRAPPER.CXX=	${WRKDIR}/.compiler/bin/c++-fail-wrapper
 _FAIL_WRAPPER.FC=	${WRKDIR}/.compiler/bin/fortran-fail-wrapper
 _FAIL_WRAPPER.ADA=	${WRKDIR}/.compiler/bin/ada-fail-wrapper
 ${_FAIL_WRAPPER.CC}: fail-wrapper
 ${_FAIL_WRAPPER.CXX}: fail-wrapper
 ${_FAIL_WRAPPER.FC}: fail-wrapper
 ${_FAIL_WRAPPER.ADA}: fail-wrapper
 .PHONY: fail-wrapper
 fail-wrapper: .USE
 	${RUN}								\
 	${TEST} -d ${.TARGET:H} || ${MKDIR} ${.TARGET:H};		\
 	exec 1>${.TARGET};						\
 	${ECHO} '#!'${TOOLS_SHELL:Q};					\
 	${ECHO} 'wrapperlog="$${TOOLS_WRAPPER_LOG-'${_TOOLS_WRAP_LOG:Q}'}"'; \
 	${ECHO} 'lang="${.TARGET:T:S/-fail-wrapper//}"'; \
 	${ECHO} 'msg="*** Please consider adding $$lang to USE_LANGUAGES in the package Makefile."'; \
 	${ECHO} '${ECHO} "$$msg" >> $$wrapperlog'; \
 	${ECHO} '${ECHO} "$$msg" > ${WARNING_DIR}/${.TARGET:T}'; \
 	${ECHO} '${ECHO} "PKGSRC-WARNING: Something is trying to run the $$lang compiler," 1>&2'; \
 	${ECHO} '${ECHO} "PKGSRC-WARNING: but it is not added to USE_LANGUAGES in the package Makefile." 1>&2'; \
 	${ECHO} 'exit 1';						\
 	${CHMOD} +x ${.TARGET}
 .if empty(USE_LANGUAGES:Mc) && empty(USE_LANGUAGES:Mobjc) && empty(USE_LANGUAGES:Mobjc-c++)
 PKG_CC:=		${_FAIL_WRAPPER.CC}
 ALL_ENV+=		CPP=${CPP:Q}
 override-tools: ${_FAIL_WRAPPER.CC}
 .endif
 .if empty(USE_LANGUAGES:Mc++)
 PKG_CXX:=		${_FAIL_WRAPPER.CXX}
 ALL_ENV+=		CXXCPP=${CPP:Q} # to make some Autoconf scripts happy
 override-tools: ${_FAIL_WRAPPER.CXX}
 .endif
 .if empty(USE_LANGUAGES:Mfortran) && empty(USE_LANGUAGES:Mfortran77)
 PKG_FC:=		${_FAIL_WRAPPER.FC}
 override-tools: ${_FAIL_WRAPPER.FC}
 .endif
 .if empty(USE_LANGUAGES:Mada)
 PKG_ADA:=		${_FAIL_WRAPPER.ADA}
 override-tools: ${_FAIL_WRAPPER.ADA}
 .endif
 .if !empty(DRAGONFLY_CCVER) && ${OPSYS} == "DragonFly"
 ALL_ENV+=		CCVER=${DRAGONFLY_CCVER}
 .endif
 .endif	# BSD_COMPILER_MK
 .if ${CHECK_COMPILER:Uno:tl} == yes
 .  if ${USE_LANGUAGES:O:u} != ${_USE_LANGUAGES_EFFECTIVE:O:u}
 .warning For ${PKGPATH}, only languages "${_USE_LANGUAGES_EFFECTIVE}" are used, the others in "${USE_LANGUAGES}" were defined too late.
 .  endif
 .  if ${GCC_REQD:U:O:u} != ${_GCC_REQD_EFFECTIVE:U:O:u}
 .warning For ${PKGPATH}, only GCC_REQD "${_GCC_REQD_EFFECTIVE}" are used, the others in "${GCC_REQD}" were defined too late.
 .  endif
 .endif