Changeset: 3a6ac3484b05
Author:cl
Date: 2013-10-21 23:33 -0700
URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3a6ac3484b05
8026974: solaris build missing java-rmi.cgi
Reviewed-by: ksrini
! makefiles/CompileLaunchers.gmk
On 2013-10-21 17:08, Erik Joelsson wrote:
JDK-8025715: Split CompileNativeLibraries.gmk, caused (almost) all
libraries on macosx to be linked incorrectly. I propose we fix this by
removing an ugly hack for libJObjC.dylib, which was only put there to
make the new and old build be as similar as
Hello,
I tried building with 4.0 in cygwin and it seemed to work fine. I doubt
there will be issues, but we will not move the official build there for
a long while yet. Until proven otherwise, I see no reason to hinder
developers from building with 4.x. Older versions of make are much worse
Still looks good to me.
/Erik
On 2013-10-22 05:34, David DeHaven wrote:
Updated webrev for JDK (hotspot change is the same):
http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/
Changes since last version:
- Moved to jdk8/build/jdk to save someone a merge headache, moved changes to
Hi, David,
thanks for additional cleanup.
I have only one concern. Before the fix, we checked if there is an
active Aqua session. When no session was found, we falled back to
HToolkit. I think this logic should be preserved, but slightly
corrected: fall back to HeadlessToolkit (with CToolkit
Artem is correct. On Mac we can't start a GUI session via ssh, for
example. Thus we choose the headless mode then. The isInAquaSession() is
supposed to perform exactly this check. This logic needs to be preserved.
--
best regards,
Anthony
On 10/22/2013 01:23 PM, Artem Ananiev wrote:
Hi,
Changeset: b121e84392fa
Author:erikj
Date: 2013-10-22 11:59 +0200
URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b121e84392fa
8026966: Most native libs broken on mac in jdk8/build
Reviewed-by: ihse, anthony
! makefiles/lib/PlatformLibraries.gmk
Looks good.
/Erik
On 2013-10-18 14:29, Magnus Ihse Bursie wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8026864
The --disable-macosx-runtime-support configure option is supposed to
stop AWT from using the framework and use X11 instead. This does not
work. Also, even if the option is
Changeset: 56db38956113
Author:ihse
Date: 2013-10-22 12:29 +0200
URL: http://hg.openjdk.java.net/jdk8/build/rev/56db38956113
8026864: Deprecate --disable-macosx-runtime-support.
Reviewed-by: erikj
! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh
!
Changeset: dffe654ab24c
Author:ihse
Date: 2013-10-22 11:12 +0200
URL: http://hg.openjdk.java.net/jdk8/build/rev/dffe654ab24c
8001925: Add useful help messages if freetype is not found on Windows
Reviewed-by: erikj, tbell
! common/autoconf/generated-configure.sh
!
This patch removes the last reference to OPENWIN on linux. All other
libs were already converted to using X_LIBS and X_CFLAGS instead of
OPENWIN_HOME on linux, but libsplashscreen was still using OPENWIN. I
also removed the logic in configure that probed for it.
Bug:
Hi Erik:
This patch removes the last reference to OPENWIN on linux. All other
libs were already converted to using X_LIBS and X_CFLAGS instead of
OPENWIN_HOME on linux, but libsplashscreen was still using OPENWIN. I
also removed the logic in configure that probed for it.
Bug:
Trying this again. Here is a new webrev against jdk8/build. Again, this
solves the issue detailed by Alan in this bug.
http://cr.openjdk.java.net/~erikj/8009280/webrev.04/
There will probably be more issues in JDK-8006350 [build] JCE unusable
using new build environment, but at least this
Oops, you're right, it definitely crashes. I'll put that code back and take
Artem's suggestion.
-DrD-
Artem is correct. On Mac we can't start a GUI session via ssh, for example.
Thus we choose the headless mode then. The isInAquaSession() is supposed to
perform exactly this check. This
Looks good.
/Magnus
22 okt 2013 kl. 15:28 skrev Erik Joelsson erik.joels...@oracle.com:
This patch removes the last reference to OPENWIN on linux. All other libs
were already converted to using X_LIBS and X_CFLAGS instead of OPENWIN_HOME
on linux, but libsplashscreen was still using
There was a discussion why we use HToolkit instead of HeadlessToolkit:
http://mail.openjdk.java.net/pipermail/awt-dev/2012-July/003114.html
So we might want to continue using it.
Also, please be aware that there is HToolkit check in
GraphicsToolkit.getHeadlessProperty()
On Oct 22, 2013, at
All -
We are not building 32-bit Solaris any longer in JDK 8. (The main bug
number for that was JDK-8023288 Remove Solaris 32-bit from JDK8).
8027039 is a cleanup task for removing 32-bit Solaris from the following
files:
./corba/make/jprt.properties
./jdk/make/jprt.properties
There seem to have been some kind of merge error (?) at the end of
CompileJavaClasses.gmk; the all target is duplicated three times with
variations.
Apart from this, it looks good from a build perspective.
/Magnus
22 okt 2013 kl. 16:52 skrev Erik Joelsson erik.joels...@oracle.com:
Trying
Hi Erik,
I havn't tested this until now, but from a first look it seems a
little weird to me that you still use $(OPENWIN_HOME) in
Awt2dLibraries.gmk:
LIBSPLASHSCREEN_CFLAGS += -DWITH_X11 $(X_CFLAGS)
-I$(OPENWIN_HOME)/include/X11/extensions
especially after you've removed the logic that probed
OPENWIN_HOME is used only on Solaris, where it is still defined. This patch
removes it from all other platforms.
/Magnus
22 okt 2013 kl. 19:04 skrev Volker Simonis volker.simo...@gmail.com:
Hi Erik,
I havn't tested this until now, but from a first look it seems a
little weird to me that
We don't have to. IIRC, the choice of HToolkit on Mac was made by chance.
Since we must load the lwawt lib in headless on Mac anyway, we may as
well use the CToolkit (properly wrapped in the HeadlessToolkit). But
there's no need to continue to use the HToolkit on Mac.
--
best regards,
The SCTP native code complies with -Werror. gcc 4.8.1 reports unused
parameters as warnings, and this causes the build to fail. gcc 4.8.1 is
the defaul on Ubuntu 13.10.
These parameters are required as the functions are JNI functions. The
simplest solution is to ignore/suppress these unused
Looks correct to me. (not a build project Reviewer)
Mike
On Oct 22 2013, at 09:36 , Tim Bell tim.b...@oracle.com wrote:
All -
We are not building 32-bit Solaris any longer in JDK 8. (The main bug number
for that was JDK-8023288 Remove Solaris 32-bit from JDK8).
8027039 is a cleanup
On 10/22/13 9:36 AM, Tim Bell wrote:
All -
We are not building 32-bit Solaris any longer in JDK 8. (The main bug
number for that was JDK-8023288 Remove Solaris 32-bit from JDK8).
8027039 is a cleanup task for removing 32-bit Solaris from the
following files:
This is the same change I am using locally. It wasn't clear why the SCTP
handling of errors was different than the rest of the libs.
Mike
On Oct 22 2013, at 11:44 , Chris Hegarty chris.hega...@oracle.com wrote:
The SCTP native code complies with -Werror. gcc 4.8.1 reports unused
parameters
I was also stuck in this build issue when working with the new gcc in
Ubuntu. Thanks for fixing the issue, Chris.
The change looks good to me.
-Dan
On 10/22/2013 11:44 AM, Chris Hegarty wrote:
The SCTP native code complies with -Werror. gcc 4.8.1 reports unused
parameters as warnings, and
On 22 Oct 2013, at 20:19, Mike Duigou mike.dui...@oracle.com wrote:
This is the same change I am using locally. It wasn't clear why the SCTP
handling of errors was different than the rest of the libs.
The SCTP native code is clean enough to enable Werror, not sure if others areas
are but
On 2013-10-22 19:54, Volker Simonis wrote:
Well, I don't think so. As far as I can see it is used for everything
which is not Windows and not Solaris in Awt2dLibraries.gmk:
+ else ifeq ($(OPENJDK_TARGET_OS), solaris)
LIBSPLASHSCREEN_CFLAGS += -DWITH_X11 -I$(OPENWIN_HOME)/include
On 2013-10-22 20:44, Chris Hegarty wrote:
The SCTP native code complies with -Werror. gcc 4.8.1 reports unused
parameters as warnings, and this causes the build to fail. gcc 4.8.1
is the defaul on Ubuntu 13.10.
An alternative solution is to keep the warning but fix the code.
The traditional
Changeset: 4d23143c676a
Author:lana
Date: 2013-10-10 08:49 -0700
URL: http://hg.openjdk.java.net/jdk8/build/rev/4d23143c676a
Merge
Changeset: fd3b32cc4b6e
Author:lana
Date: 2013-10-10 21:22 -0700
URL: http://hg.openjdk.java.net/jdk8/build/rev/fd3b32cc4b6e
Merge
Changeset: 81d694b1ab2f
Author:msheppar
Date: 2013-06-14 16:31 +0100
URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/81d694b1ab2f
8011157: Improve CORBA portablility
Summary: fix also reviewed by Alexander Fomin
Reviewed-by: alanb, coffeys, skoivu
!
Please review this simple fix, addressing a problem with yesterday's
integration of JDK-8026528.
NewMakefile.gmk was extended to recognize version 4 of make, but in the
process restricted older usage to exactly 3.81 3.82, which means
something like 3.82.90 is now flagged as too low.
Both
Changeset: 5c599c419c1d
Author:hseigel
Date: 2013-07-11 12:59 -0400
URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5c599c419c1d
8016256: Make finalization final
Summary: Add private methods to final methods check
Reviewed-by: coleenp, acorn, ahgross
Contributed-by:
On 2013-10-23 00:14, David Katleman wrote:
Please review this simple fix, addressing a problem with yesterday's
integration of JDK-8026528.
NewMakefile.gmk was extended to recognize version 4 of make, but in
the process restricted older usage to exactly 3.81 3.82, which means
something like
Looks good to me also.
Brad
On 10/22/2013 3:19 PM, Magnus Ihse Bursie wrote:
On 2013-10-23 00:14, David Katleman wrote:
Please review this simple fix, addressing a problem with yesterday's
integration of JDK-8026528.
NewMakefile.gmk was extended to recognize version 4 of make, but in
the
Hi Dave
On 10/22/13 03:19 PM, Magnus Ihse Bursie wrote:
On 2013-10-23 00:14, David Katleman wrote:
Please review this simple fix, addressing a problem with yesterday's
integration of JDK-8026528.
NewMakefile.gmk was extended to recognize version 4 of make, but in
the process restricted
On 10/22/2013 7:52 AM, Erik Joelsson wrote:
Trying this again. Here is a new webrev against jdk8/build. Again, this
solves the issue detailed by Alan in this bug.
http://cr.openjdk.java.net/~erikj/8009280/webrev.04/
There will probably be more issues in JDK-8006350 [build] JCE unusable
using
Thanks to Magnus, Brad, and Tim for the reviews.
That should be enough.
Dave
On 10/22/2013 3:14 PM, David Katleman wrote:
Please review this simple fix, addressing a problem with yesterday's
integration of JDK-8026528.
NewMakefile.gmk was extended to recognize version 4 of make, but
Changeset: 4293401d683b
Author:katleman
Date: 2013-10-22 16:35 -0700
URL: http://hg.openjdk.java.net/jdk8/build/rev/4293401d683b
8027068: Update to NewMakefile.gmk check of MAKE_VERSION broke jdk8-build
nightly builds on windows, saying 3.82.90 is too low
Reviewed-by: ihse, tbell,
Changeset: 269497597620
Author:tbell
Date: 2013-10-22 16:28 -0700
URL: http://hg.openjdk.java.net/jdk8/build/rev/269497597620
8027039: [jprt] Remove 32-bit Solaris from jprt.properties files
Reviewed-by: mduigou, mchung
! make/jprt.properties
Changeset: 2cc1a52d37ef
Author:
Changeset: da77e343f458
Author:lana
Date: 2013-10-10 10:03 -0700
URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/da77e343f458
Merge
Changeset: 66a12ce67d3a
Author:lana
Date: 2013-10-10 21:22 -0700
URL:
Changeset: a259ff3e42d9
Author:tbell
Date: 2013-10-22 16:29 -0700
URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/a259ff3e42d9
8027039: [jprt] Remove 32-bit Solaris from jprt.properties files
Reviewed-by: mduigou, mchung
! make/jprt.properties
Changeset: 0046d2278204
Author:tbell
Date: 2013-10-22 16:29 -0700
URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/0046d2278204
8027039: [jprt] Remove 32-bit Solaris from jprt.properties files
Reviewed-by: mduigou, mchung
! make/jprt.properties
Changeset: 127c2e74d2cf
Author:tbell
Date: 2013-10-22 16:30 -0700
URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/127c2e74d2cf
8027039: [jprt] Remove 32-bit Solaris from jprt.properties files
Reviewed-by: mduigou, mchung
! make/jprt.properties
Changeset: 9261f342aa73
Author:tbell
Date: 2013-10-22 16:29 -0700
URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/9261f342aa73
8027039: [jprt] Remove 32-bit Solaris from jprt.properties files
Reviewed-by: mduigou, mchung
! make/jprt.properties
Changeset: 698937f18761
Author:tbell
Date: 2013-10-22 16:29 -0700
URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/698937f18761
8027039: [jprt] Remove 32-bit Solaris from jprt.properties files
Reviewed-by: mduigou, mchung
! make/jprt.properties
! makefiles/jprt.properties
Changeset: 8d29733ad609
Author:sundar
Date: 2013-10-09 10:47 +0200
URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/8d29733ad609
8026112: Function(with(x ? 1e81 : (x2.constructor = 0.1)){}) throws
AssertionError: double is not compatible with object
Reviewed-by: lagergren,
On 23/10/2013 8:14 AM, David Katleman wrote:
Please review this simple fix, addressing a problem with yesterday's
integration of JDK-8026528.
NewMakefile.gmk was extended to recognize version 4 of make, but in the
process restricted older usage to exactly 3.81 3.82, which means
something like
On 10/22/2013 7:00 PM, David Holmes wrote:
On 23/10/2013 8:14 AM, David Katleman wrote:
Please review this simple fix, addressing a problem with yesterday's
integration of JDK-8026528.
NewMakefile.gmk was extended to recognize version 4 of make, but in the
process restricted older usage to
Updated webrev:
http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/
Summary of changes since last:
- Added awt_headless to java_props_t (set to NULL by default which does not set
the property)
- Replaced the toolkit selection code in java_props_macosx.[ch]. I could have
just exposed
On 23/10/2013 2:10 PM, David DeHaven wrote:
Updated webrev:
http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/
Summary of changes since last:
- Added awt_headless to java_props_t (set to NULL by default which does not set
the property)
Not sure about this part. We already force this
51 matches
Mail list logo
