- remove some a.out mentions
- adjust USE_LIBTOOL now that this is the default and talk about
CMake as well since this works in a similar way
- remove the outdated list of autoconf versions in the ports tree
and suggest that people use the version originally used in the distfile
any comments?
Index: specialtopics.html
===================================================================
RCS file: /cvs/www/faq/ports/specialtopics.html,v
retrieving revision 1.31
diff -u -p -r1.31 specialtopics.html
--- specialtopics.html 22 Jun 2013 09:58:46 -0000 1.31
+++ specialtopics.html 12 Nov 2013 09:00:07 -0000
@@ -109,9 +109,6 @@ Sometimes, it happens that a library is
internal functions happen to be visible to communicate between those files.
Those function names traditionally begin with an underscore, and are not
part of the API proper.
-<p>
-Note that the library naming scheme is ubiquitous on OpenBSD platforms,
-whether they be ELF or a.out.
<h3>Tweaking ports builds to achieve the right names</h3>
Quite a few ports need tweaks to build shared libraries correctly anyways.
@@ -128,18 +125,23 @@ internal name, so you must link it with
<p>
On the other hand, remember that you can override <tt>Makefile</tt> variables
from
the command line, by using <tt>MAKE_FLAGS</tt> in the port's <tt>Makefile</tt>.
-This is quite valuable in, for instance, libtool-based ports, which provide
-one such version variable for each library they create.
+In some cases, the program you're porting will have a simple variable which
+you can override by setting the library version in MAKE_FLAGS, for example
+<tt>MAKE_FLAGS= SO_VERSION=${LIBfoo_VERSION}</tt>.
+In others, the port will need to be patched to make use of such a variable.
<p>
-The best way to handle libtool-based ports is to set
-<tt>USE_LIBTOOL=Yes</tt>.
-This activates the version of libtool in base, which handles most details
-automatically:
+The ports infrastructure already handles these details in libtool-based
+and CMake-based ports.
+For libtool, by default the version from the base OS is used, but in some
+cases this is insufficient and <tt>USE_LIBTOOL=gnu</tt> can be set.
+CMake is handled by using the <tt>cmake.port.mk</tt> module:
+<tt>MODULES += devel/cmake</tt>.
+In these cases, most details are handled automatically:
<ul>
- <li>libtool looks at <tt>SHARED_LIBS</tt> and automatically
- replaces version numbers.
- <li>libtool produces a log of shared library building in
+ <li><tt>SHARED_LIBS</tt> is examined and version numbers are
+ automatically replaced.
+ <li>shared library building is logged in
<tt>${WRKBUILD}/shared_libs.log</tt> which can be directly
included in the port's <tt>Makefile</tt>.
</ul>
@@ -444,9 +446,9 @@ Which autoconf script actually gets call
environment variable <tt>AUTOCONF_VERSION</tt>.
Calling autoconf happens if you set <tt>CONFIGURE_STYLE=autoconf</tt>,
together with setting <tt>AUTOCONF_VERSION</tt>.
-Versions currently available are 2.13, 2.52, 2.54, 2.56, 2.57, 2.58,
-2.59, 2.60, 2.61, 2.62, 2.63, 2.64, 2.65, 2.67 and 2.68.
-These cover 99% of all configure scripts out there.
+In most cases, identify the version of autoconf that was used to generate
+the distributed configure script (usually obvious when reading the script)
+and use this same version yourself.
<p>
autoconf relies on the standard unix preprocessor m4(1).
