I've been using this patch while debugging other issues and I now get full
symbols in the debugger without a lot of manual work. So it's a go!
Thanks,
/Staffan
On 11 okt 2013, at 22:27, Daniel D. Daugherty
wrote:
> Greetings,
>
> I'm ready for code review round 1 of the FDS on MacOS X hotspo
On 15/10/2013 1:18 AM, Daniel D. Daugherty wrote:
Thanks for the re-review!
On 10/13/13 7:57 PM, David Holmes wrote:
Hi Dan,
Only further comment I have, and it may well be deferred for future
work, is that we should be able to abstract away the actual
"extension" used for the "debuginfo" fil
On 15/10/2013 1:52 AM, Daniel D. Daugherty wrote:
On 10/14/13 9:18 AM, Daniel D. Daugherty wrote:
On 10/13/13 7:57 PM, David Holmes wrote:
Hmm second comment - I don't see a .m4 file change that corresponds
to the DSYMUTIL configure change ??
Yikes! I'll check into that shortly. Not sure wha
On 10/14/2013 6:39 AM, Alan Bateman wrote:
This is an update to the BuildMetaIndex tool, the tool used in the
build to generate the meta-index file.
The problem is that the tool assumes that there are at least two
levels of package in the name of each type. This causes a problem for
jdk.Exp
Looks good to me as well..
/Tim
On 10/14/13 01:17 AM, Erik Joelsson wrote:
I'm in favor of this change and it looks good to me.
/Erik
On 2013-10-14 10:07, Magnus Ihse Bursie wrote:
On 2013-10-11 20:18, Magnus Ihse Bursie wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8001933
In the
Changeset: cf3ee0e2c1a5
Author:erikj
Date: 2013-10-14 11:36 +0200
URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/cf3ee0e2c1a5
8025612: rt.jar still has old specification value in the manifest
Reviewed-by: alanb, dholmes, tbell, wetmore
! make/tools/manifest.mf
Changeset: 6274d4cd22d3
Author:erikj
Date: 2013-10-14 11:54 +0200
URL: http://hg.openjdk.java.net/jdk8/build/rev/6274d4cd22d3
8025921: Make LOG=debug output more readable
Reviewed-by: tbell, ihse
! common/makefiles/JavaCompilation.gmk
! common/makefiles/MakeBase.gmk
On Oct 11 2013, at 18:03 , Weijun Wang wrote:
> The webrev shows """ inside the "Bug id" header entry.
I have fixed this. It was being double escaped. ie. "
Updated webrev:
http://cr.openjdk.java.net/~mduigou/JDK-8026062/2
>
> Also, the following headers look a little suspicious:
>
>
On 10/14/13 9:18 AM, Daniel D. Daugherty wrote:
On 10/13/13 7:57 PM, David Holmes wrote:
Hmm second comment - I don't see a .m4 file change that corresponds
to the DSYMUTIL configure change ??
Yikes! I'll check into that shortly. Not sure what happened here.
I somehow missed/lost two 1-line
Thanks for the re-review!
On 10/13/13 7:57 PM, David Holmes wrote:
Hi Dan,
Only further comment I have, and it may well be deferred for future
work, is that we should be able to abstract away the actual
"extension" used for the "debuginfo" file so that we don't need macosx
conditionals as m
The changes look right to me, and prudent given where we are with jdk8.
It suspect that this would have gone unnoticed forever, if you were not
to add this type.
-Chris.
On 14/10/2013 14:39, Alan Bateman wrote:
This is an update to the BuildMetaIndex tool, the tool used in the build
to gene
This is an update to the BuildMetaIndex tool, the tool used in the build
to generate the meta-index file.
The problem is that the tool assumes that there are at least two levels
of package in the name of each type. This causes a problem for
jdk.Exported, the annotation that was added as part
Bumping this review. I'm pretty sure it fixes the problem reported in
this particular bug. There is another bug to track all of the problems
the JCE team has with the new build.
/Erik
On 2013-08-16 17:09, Tim Bell wrote:
Erik:
Woops, as some of you pointed out, I missed adding the link to th
Looks good! Of course, the proof is in building it.
I can sponsor the hotspot fix.
Thanks,
/Staffan
On 14 okt 2013, at 11:25, Erik Joelsson wrote:
> Please review the following changes, correcting the conditions for when to
> build certain parts of the servicability features. Instead of guard
Please review the following changes, correcting the conditions for when
to build certain parts of the servicability features. Instead of
guarding them with the OPENJDK variable, they need to be conditioned on
the existence of the source itself.
In hotspot, this only fails on Windows. The linux
Hi,
On 10/14/2013 09:58 AM, Francis ANDRE wrote:
Hi
Just cloning this repository http://hg.openjdk.java.net/jdk7u/jdk7u to a
fresh new directory on a WXP/Cygwin platform with the following ALT_*
variables
$ env | grep ALT
ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_40
ALT_SLASH_JAVA=C:/Progra~1/Java
Erik,
Thank you!
-Dmitry
On 2013-10-14 11:50, Erik Joelsson wrote:
> I have seen this before and filed this bug. It's currently the main
> stopper for making sjavac default.
>
> https://bugs.openjdk.java.net/browse/JDK-8025702
>
> /Erik
>
> On 2013-10-11 23:00, Dmitry Samersoff wrote:
>> Brad
I'm in favor of this change and it looks good to me.
/Erik
On 2013-10-14 10:07, Magnus Ihse Bursie wrote:
On 2013-10-11 20:18, Magnus Ihse Bursie wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8001933
In the makefiles directory in the jdk repo, there are a lot of files
-- important fil
On 2013-10-11 20:18, Magnus Ihse Bursie wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8001933
In the makefiles directory in the jdk repo, there are a lot of files
-- important files, and lot of small helper files. Many of them share
a common filename prefix; however, there is a better k
I have seen this before and filed this bug. It's currently the main
stopper for making sjavac default.
https://bugs.openjdk.java.net/browse/JDK-8025702
/Erik
On 2013-10-11 23:00, Dmitry Samersoff wrote:
Brad,
Thank you for greet idea. sjavac might be a culprit.
-Dmitry
On 2013-10-11 22:23
On 2013-10-11 20:14, Bradford Wetmore wrote:
As the submitter, I also agree with this part of the fix and all
comments made here. ;)
Erik, one thing I did not check is whether other .jars in j2re/j2sdk
use a different manifest template than the one you modified. Have you
checked them all?
21 matches
Mail list logo