Unfortunately, Ruby has problem with thread library even if recent
release of 1.8.1. So, a program using ruby's library shouldn't link
with thread library.
Bump PKGREVISION.
To see a full list of changes, please review:
http://xfree86.org/4.4.0/RELNOTES.html
These packages has been tested under NetBSD 1.6/-current, FreeBSD 4.x/5.x,
and GNU/Linux (i386) by Jeremy C. Reed, Michal Pasternak and myself.
that accumulates within itself with a do-nothing version because it tried
to re-use LDFLAGS for another purpose. This broke all library checks after
the "checking for ELF" step. Fix this by (duh) not re-using LDFLAGS but
by using a different variable. Bump the PKGREVISIONs of lang/tcl and
x11/tk.
This fixes building the threaded versions of tcl and tk.
This a re-port of a perl interface to Tk8.4.
C code is derived from Tcl/Tk8.4.5.
It also includes all the C code parts of Tix8.1.4 from SourceForge.
The perl code corresponding to Tix's Tcl code is not fully implemented.
Perl API is essentially the same as Tk800 series Tk800.025 but has not
been verified as compliant. There ARE differences see pod/804delta.pod.
The goal of this release is Unicode support via perl's and
core-tk's use of UTF-8.
Tk804.026 builds and loads into a threaded perl but is NOT
yet thread safe.
This Tk804 is only likely to work with perl5.8.0 or later.
Perl's UTF-8 support has improved since it was introduced in perl5.6.0.
Some functions (regular expression match in Text widgets) are known
to only work with perl5.8.1 and later
There are a lot more tests in Tk804. Some notably t/entry.t and
t/listbox.t very dependant on the available fonts and to a lesser
extent the window manager used. (See below for a list of fails
which can be "expected" even if nothing is really wrong.)
Others t/JP.t and t/KR.t need oriental fonts and can take a long time to
run on a machine with a lot of fonts but which lacks the glyphs tests are
looking for.
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.
