but do it correctly. The way this was done before, by simply statically
linking all the objects into a perl binary without recompiling the objects
without -fPIC, was wrong as pointed out in private email by Todd Vierling.
We now simply reconfigure perl to link statically, and use the perl build
process to generate a statically-linked perl.
to install things like "open.3" and "lib.3" which confuse users. Perl
ships with a documentation tool, "perldoc", for this purpose; create a
MESSAGE indicating that it should be used instead. (Perl still installs
command line program manual pages in man1.)
* Integrate bsd.perl.mk into the perl5-base build where it should have been
from the beginning. The separate perl-mk pkg makes binary packages of
perl-mk completely useless[*]. Older perl builders will not break, since
<bsd.pkg.mk> contains fallback definitions that are evaluated at pkg
build time.
=====
[*] bsd.perl.mk is tightly bound to the version of perl that is installed.
The version name "perl-mk-1.1" is completely useless as a binary pkg,
since keeping multiple binary versions of perl on a FTP server means
that one of the perl-mk's will get clobbered.
However, putting the current pkgsrc PERL5_DIST_VERS in the perl-mk pkg
is also a problem, because that doesn't necessarily reflect the
installed version of perl. Snarfing the installed version at perl-mk
build time would be even uglier, since you could not then walk the tree
without perl being installed.
The cleanest solution is to integrate bsd.perl.mk into the perl5-base
pkg, and let those who have not upgraded perl yet use the runtime
definitions in <bsd.pkg.mk>.
the plugging of several memory leaks, fixes to the regular expression
engine, the addition of a Unicode character classes, better support for
64-bit platorms, and updates of many modules in the base Perl Library.
See perldelta.pod for more details.
Also update p5-Data-Dumper, p5-Devel-DProf, and p5-Devel-Peek to the
latest versions distributed with the perl-5.6.1 sources, and libperl to
5.6.1 to match the perl package.
and installing libperl as a shared libarary on platforms that support
shared libraries (or those that explicitly define MKPIC=yes). As a
compromise for those platforms that have the need for speed and thus a
statically-linked perl binary, explicitly link perl against a static
libperl.a.
Before this update, the current situtation was that we installed the static
library in perl and the shared library in libperl. This caused the wrong
linker flags to be passed to perl packages and they might have gotten a
hidden dependency on libperl depending on whether they were built with or
without libperl installed. Avoid all this by only having the static or
shared library installed at any time.
included in the perl executable. We need this to make the upcoming
xerces-perl package working.
This hack should be made obsolete by gcc-3.0, which will have a libgcc.so.
See http://mail-index.netbsd.org/tech-pkg/2001/04/07/0000.html for more details
The patch against regcomp.c (uninitialized variable) has been fed back
to the perl maintainers. The others are more like workarounds for known
toolchain problems and not fed back (for now).
The hints/netbsd.sh file has an additional change: the perl buildin malloc
(which is disabled in pkgsrc builds via configure arguments anyway) is now
disabled in the hints file as well. This makes it possible to build a
working perl outside of pkgsrc with this hints file. Wheter this hints file
should be fed back is subject to further discussion.
Make perl not build against a dynamic libperl.so.
There are two reasons: (a) the dynamic libperl.so version does not work
at all on sparc64, and (b) the static linked version is said to have a
significant performance improvement on some platforms (i.e. sparc). I think
the libperl.so was enabled by accident when switching from perl 5.0.4 to
5.6.0.
Other packages using libperl.so should not depend on perl5-base but on
../libperl.
