-fmemoize-lookups as gcc 3.4 doesn't understand it. [1]
. Use CXX and CXXFLAGS for compiling C++ code, not CPP and CPPFLAGS.
Also, respect the setting of CXX and CXXFLAGS.
PR: 71516 [1]
Submitted by: Damir Kiramov <damirycha@damirycha.net.ru> [1]
where previously they defaulted to protected. gcc 3.4 seems to pick
this up where earlier versions didn't.
PR: 71516
Submitted by: Damir Kiramov <damirycha@damirycha.net.ru>
PLIST_FILES for scripts [1]
- Use FIND | INSTALL_DATA to install documentation rather than CP -r
- Added a missing SETENV macro in pre-install target
- Put JAVA_HOME/bin in front of PATH as the new javavmwrapper version would
otherwise cause trouble (see UPDATING for further information)
- ECHO_CMD -> ECHO_MSG
- Tweaked the comment: the name of the port is redundant here
PR: 72900
Requested by: linimon [1]
- Update to bsd.java.mk 2.0
- Use USE_ANT
- Cleanup unused variables
- Do not try to remove JAVAJARDIR
- Remove some sed magic in dynamic plist process (make will perform most of
these substitutions)
- Use PLIST_FILES and %%JAVAJARDIR%% to reduce plist build process
- Bumped PORTREVISION as a new file is installed
PR: ports/73284, java/43947 [1]
Suggested by: znerd [1]
Submitted by: me
Approved by: maintainer
- Update to bsd.java.mk 2.0
- Use JAVAJARDIR
- Removed patch, added a launcher script file
- Use javavmwrapper to run Java in the launcher script
- Honor hier(7): docs in DOCSDIR and samples in EXAMPLESDIR
- Honor NOPORTDOCS
- Dynamic plist
- do-build -> do-configure (and NO_BUILD=yes)
- ECHO -> ECHO_MSG
- Bumped PORTREVISION as many file locations has changed and the use of
javavmwrapper will allow user to use different JVMs
PR: 72883 [1]
Submitted by: Aaron Dalton <aaron@daltons.ca> [1]
Approved by: maintainer timeout
- Honor hier(7): install docs in DOCSDIR and examples in EXAMPLESDIR [1]
- Use FIND | INSTALL_DATA to install docs, samples and data files
- Fix distfile location for "Community Edition" and add some more
MASTER_SITES [1]
- Dynamic plist
- Minimal required JDK version is now 1.3 [1]
- Merge patches
PR: 74119 [1]
Submitted by: maintainer [1]
utilities. Unfortunately this overrides any PATH that may have been
set by the user and hence affects the ability of java to execute
external programmes. So, save the PATH before setting it and then
restore it immediately before executing java.
. Bump PORTREVISION for this fix.
Reported by: Christian Laursen <xi@borderworlds.dk>
allow the simple use of multiple VMs. Brief detail of the main changes:
. When a VM is registered, symbolic links for its executables are
created in ${LOCALBASE}/bin. This allows people to just type
'java', 'javac', etc. without having to add the VM installation
directory to their PATH.
. The actual 'java' that is executed via one of these symlinks is
determined by the order of the (sorted) configuration file
${LOCALBASE}/etc/javavms and by the environment variables
JAVA_VERSION, JAVA_OS and JAVA_VENDOR which function to select
a VM as they do in the ports framework.
. There is a new command, checkvms, to sanity check the configuration
and symlinks.
. The "javavm" executable is currently retained in its original capacity
as a synonym for Java for backward compatibility. However, its use
is deprecated.
. Temporarily set MAINTAINER to myself to make monitoring any initial
bug reports easier. The intent is to convert it to java@ at a later
date.
This is built on the ideas of znerd, hq and Shelton C. Johnson Jr., with
hq and Shelton contributing code and reviews.
PR: 27079, 39080
Reviewed by: hq, Shelton C. Johnson Jr. <shelton_c_j@yahoo.com>
This was found implicitly dependency on unzip by
pointyhat. In almost environment, this is not a
problem and isn't regist installed package
database. So I don't bump PORTREVISION.
Pointed out by: pointyhat via kris
o Reset MAINTAINER to java@.
o Bump PORTREVISION accordingly.
PR: ports/72802
Submitted by: Jeremy Faulkner <gldisater@gldis.ca>
Approved by: maintainer no response
o Use native JDK rather than linux-sun-jdk. [2]
o Utilize WITH_MOZILLA. It provies to use mozilla or firefox. [2]
o Fix some port's bugs. [2]
o Add zip to BUILD_DEPENDS and fix build error without zip. [3]
PR: ports/72990 [1], ports/72475 [2]
Submitted by: Jeremy Faulkner <gldisater@gldis.ca> [1], [2]
Pointed out by: pointy via kris [3]
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
