It's meant to be used directly in place of libtiff.so, i.e. instead
of linking against -ltiff, you link against -ltiffcxx. It also leaves
libtiff.so as a plain C-linkage library again, as it was in tiff-3.6.x,
and avoids needing to patch tiff-using packages to link using the C++
compiler. Bump the PKGREVISION to 1.
Remove OpenWindows workaround in pkgsrc for this.
Too many changes to include here.
See http://www.remotesensing.org/libtiff/v3.7.1.html
and http://www.remotesensing.org/libtiff/v3.7.0.html
and previous change files for changes information.
tiff-3.7.1 now includes the lzw compression code again.
It also uses autoconf and libtool now.
A new tool is bmp2tiff.
Docs are placed under share/doc/tiff/html instead of share/doc/html/tiff.
Many manpage symlinks are now missing. (This was reported to tiff list.)
But now these are improved in response to
iDEFENSE Security Advisory 12.21.04
www.idefense.com/application/poi/display?id=173&type=vulnerabilities
libtiff STRIPOFFSETS Integer Overflow Vulnerability
December 21, 2004
This fix (in two files) was from that advisory and also seen
in tiff 3.7.1.
PKGREVISION is bumped to 6 and BUILDLINK_RECOMMENDED is adjusted for
this possible security issue. Other packages depending on this are not
bumped.
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.
by moving the inclusion of buildlink3.mk files outside of the protected
region. This bug would be seen by users that have set PREFER_PKGSRC
or PREFER_NATIVE to non-default values.
BUILDLINK_PACKAGES should be ordered so that for any package in the
list, that package doesn't depend on any packages to the left of it
in the list. This ordering property is used to check for builtin
packages in the correct order. The problem was that including a
buildlink3.mk file for <pkg> correctly ensured that <pkg> was removed
from BUILDLINK_PACKAGES and appended to the end. However, since the
inclusion of any other buildlink3.mk files within that buildlink3.mk
was in a region that was protected against multiple inclusion, those
dependencies weren't also moved to the end of BUILDLINK_PACKAGES.
the normal case when BUILDLINK_DEPENDS.<pkg> isn't specified, it receives
a value only once due to the multiple inclusion protection in the
bulldlink3.mk files. In the case where a package includes several
buildlink3.mk files that each want a slightly different version of another
dependency, having BUILDLINK_DEPENDS.<pkg> be a list allows for the
strictest <pkg> dependency to be matched.
