On 09/27/2017 09:57 PM, John Paul Adrian Glaubitz wrote:> On 09/27/2017 08:51
PM, Kim Barrett wrote:
Looks good.
Please update the copyright in oopMap.cpp.
Done [1].
Just a second, please. I just ran into build errors.
Please don't merge as is.
Adrian
--
.''`. John Paul Adrian Glaubitz
Hi Kim!
On 09/27/2017 08:51 PM, Kim Barrett wrote:
Looks good.
Please update the copyright in oopMap.cpp.
Done [1].
Adrian
[1] http://cr.openjdk.java.net/~glaubitz/8186578/webrev.03/
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Univers
Build change looks good.
/Magnus
On 2017-09-27 18:40, John Paul Adrian Glaubitz wrote:
Hello!
Zero currently fails to build on linux-sparc since there are two
instances where
SPARC-specific defines conflict with the Zero code.
One instance is src/hotspot/share/compiler/oopMap.cpp where a he
> On Sep 27, 2017, at 12:40 PM, John Paul Adrian Glaubitz
> wrote:
>
> Hello!
>
> Zero currently fails to build on linux-sparc since there are two instances
> where
> SPARC-specific defines conflict with the Zero code.
>
> […]
> The webrev to fix the Zero build on SPARC includes both changes
On 27/09/17 17:47, John Paul Adrian Glaubitz wrote:
> On 09/27/2017 06:46 PM, Andrew Haley wrote:
>> On 27/09/17 17:40, John Paul Adrian Glaubitz wrote:
>>> The webrev to fix the Zero build on SPARC includes both changes and can be
>>> found
>>> in [1].
>>
>> That looks right, but I think the rele
On 09/27/2017 06:46 PM, Andrew Haley wrote:
On 27/09/17 17:40, John Paul Adrian Glaubitz wrote:
The webrev to fix the Zero build on SPARC includes both changes and can be found
in [1].
That looks right, but I think the release JDK 9 is done. We'll have
to stage the fix for the JDK 9 updates p
On 27/09/17 17:40, John Paul Adrian Glaubitz wrote:
> The webrev to fix the Zero build on SPARC includes both changes and can be
> found
> in [1].
That looks right, but I think the release JDK 9 is done. We'll have
to stage the fix for the JDK 9 updates project.
--
Andrew Haley
Java Platform L
Hello!
Zero currently fails to build on linux-sparc since there are two instances where
SPARC-specific defines conflict with the Zero code.
One instance is src/hotspot/share/compiler/oopMap.cpp where a header is
uncondtionally
included for SPARC which is not available for Zero. It turns out tha
Ouch, looks good.
/Erik
On 2017-09-27 15:41, Magnus Ihse Bursie wrote:
After the forest consolidation, InitSupport.gmk does not properly
include the closed file, since it's not using the normal inclusion
mechanism (due to the SPEC not being available yet).
Bug: https://bugs.openjdk.java.net
Magnus:
After the forest consolidation, InitSupport.gmk does not properly
include the closed file, since it's not using the normal inclusion
mechanism (due to the SPEC not being available yet).
Bug: https://bugs.openjdk.java.net/browse/JDK-8188034
Patch inline:
diff --git a/make/InitSupport.gmk
After the forest consolidation, InitSupport.gmk does not properly
include the closed file, since it's not using the normal inclusion
mechanism (due to the SPEC not being available yet).
Bug: https://bugs.openjdk.java.net/browse/JDK-8188034
Patch inline:
diff --git a/make/InitSupport.gmk b/make/
ah - got it
the script I use for rsyncing was excluding all stuff in build/** -
meaning that I ended up with an inconsistent spec.gmk.
Apparently, the name of this variable changed:
http://hg.openjdk.java.net/jdk10/master/rev/92fd0e04e0e1
And so my sync setup flaw was exposed.
Sorry for the
On a problematic repo I tried to compare the spec.gmk before/after the
configure run - there's a difference which seems to be causing this issue:
The buggy spec.gmk (which causes the permission issues) has this:
BUILD_OUTPUT:=/w/master/build/linux-x86_64-normal-server-release
# Colon left out t
On 27/09/2017 8:19 PM, Maurizio Cimadamore wrote:
On 27/09/17 10:51, David Holmes wrote:
On 27/09/2017 7:46 PM, Maurizio Cimadamore wrote:
Hi,
I sometimes encounter this (consolidated repo only):
$ make
/usr/bin/tee: /bin/mkdir: /build.logcannot create directory
‘/make-support’: Permission de
On 27/09/17 10:51, David Holmes wrote:
On 27/09/2017 7:46 PM, Maurizio Cimadamore wrote:
Hi,
I sometimes encounter this (consolidated repo only):
$ make
/usr/bin/tee: /bin/mkdir: /build.logcannot create directory
‘/make-support’: Permission denied: Permission denied
/usr/bin/tee: /build.lo
Looks good.
Jan
On 27.9.2017 11:29, Magnus Ihse Bursie wrote:
In
make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java,
javac gets called with a fixed command line. This includes the arguments
"-source 9 -target 9". While this was fine for jdk9, in jdk10
this result
On 27/09/2017 7:46 PM, Maurizio Cimadamore wrote:
Hi,
I sometimes encounter this (consolidated repo only):
$ make
/usr/bin/tee: /bin/mkdir: /build.logcannot create directory
‘/make-support’: Permission denied: Permission denied
/usr/bin/tee: /build.log: Permission denied
Building target 'defa
Hi,
I sometimes encounter this (consolidated repo only):
$ make
/usr/bin/tee: /bin/mkdir: /build.logcannot create directory
‘/make-support’: Permission denied: Permission denied
/usr/bin/tee: /build.log: Permission denied
Building target 'default (exploded-image)' in configuration
'linux-x86_
On 27/09/2017 7:26 PM, Magnus Ihse Bursie wrote:
On 2017-09-27 10:55, David Holmes wrote:
On 27/09/2017 6:30 PM, Magnus Ihse Bursie wrote:
The nashorn java code requires a somewhat convoluted compilation. As
a result, we use a special java compiler setup,
GENERATE_NEWBYTECODE_DEBUG. This e
On 2017-09-27 11:36, Erik Joelsson wrote:
Ah good find and I stand corrected. That relative path check does need
to change for this to continue working as before.
What I don't understand is why the chmod is needed and why it's only
done when not running from a hg repo. We don't allow executa
Ah good find and I stand corrected. That relative path check does need
to change for this to continue working as before.
What I don't understand is why the chmod is needed and why it's only
done when not running from a hg repo. We don't allow executable files in
the repository so if +x was req
Looks good to me.
/Erik
On 2017-09-27 11:29, Magnus Ihse Bursie wrote:
In
make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java,
javac gets called with a fixed command line. This includes the
arguments "-source 9 -target 9". While this was fine for
jdk9, in jdk1
In
make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java,
javac gets called with a fixed command line. This includes the arguments
"-source 9 -target 9". While this was fine for jdk9, in jdk10
this results in the following warning:
warning: [options] bootstrap cla
I did a bit of digging on this one, I found out that the permissions are
indeed changed by make - see test/TestCommon.gmk:
# Prep for output
# Change execute permissions on shared library files.
# Files in repositories should never have execute permissions, but
# there are some tests that have p
We run nasgen tool on the generated nashorn .class files to
post-process. nasgen used to run on boot JDK in the past (if I recall
right). I'm fine with current change is okay - so long as nasgen works
fine & nashorn tests run fine.
Please note that nashorn tests are run with "ant".
cd $jd
On 2017-09-27 10:55, David Holmes wrote:
On 27/09/2017 6:30 PM, Magnus Ihse Bursie wrote:
The nashorn java code requires a somewhat convoluted compilation. As
a result, we use a special java compiler setup,
GENERATE_NEWBYTECODE_DEBUG. This explicitly lists -source 9 -target
9, which generate
On 27/09/2017 6:30 PM, Magnus Ihse Bursie wrote:
The nashorn java code requires a somewhat convoluted compilation. As a
result, we use a special java compiler setup,
GENERATE_NEWBYTECODE_DEBUG. This explicitly lists -source 9 -target 9,
which generates this warning:
warning: [options] boots
Looks good.
/Erik
On 2017-09-27 10:30, Magnus Ihse Bursie wrote:
The nashorn java code requires a somewhat convoluted compilation. As a
result, we use a special java compiler setup,
GENERATE_NEWBYTECODE_DEBUG. This explicitly lists -source 9 -target 9,
which generates this warning:
warni
The nashorn java code requires a somewhat convoluted compilation. As a
result, we use a special java compiler setup,
GENERATE_NEWBYTECODE_DEBUG. This explicitly lists -source 9 -target 9,
which generates this warning:
warning: [options] bootstrap class path not set in conjunction with
-sour
29 matches
Mail list logo
