appears to actually match the type of variable its being used with in the
code (although it seems that it may be even cleaner to just replace 'fastInt'
with 'short').
This also partially bandaids a build problem some are seeing since Hint.h
is a less common header file name than cpu.h.
. Replace some hardwired /usr/local instances with LOCALBASE.
. Small Makefile restructure to keep related variables in one place.
. Add ipv6 to CATEGORIES if its enabled. [2]
PR: 106130 [2]
Submitted by: Janos Mohacsi <janos.mohacsi@bsd.hu> [2]
Pointed out by: pointyhat (via kris) [1]
building, the JDK zone info file doesn't exist yet, so attempting to
get the zone info for GMT_ID would fail.
Submitted by: Kurt Miller <kurt@intricatesoftware.com>
defining O_SYNC and O_DSYNC if they aren't defined. In particular we
were previously defining O_SYNC bogusly to the same value as O_EXCL.
PR not closed as this fixes jdk15, not diablo-jdk15.
PR: 102888
can't use -j in general since the build of the other bits is almost
certainly not -j safe. If set, this will speed up the build for those
with an SMP box. [1]
. Install the cacerts file from Sun's JDK 1.5.0_06 release rather than
using the almost empty one that comes with the SCSL source. [2]
. Bump PORTREVISION for the second change.
PR: 87552 [1]
Submitted by: leafy <leafy@leafy.idv.tw> [1]
Prompted by: Panagiotis Astithas <past@ebs.gr> [2]
copy. This should have the following effects:
. Fix problems experienced by programmes that dynamically create their
own copy of the JVM and are linked against the system's zlib (e.g.,
eclipse).
. Reduce the potential for zlib based security problems affecting the
JDK.
Submitted by: mi@
in the systems libz.so. This conflict broke applications such as
Eclipse which is linked with libz.so (via gtk+ I believe).
This is a slightly modified version of the submitter's patch.
A better solution may be to link with the system's libz.so and remove
the JDK's internal zlib code altogether, but I'd like to test that a
little more first. Until then this solves the problem.
. Bump PORTREVISION since Eclipse seems to be quite widely used.
Submitted by: "Arno J. Klaassen" <arno@heho.snv.jussieu.fr>
valid one doesn't currently exist.
. Add a pkg-deinstall which removes the symbolic link if this port owns it.
. Produce pkg-install and pkg-deinstall with SUB_FILES and SUB_LIST rather
than manually using ${SED} ourselves.
Approved by: maintainer timeout
http://java.sun.com/j2se/1.5.0/docs/guide/awt/1.5/xawt.html
it has some advantages over XToolkit. Its also the default on Linux
and Solaris will be switching to it. Some people have reported that
it fixes a crash in the browser plugin for them.
Please let me know straight away if this causes problems, particularly
with Swing, as it hasn't been extensively tested. The web page
mentioned above explains how to switch the toolkits dynamically so you
can compare them.
Submitted by: Huang wen hui <hwh@gddsn.org.cn>
(the awt_LoadLibrary.c patch)
Approved by: phantom (maintainer)
. Many patches are now unnecessary as they are included in the new
patchset.
. The browser plugin and Java Web Start is enabled on i386 (there are
64 bit issues with both the plugin and Mozilla/Firefox which prevent
enabling it on amd64).
. Update the amount of disk space needed.
. Update the status of the port.
. Disable building the shared class data archive. This broke the build
on amd64 and appears to also be problematic on some i386 versions
(4.11 is broken at least). It will reappear in future, probably
initially on a limited set of FreeBSD versions and architectures
(6.0/i386 is reported to work).
Reviewed by: freebsd-java@
Approved by: maintainer timeout (1 week)
in or below the current working directory. Fixes a security problem with
jar(1).
This fix may change to be compatible with whatever fix Sun applies when
they release the next version of 1.5.
. Bump PORTREVISION for this fix.
Security: http://vuxml.FreeBSD.org/18e5428f-ae7c-11d9-837d-000e0c2e438a.html
Reviewed by: maintainer timeout
. /etc/localtime is a symlink.
. /etc/localtime contains a time zone not recognised by the JDK.
Submitted by: Kurt Miller <truk@optonline.net>
Reviewed by: maintainer timeout
hence the path for the shared libraries doesn't always work on FreeBSD.
It definitely fails on FreeBSD 4.11 and FreeBSD 6-CURRENT under the
tested environments. In fact, the dladdr(3) man page even warns of
these problems. While there is work under way to fix this, it isn't
available yet.
Given that situation, switch to trying /proc/curproc/file, which is
similar to what Linux does, and if that fails, drop back to checking
argv[0] and iterating through $PATH as in jdk 1.4. Both these methods
work correctly in testing.
Reported by: das
Reviewed by: maintainer timeout
unfortunately sending it to stdout. When using such a JDK to bootstrap
this line ends up at the head of generated classes, leaving them
uncompilable. Add a filter to the class generation to strip out such
lines with egrep.
A similar patch is present in the jdk14 port and prevents a semi-common
class of error reports.
Approved by: phantom (maintainer)
family -- first public patchset of native Sun JDK 1.5.0 port.
Most valuable addition of this patchset is native amd64 support.
And special thanks goes to Daniel Seuffert <ds@freeBSD.org> for
making it possible by providing amd64 hardware.
This patchset was tested on following configurations: i386/4.10,
i386/5.3, amd64/5.3. 5.3-RELEASE support is quite strong and
shown no huge visible problems over last week.
But even mentioning above note, keep in mind -- THIS IS ALPHA
PATCHSET and suitable for testers/developers ONLY!
Known issues are including (but for sure not limited to):
. Browser plugin support is missing
. JVMTI, JDWP and JMX are not tested yet
. FreeBSD i386/4.10 support is suffering from hidden memory
allocation failres (ideas and patches are welcome)
NOTE ABOUT BOOTSTRAPING: It's possible to bootstrap jdk 1.5.0 using
jdk 1.4.2 (either native or linux one). There's no need to have
java/linux_jdk15 installed and working.
Supported by: FreeBSD Foundation
a generated file will be overwritten with a warning, causing the
build to fail. There is a check for linprocfs in pre-build, but it
seems as though this problem can somehow trigger anyway, based on
semi-regular reports to the mailing lists.
PR: 74999
Approved by: phantom
