Hello,
Could you review a back-port of 7129133 to JDK 7u, please? The back-port
and the main fix integrated into jdk8 are slightly different.
bug: http://bugs.sun.com/view_bug.do?bug_id=7129133
webrev for jdk7u: http://cr.openjdk.java.net/~dmarkov/7129133/webrev.00/
jdk8 changeset: http://hg.o
Hello all;
When JDK-8006709 (http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/cff8d7768d72)
was pushed it changed the default source level for the jdk project NetBeans
projects to 1.8. This was a reasonable change since at this point there was
already a small amount of Java 8 "-source 1.8" code in
On 30 sep 2013, at 15:44, Daniel D. Daugherty
wrote:
> On 9/30/13 7:13 AM, Staffan Larsen wrote:
>> First: thanks for doing this work - it will make debugging on os x so much
>> easier!
>
> That's the plan...
>
>
>> I'm not done with the review, but here are a couple of comments so far.
>>
On 30.09.2013 20:14, Daniel D. Daugherty wrote:
On 9/30/13 10:04 AM, Vadim Pakhnushev wrote:
Ah, this error is not relevant to your changes at all, this happens
without them,
That would have been good to know up front. You had me looking all
over the place trying to figure out how I broke this
On 9/30/13 10:04 AM, Vadim Pakhnushev wrote:
Ah, this error is not relevant to your changes at all, this happens
without them,
That would have been good to know up front. You had me looking all
over the place trying to figure out how I broke this... :-)
Staffan's make error caught my eye.
Ah, this error is not relevant to your changes at all, this happens
without them, Staffan's make error caught my eye.
So your point is if these files are missing, the make won't run link
again so they are rebuilt, correct?
Thanks,
Vadim
On 30.09.2013 19:44, Daniel D. Daugherty wrote:
That's t
That's the correct name. If you drop them from the targets list, then
the make subsystem won't detect that those expected targets aren't
being built... In any case, I'm curious why this is failing on Windows
since I didn't (intentionally) change Windows code here.
These OpenJDK changes along with
No, I don't. I'm just excluding them from the targets list (not sure
what's the correct name for that).
Actual files are created using these lines:
ifeq ($(ENABLE_DEBUG_SYMBOLS), true)
ifeq ($(OPENJDK_TARGET_OS), windows)
$1_EXTRA_LDFLAGS+="-pdb:$$($1_OBJECT_DIR)/$$($1
On 9/30/13 8:12 AM, Vadim Pakhnushev wrote:
BTW, I have the same issue on windows:
make[2]: *** No rule to make target
`/cygdrive/c/Vadim/jdk8_2d/build/windows-x86-normal-server-release/jdk/bin/verify.map',
needed by `all'. Stop.
I think it can be fixed by this:
diff -r d4762f463fe0 common/
BTW, I have the same issue on windows:
make[2]: *** No rule to make target
`/cygdrive/c/Vadim/jdk8_2d/build/windows-x86-normal-server-release/jdk/bin/verify.map',
needed by `all'. Stop.
I think it can be fixed by this:
diff -r d4762f463fe0 common/makefiles/NativeCompilation.gmk
--- a/common/
On 9/30/13 7:13 AM, Staffan Larsen wrote:
First: thanks for doing this work - it will make debugging on os x so much
easier!
That's the plan...
I'm not done with the review, but here are a couple of comments so far.
I tried running with:
$ sh ./configure --with-debug-level=slowdebug --dis
First: thanks for doing this work - it will make debugging on os x so much
easier! I'm not done with the review, but here are a couple of comments so far.
I tried running with:
$ sh ./configure --with-debug-level=slowdebug --disable-zip-debug-info
$ make
which results in:
## Starting hotspot
.
Reposting an updated webrev for this:
http://cr.openjdk.java.net/~erikj/8009280/webrev.03/
From what I can tell, this changes the jdk (default) target to create a
valid jce layout. The jdk_security* tests are not failing for me. There
will likely be more issues to resolve for the JCE team, but
Erik, Joe, Robert,
Thanks for the reviews, just pushed this to TL
cheers
/Joel
On 2013-09-25 08:31, Jungwoo Ha wrote:
So now I can run make, and the next problem is on adlc.
Compiling /home/jwha/clients/jdk8_build/hotspot/src/share/vm/adlc/adlparse.cpp
rm -f ../generated/adfiles/adlparse.o
/path/../to/compiler/bin/g++ -DLINUX -D_GNU_SOURCE -DAMD64
-I/home/jwha/clients/jdk8
Looks good Staffan, thanks for fixing.
/Markus
-Original Message-
From: Staffan Larsen
Sent: den 30 september 2013 10:00
To: build-dev@openjdk.java.net build-dev; serviceability-...@openjdk.java.net
serviceability-...@openjdk.java.net
Subject: RFR: 8023492 jfr.jar gets loaded even thoug
Looks good to me. Also verified that nothing else changed in the
meta-index files.
/Erik
On 2013-09-30 09:59, Staffan Larsen wrote:
When running a program that has code in the com.oracle.* package, jfr.jar will
be loaded even if JFR is not referenced. This is because jre/lib/meta-index
says
When running a program that has code in the com.oracle.* package, jfr.jar will
be loaded even if JFR is not referenced. This is because jre/lib/meta-index
says that jfr.jar contains code for com.oracle.*. While this is true, it is a
bit too general. It would be more accurate to say that jfr.jar
18 matches
Mail list logo
