- Remove USE_XLIB/USE_X_PREFIX/USE_XPM in favor of USE_XORG
- Remove X11BASE support in favor of LOCALBASE or PREFIX
- Use USE_LDCONFIG instead of INSTALLS_SHLIB
- Remove unneeded USE_GCC 3.4+
Thanks to all Helpers:
Dmitry Marakasov, Chess Griffin, beech@, dinoex, rafan, gahr,
ehaupt, nox, itetcu, flz, pav
PR: 116263
Tested on: pointyhat
Approved by: portmgr (pav)
data for the JDK using Sun's tzupdater. [1]
. Some simplification of the convoluted logic around telling the user
which files to download. In particular, don't care if we've already
told them to download a file.
. Bump PORTREVISION since many North American users will need to pick up
the time zone changes.
Collaboration with: Tim Zingelman <zingelman@fnal.gov> [1]
. Small Makefile restructure to keep related variables in one place.
. Trim the ancient bootstrapping options.
. Add ipv6 to CATEGORIES if its enabled. [2]
PR: 106129 [2]
Submitted by: Janos Mohacsi <janos.mohacsi@bsd.hu> [2]
Pointed out by: pointyhat (via kris) [1]
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.
This is similar to the patch in the PR, but was actually backported from
the patches for the jdk15 port, so its a touch different.
PR: 92459
failed to build the jdk14 port in a jail under FreeBSD 5.4
FreeBSD 4.11 works.
The problem is that mount don't list the linprocfs,
and this make the selfcheck fail.
maintainer emailed:
So 6 Nov 2005 11:21:20 CET
Approved by: (maintainer timeout)
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
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 a fixed version of 1.5.
. Bump PORTREVISION for this fix.
Approved by: maintainer timeout
Security: http://vuxml.FreeBSD.org/18e5428f-ae7c-11d9-837d-000e0c2e438a.html
files that are generated by the post-install script (which runs after
the dynamic packing list has been generated).
Approved by: portmgr (krion), phantom (maintainer)
This ensures that this command is run before the files in the package
are deleted (which is necessary for it to correctly delete the symbolic
links created by registervm).
Approved by: phantom (maintainer)
added open-motif-jdk port. It's controlled via WITH_OPENMOTIF_JDK
knob and currently disabled by default (it still requires additional
testing and checking)
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
existing the Solaris base, and similarly to what happened with NSPR, made
a bad assumption on undefined behavior. This broke locking in various
places in Java, for example, causing the the debugging support to be
totally broken. It is worth someone who knows the Java codebase taking
a look to see what other things could have been broken by this on
FreeBSD 5.x+.
The assumption is that pthread_mutex_trylock(3) on a default-type
mutex will fail with EBUSY. This assumption is wrong for our
libpthread, which returns EDEADLK if the owner thread is trying to
acquire the mutex again with trylock. The behavior of performing a
locking operation on a self-locked default-type mutex is explicitly
undefined for pthread_mutex_lock(3).
The POSIX specification is still not very clear. It defines
pthread_mutex_trylock(3) in terms of pthread_mutex_lock(3) yet
does not say what the defined behavior should be for a self-locked
pthread_mutex_trylock(3) for any of the various mutex types, so it is
ambiguous whether the result is clearly undefined or clearly to return
EBUSY.
It is a one line change whether or not to make libpthread return
EDEADLK in this case, where it seems that most implementations do not.
Reference: http://www.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_lock.html
The HotSpot code (ab)uses named enums as ints in a number of places.
The problem with this is that according the the C++ spec, the compiler
(essentially) only needs to use an integral type wide enough to hold
the values defined in the enum. Earlier versions of gcc appear to have
just used an int whether they could have got away with a narrower type
or not, hence the code worked as expected. gcc 3.4 now appears to
implement this part of the spec, so using an enum blindly as an int
causes various problems due to overflow.
In this case the enum, Bytecodes::Code, appears to be a genuine enum,
its just assumed to be wide enough to hold an arbitrary int in various
places in the code. The correct fix would be to track down all those
places in the code and fix them. Since there are quite a lot of these
places and 5.3 is close to release for now we just add a value to the
enum set to INT_MAX, forcing the compiler to use at least an int for the
type.
Sleuth work, discussion and code suggestions: peadar
