On 2016-01-28 06:49, David Holmes wrote:
On 28/01/2016 8:40 AM, Magnus Ihse Bursie wrote:
A merge error occured in changeset 8b46c6cecc37 in the file hotspot.m4.
Very odd given the file was brand new prior to the merge.
I split out half the contents of the jdk-options.m4 into the new file
h
On 28/01/2016 8:40 AM, Magnus Ihse Bursie wrote:
A merge error occured in changeset 8b46c6cecc37 in the file hotspot.m4.
Very odd given the file was brand new prior to the merge.
Bug: https://bugs.openjdk.java.net/browse/JDK-8148416
Patch inline:
diff --git a/common/autoconf/hotspot.m4 b/com
A merge error occured in changeset 8b46c6cecc37 in the file hotspot.m4.
Bug: https://bugs.openjdk.java.net/browse/JDK-8148416
Patch inline:
diff --git a/common/autoconf/hotspot.m4 b/common/autoconf/hotspot.m4
--- a/common/autoconf/hotspot.m4
+++ b/common/autoconf/hotspot.m4
@@ -266,14 +266,3 @@
On 2016-01-27 17:54, Jiri Vanek wrote:
On 01/27/2016 11:09 AM, Magnus Ihse Bursie wrote:
On 2016-01-25 21:38, Andrew Hughes wrote:
- Original Message -
Hello!
When compiler is wrapped, the configure phase of build fails:
[...]
checking for gcc... /usr/lib64/cscppc/gcc
configure: Reso
On 2016-01-27 19:37, Bob Vandette wrote:
Here’s the updated webrev with updates based on your feedback.
http://cr.openjdk.java.net/~bobv/8148302/webrev.01
I implemented all of the changes suggested.
For the X11 issue, I removed my changes and replaced BUILD_HEADLESS_ONLY with
SUPPORT_HEADFUL.
On 2016-01-27 17:15, Bob Vandette wrote:
On Jan 27, 2016, at 4:56 AM, Magnus Ihse Bursie
wrote:
On 2016-01-26 20:50, Bob Vandette wrote:
Please review the changes for two improvements for the Mobile Dev Forest.
With these changes, the mobile/dev forest can successfully build x86 and ARM
And
I think it quite reasonable to push everything to jdk9/dev.
Paul.
> On 27 Jan 2016, at 14:55, Aleksey Shipilev
> wrote:
>
> Hi again,
>
> This is a formal pre-integration review thread for JEP 280 ("Indify
> String Concatenation") integration:
> http://openjdk.java.net/jeps/280
>
> The JEP
Hi Magnus,
I am just an observer here but good work. I have been on this list for a
long time because of my interest in MacOSX and that port so I naturally
thought that BSD would become part of mainline Java too. More platforms for
Java is better. Because of your work I took a look at BSD and the
Here’s the updated webrev with updates based on your feedback.
http://cr.openjdk.java.net/~bobv/8148302/webrev.01
I implemented all of the changes suggested.
For the X11 issue, I removed my changes and replaced BUILD_HEADLESS_ONLY with
SUPPORT_HEADFUL. This allows a headless only build to be f
- Original Message -
> On 2016-01-25 21:38, Andrew Hughes wrote:
> > - Original Message -
> >> Hello!
> >>
> >> When compiler is wrapped, the configure phase of build fails:
> >>
> >> [...]
> >> checking for gcc... /usr/lib64/cscppc/gcc
> >> configure: Resolving CC (as /usr/lib64/cs
On 01/27/2016 11:09 AM, Magnus Ihse Bursie wrote:
On 2016-01-25 21:38, Andrew Hughes wrote:
- Original Message -
Hello!
When compiler is wrapped, the configure phase of build fails:
[...]
checking for gcc... /usr/lib64/cscppc/gcc
configure: Resolving CC (as /usr/lib64/cscppc/gcc) fail
JDK changes looks good!
Best regards,
Vladimir Ivanov
On 1/27/16 4:55 PM, Aleksey Shipilev wrote:
Hi again,
This is a formal pre-integration review thread for JEP 280 ("Indify
String Concatenation") integration:
http://openjdk.java.net/jeps/280
The JEP is Targeted, the CCC is approved, th
> On Jan 27, 2016, at 4:56 AM, Magnus Ihse Bursie
> wrote:
>
> On 2016-01-26 20:50, Bob Vandette wrote:
>> Please review the changes for two improvements for the Mobile Dev Forest.
>>
>> With these changes, the mobile/dev forest can successfully build x86 and ARM
>> Android
>> JDK 9 binaries.
On 01/27/2016 05:07 PM, Magnus Ihse Bursie wrote:
> On 2016-01-27 14:55, Aleksey Shipilev wrote:
>> c) (XS) Build changes that force emitting the "legacy" inline
>> StringBuilder concat in a few cases (e.g. when pre-JDK 9 bytecode is
>> expected):
>> http://cr.openjdk.java.net/~shade/8085796/
>
> Just out of curiosity, what does "indy" mean in this context? I have not
> heard this expression and googling fails to bring up anything relevant.
>
At first I thought it's Russian, but then -- invokedynamic.
--Max
On 2016-01-27 14:55, Aleksey Shipilev wrote:
Hi again,
This is a formal pre-integration review thread for JEP 280 ("Indify
String Concatenation") integration:
http://openjdk.java.net/jeps/280
The JEP is Targeted, the CCC is approved, the code reviews and
pre-integration checks are clean.
C
On 2016-01-27 13:42, Gary Adams wrote:
When the sync with jdk9 b102 was pulled into mobile/dev repos a new
feature for thread local storage was over looked. Most modern compilers
include support for thread local declaration, but this feature is
intentionally
not supported by Apple's clang compi
Hi again,
This is a formal pre-integration review thread for JEP 280 ("Indify
String Concatenation") integration:
http://openjdk.java.net/jeps/280
The JEP is Targeted, the CCC is approved, the code reviews and
pre-integration checks are clean.
Code changes are happening simultaneously in four
Approved,
Bertrand.
On 27/01/2016 13:42, Gary Adams wrote:
When the sync with jdk9 b102 was pulled into mobile/dev repos a new
feature for thread local storage was over looked. Most modern compilers
include support for thread local declaration, but this feature is
intentionally
not supported by
When the sync with jdk9 b102 was pulled into mobile/dev repos a new
feature for thread local storage was over looked. Most modern compilers
include support for thread local declaration, but this feature is
intentionally
not supported by Apple's clang compiler.
This change declares USE_LIBRARY_B
During toolchain detection, if the found compiler (CC or CXX) is a
symbolic link, we resolve it and point to the resolved binary. This was
introduced to be able to debug systems with a broken setup, but it
breaks use cases were a CC wrapper is used.
A better solution is to just print the path
On 2016-01-25 21:38, Andrew Hughes wrote:
- Original Message -
Hello!
When compiler is wrapped, the configure phase of build fails:
[...]
checking for gcc... /usr/lib64/cscppc/gcc
configure: Resolving CC (as /usr/lib64/cscppc/gcc) failed, using
/usr/lib64/cscppc/gcc directly.
checking
On 2016-01-26 20:50, Bob Vandette wrote:
Please review the changes for two improvements for the Mobile Dev Forest.
With these changes, the mobile/dev forest can successfully build x86 and ARM
Android
JDK 9 binaries. The ARM binaries use the Zero ARM interpreter while the x86
implementation us
23 matches
Mail list logo
