due to freetds installation changes and may also depend on gettext-lib.)
Include buildlink for gettext-lib, because CTlib.so uses libintl.so
(noticed on build failure on DragonFly and then saw on NetBSD 2.1 too).
Remove freetds subdirectory from the buildlink directory used during build.
(This is because of recent installation changes for freetds.)
module directory has changed (eg. "darwin-2level" vs.
"darwin-thread-multi-2level").
binary packages of perl modules need to be distinguishable between
being built against threaded perl and unthreaded perl, so bump the
PKGREVISION of all perl module packages and introduce
BUILDLINK_RECOMMENDED for perl as perl>=5.8.5nb5 so the correct
dependencies are registered and the binary packages are distinct.
addresses PR pkg/28619 from H. Todd Fujinaka.
in the process. (More information on tech-pkg.)
Bump PKGREVISION and BUILDLINK_DEPENDS of all packages using libtool and
installing .la files.
Bump PKGREVISION (only) of all packages depending directly on the above
via a buildlink3 include.
which are the full option names used to set rpath directives for the
linker and the compiler, respectively. In places were we are invoking
the linker, use "${LINKER_RPATH_FLAG} <path>", where the space is
inserted in case the flag is a word, e.g. -rpath. The default values
of *_RPATH_FLAG are set by the compiler/*.mk files, depending on the
compiler that you use. They may be overridden on a ${OPSYS}-specific
basis by setting _OPSYS_LINKER_RPATH_FLAG and _OPSYS_COMPILER_RPATH_FLAG,
respectively. Garbage-collect _OPSYS_RPATH_NAME and _COMPILER_LD_FLAG.
sybperl includes four modules: Sybase::DBlib, Sybase::CTlib,
Sybase::BCP and Sybase::Sybperl. The first two implement a thin
wrapper around the Sybase DB-Library and Client Library APIs,
respectively. Sybase::BCP is a specialty module aimed at doing
Bulk-Copy operations, and Sybase::Sybperl is a compatibility module
with sybperl 1.xx (i.e. with the perl 4.x version).
The sybperl modules are thin wrappers around the Sybase APIs. This is
both good and bad. It's good because you have greater control, and
because the API is (obviously) close to the way the server and the
protocol work. It's bad in that it's a proprietary API, and that it is
somewhat verbose.
