the libtoolX ports instead of the one included with each port. Ports that
set USE_LIBTOOL_VER=X will now use the ports version of libtool instead of
the included version. To restore previous behavior, use the new macro,
USE_INC_LIBTOOL_VER. Both macros accept the same argument: a libtool version.
For example, to use the ports version of libtool-1.5, add the following to
your Makefile:
USE_LIBTOOL_VER= 15
To use the included version of libtool with extra hacks provided by
libtool-1.5, add the following to your Makefile:
USE_INC_LIBTOOL_VER= 15
With this change, ports that had to add additional libtool hacks to prevent
.la files from being installed or to fix certain threading issues can now
delete those hacks (after appropriate testing, of course).
PR: 63944
Based on work by:eik and marcus
Approved by: ade (autotools maintainer)
Tested by: kris on pointyhat
Bound to be hidden problems: You bet
logfile, one Linux-only change, and one change in a test script). Assign
submitter as new maintainer as current one has not responded to PRs for
some time.
PR: ports/68199
Submitted by: Fernan Aguero <fernan at iib dot unsam dot edu dot ar>
this is a followup to ports/67432
I completely overlooked the fact that the port was setting
PATCH_SITES, here's a fix for that
maintainer cc'd
PR: ports/67441
Submitted by: Roman Neuhauser <neuhauser@chello.cz>
Since the distfile has no version number, put it in
DIST_SUBDIR= ${PORTNAME}-${PORTVERSION}
PR: 66817
Submitted by: Fernan Aguero <fernan@iib.unsam.edu.ar> (new maintainer)
behaviour of -fPIC and -fpic are different.
Here is the comment form obrien:
--
"-fpic" is a [minor?] optimization for machines that can handle it:
-fpic
Generate position-independent code (PIC) suitable for use in a shared
library, if supported for the target machine. Such code accesses all
constant addresses through a global offset table (GOT). The dynamic
loader resolves the GOT entries when the program starts (the dynamic
loader is not part of GCC; it is part of the operating system). If
the GOT size for the linked executable exceeds a machine-specific
maximum size, you get an error message from the linker indicating
that -fpic does not work; in that case, recompile with -fPIC instead.
(These maximums are 16k on the m88k, 8k on the SPARC, and 32k on the
m68k and RS/6000. The 386 has no such limit.)
-fPIC
If supported for the target machine, emit position-independent code,
suitable for dynamic linking and avoiding any limit on the size of
the global offset table. This option makes a difference on the m68k,
m88k, and the SPARC.
Thanks to: obrien
