Hi Erik,
On 4/08/2016 1:04 AM, Erik Joelsson wrote:
Hello,
The current --disable-headful option is weird. Even worse, it doesn't
work since the makefiles still uses the legacy BUILD_HEADLESS_ONLY
variable, which configure never touches.
The confusion around that variable due to its legacy alw
Erik,
David is already cleaning up the jawt.c file here :-
http://cr.openjdk.java.net/~dholmes/8140723/webrev.jdk/src/java.desktop/unix/native/libjawt/jawt.c.sdiff.html
Not sure who should win :-)
-phil.
On 8/3/16, 8:04 AM, Erik Joelsson wrote:
Hello,
The current --disable-headful option is
Erik:
When making changes to this file:
langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
The incremental build fails to recognize the change and rebuild
properly. The problem is a missing $ in a macro definition. I have
verified this fix with the
Erik:
When building using a special Oracle internal tool, the value of the
JMOD_CMD variable has an environment variable assignment added to it
(SOMETHING_FOO=foo /path/to/jmod). This causes the build to break in
jmod creation, because the value of JMOD_CMD is used as a prerequisite
in a rule
Erik:
When building for 32bit with (at least) Visual Studio 2010, configure
may fail to run with the error:
configure: error: Target CPU mismatch. We are building for x86 but CL
is for "directory"; expected "80x86" or "x86"
This is caused by cl.exe failing to load mspdb100.dll, which in tur
Erik:
The current --disable-headful option is weird. Even worse, it doesn't
work since the makefiles still uses the legacy BUILD_HEADLESS_ONLY
variable, which configure never touches.
In this patch I'm replacing the configure option with
--enable-headless-only. Default is disabled, where bot
Hello,
When making changes to this file:
langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
The incremental build fails to recognize the change and rebuild
properly. The problem is a missing $ in a macro definition. I have
verified this fix with the rep
Erik:
On 08/03/16 02:17, David Holmes wrote:
On 3/08/2016 7:11 PM, Erik Joelsson wrote:
New webrev: http://cr.openjdk.java.net/~erikj/8162354/webrev.02/
I found that the first working update was 8u20 and changed to use that
instead for minimal impact.
Seems reasonable. :)
Thanks,
David
Lo
Hello,
The current --disable-headful option is weird. Even worse, it doesn't
work since the makefiles still uses the legacy BUILD_HEADLESS_ONLY
variable, which configure never touches.
In this patch I'm replacing the configure option with
--enable-headless-only. Default is disabled, where bo
When building using a special Oracle internal tool, the value of the
JMOD_CMD variable has an environment variable assignment added to it
(SOMETHING_FOO=foo /path/to/jmod). This causes the build to break in
jmod creation, because the value of JMOD_CMD is used as a prerequisite
in a rule declara
The build changes look good to me now.
I can't comment on the implications for the generated docs. Any idea
of why these particular docs were generated in such a special way?
I really don't know, other than speculate, I back tracked to JDK6, and
it seems to be generated this way, in the old
Maybe, but the problem is that we don't know what the next chip name
will be. The last generation was T5, so the letter may also change. I
think it's safer to go with what we know at this point.
/Erik
On 2016-08-03 13:26, Seán Coffey wrote:
One suggestion to future proof your fix might be to
One suggestion to future proof your fix might be to pattern match
against any CPU of M7 of greater perhaps. Something like SPARC-M[7+]
perhaps.
Regards,
Sean.
On 03/08/16 11:47, Erik Joelsson wrote:
Followup on this. I did a compare build on Solaris with 8GA and 8u20.
There is a slight differ
Followup on this. I did a compare build on Solaris with 8GA and 8u20.
There is a slight difference for these class files:
/jdk.compiler/com/sun/tools/javac/resources/CompilerProperties$Errors.class
/jdk.compiler/com/sun/tools/javac/resources/CompilerProperties$Fragments.class
/jdk.compiler/com/s
Hello,
When building for 32bit with (at least) Visual Studio 2010, configure
may fail to run with the error:
configure: error: Target CPU mismatch. We are building for x86 but CL is
for "directory"; expected "80x86" or "x86"
This is caused by cl.exe failing to load mspdb100.dll, which in tu
On 3/08/2016 7:11 PM, Erik Joelsson wrote:
New webrev: http://cr.openjdk.java.net/~erikj/8162354/webrev.02/
I found that the first working update was 8u20 and changed to use that
instead for minimal impact.
Seems reasonable. :)
Thanks,
David
/Erik
On 2016-08-03 09:08, Erik Joelsson wrote:
New webrev: http://cr.openjdk.java.net/~erikj/8162354/webrev.02/
I found that the first working update was 8u20 and changed to use that
instead for minimal impact.
/Erik
On 2016-08-03 09:08, Erik Joelsson wrote:
On 2016-08-03 04:20, David Holmes wrote:
Hi Erik,
On 3/08/2016 1:11 AM, Erik
The build changes look good to me now.
I can't comment on the implications for the generated docs. Any idea of
why these particular docs were generated in such a special way?
/Erik
On 2016-08-02 22:25, Kumar Srinivasan wrote:
Hello Erik,
Ok I fixed the items you pointed out, also in my las
On 2016-08-03 04:20, David Holmes wrote:
Hi Erik,
On 3/08/2016 1:11 AM, Erik Joelsson wrote:
Hello,
The default bootjdk for 9 is JDK 8. Unfortunately JDK 8 does not work on
newer M7 sparc hardware. This has of course been fixed in an update.
This patch changes the Jib profile configuration t
19 matches
Mail list logo
