From daniel.daugherty at oracle.com Wed Aug 1 17:22:48 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 01 Aug 2012 11:22:48 -0600 Subject: Code review request for Linux DEBUG_BINARIES/FDS fix (7188168) Message-ID: <501965E8.2080209@oracle.com> Greetings, I have a fix for the following Linux specific FDS bug: 7188168 4/4 7071904 broke the DEBUG_BINARIES option on Linux Here is the URL for the webrev: http://cr.openjdk.java.net/~dcubed/fds_revamp/7188168-webrev/0/ What the fix does is reorder and slightly tweak the Makefile logic that supports the DEBUG_BINARIES make option: - when 'DEBUG_BINARIES=true' is specified, the '-g' option is added to the CFLAGS make variable and none of the other {DEBUG,FASTDEBUG,OPT}_CFLAGS variables are touched - this fix prevents doubled '-g' options and combined '-g' and '-gstabs' options - depending on the particular Linux config being built, a compilation will have a single '-g' or a single '-gstabs' or neither of those options The Linux embedded builds doesn't support FDS yet so most of those compiles fall into the "neither" bucket... Thanks, in advance, for any reviews. Dan From david.katleman at oracle.com Wed Aug 1 22:24:20 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 01 Aug 2012 22:24:20 +0000 Subject: hg: jdk8/build: Added tag jdk8-b49 for changeset c97b99424815 Message-ID: <20120801222420.B1293472F8@hg.openjdk.java.net> Changeset: 2fd67618b9a3 Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/2fd67618b9a3 Added tag jdk8-b49 for changeset c97b99424815 ! .hgtags From david.katleman at oracle.com Wed Aug 1 22:24:27 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 01 Aug 2012 22:24:27 +0000 Subject: hg: jdk8/build/corba: Added tag jdk8-b49 for changeset fe44e58a6bdb Message-ID: <20120801222429.348EC472F9@hg.openjdk.java.net> Changeset: d20d9eb9f093 Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/d20d9eb9f093 Added tag jdk8-b49 for changeset fe44e58a6bdb ! .hgtags From david.katleman at oracle.com Wed Aug 1 22:26:25 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 01 Aug 2012 22:26:25 +0000 Subject: hg: jdk8/build/hotspot: 37 new changesets Message-ID: <20120801222746.2C613472FA@hg.openjdk.java.net> Changeset: ea926f2921d6 Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ea926f2921d6 Added tag jdk8-b49 for changeset e3619706a725 ! .hgtags Changeset: 54e66510c9cd Author: amurillo Date: 2012-07-13 14:16 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/54e66510c9cd 7184050: new hotspot build - hs24-b17 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 8150fa46d2ed Author: jiangli Date: 2012-06-26 19:08 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8150fa46d2ed 7178145: Change constMethodOop::_exception_table to optionally inlined u2 table. Summary: Change constMethodOop::_exception_table to optionally inlined u2 table. Reviewed-by: bdelsart, coleenp, kamg ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java + agent/src/share/classes/sun/jvm/hotspot/oops/ExceptionTableElement.java ! agent/src/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/oops/constMethodKlass.hpp ! src/share/vm/oops/constMethodOop.cpp ! src/share/vm/oops/constMethodOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/runtime/relocator.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f0b82641fb7e Author: bdelsart Date: 2012-07-02 04:19 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f0b82641fb7e Merge ! src/share/vm/classfile/verifier.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: d68b1274b9ba Author: jiangli Date: 2012-07-05 18:47 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d68b1274b9ba 7180914: Compilation warning after: 7172967: Eliminate the constMethod's _method backpointer to the methodOop. Summary: Use read_pointer(J...) to access from 'constMethod' base in name_for_methodOop(), libjvm_db.c. Reviewed-by: kvn, coleenp ! src/os/solaris/dtrace/libjvm_db.c Changeset: 161ae369407d Author: jiangli Date: 2012-07-05 20:54 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/161ae369407d 7181632: nsk classLoad001_14 failure and CompileTheWorld crash after 7178145. Summary: Need to copy the inlined exception table to the new constMethodOop during method rewriting. Reviewed-by: coleenp, dholmes ! src/share/vm/oops/methodOop.cpp Changeset: e74da3c2b827 Author: jiangli Date: 2012-07-13 20:14 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e74da3c2b827 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 0bca41b2fa63 Author: jiangli Date: 2012-07-17 12:32 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/0bca41b2fa63 Merge Changeset: 922993931b3d Author: brutisso Date: 2012-07-11 22:47 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/922993931b3d 7178361: G1: Make sure that PrintGC and PrintGCDetails use the same timing for the GC pause Summary: Also reviewed by: vitalyd at gmail.com. Move the timing out of G1CollectorPolicy into the G1GCPhaseTimes class Reviewed-by: johnc ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp + src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp + src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: 3a431b605145 Author: jmasa Date: 2012-07-16 13:00 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3a431b605145 Merge ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp + src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: 7553d441b878 Author: jmasa Date: 2012-07-17 14:33 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7553d441b878 Merge Changeset: 6d8f36bcef55 Author: jrose Date: 2012-07-12 00:39 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6d8f36bcef55 6711908: JVM needs direct access to some annotations Summary: Add annotation extraction code to class file parser. Reviewed-by: twisti, jrose, kvn Contributed-by: michael.haupt at oracle.com ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/methodOop.hpp Changeset: ed21db7b3fda Author: kvn Date: 2012-07-13 17:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ed21db7b3fda 7123926: Some CTW test crash: !_control.contains(ctrl) Summary: Don't eliminate Integer::toString() call node during String concatenation optimization if it has several uses. Reviewed-by: twisti ! src/share/vm/opto/stringopts.cpp Changeset: 56c4f88474b3 Author: twisti Date: 2012-07-16 11:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/56c4f88474b3 7087357: JSR 292: remove obsolete code after 7085860 Reviewed-by: kvn, never ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/unsafe.cpp Changeset: 2c368ea3e844 Author: kvn Date: 2012-07-16 17:10 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/2c368ea3e844 7181494: cleanup avx and vectors code Summary: renamed mach nodes which use scalar AVX instructions, added integer vectors shuffling instructions Reviewed-by: twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/x86.ad ! src/share/vm/code/vmreg.hpp Changeset: 9c9fb30d2b3b Author: kvn Date: 2012-07-16 19:50 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9c9fb30d2b3b Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/unsafe.cpp Changeset: dd785aabe02b Author: kvn Date: 2012-07-17 11:16 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/dd785aabe02b Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/methodOop.hpp Changeset: bc3e01899804 Author: kvn Date: 2012-07-19 16:17 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/bc3e01899804 Merge Changeset: d900d95bfdb0 Author: fparain Date: 2012-07-16 04:06 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d900d95bfdb0 7183754: Test runtime/6294277/Test6294277.sh runs wrong JVM Reviewed-by: kamg, coleenp, ctornqvi ! test/runtime/6294277/SourceDebugExtension.java - test/runtime/6294277/Test6294277.sh Changeset: 149c36689fcb Author: asaha Date: 2012-07-17 22:16 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/149c36689fcb 7053586: TEST: runtime/7020373/Test7020373.sh fails on 64-bit platforms Reviewed-by: kamg ! test/runtime/7020373/Test7020373.sh Changeset: 7e5976e66c62 Author: zgu Date: 2012-07-19 09:05 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7e5976e66c62 7182543: NMT ON: Aggregate a few NMT related bugs Summary: 1) Fixed MemTrackWorker::generations_in_used() calculation 2) Ensured NMT not to leak memory recorders after shutdown 3) Used ThreadCritical to block safepoint safe threads Reviewed-by: acorn, coleenp, dholmes, kvn ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: f1f45dddb0bd Author: zgu Date: 2012-07-16 14:10 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f1f45dddb0bd 7181986: NMT ON: Assertion failure when running jdi ExpiredRequestDeletionTest Summary: Changed _query_lock to heap object from static object. Also fixed _query_lock and snapshot lock ranks, so they can participate deadlock detection. Reviewed-by: coleenp, dholmes, kvn ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: d5bc62fcfac7 Author: zgu Date: 2012-07-19 09:10 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d5bc62fcfac7 Merge ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: 04a9b3789683 Author: zgu Date: 2012-07-16 14:05 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/04a9b3789683 7181989: NMT ON: Assertion failure when NMT checks thread's native stack base address Summary: Assertion on stack base is not necessary Reviewed-by: coleenp, dholmes, kvn ! src/share/vm/services/memTracker.cpp Changeset: 58a04a45a549 Author: zgu Date: 2012-07-19 09:15 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/58a04a45a549 Merge ! src/share/vm/services/memTracker.cpp Changeset: 950ed41429e5 Author: zgu Date: 2012-07-19 06:24 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/950ed41429e5 Merge Changeset: 12fc2571a6e2 Author: coleenp Date: 2012-07-20 12:09 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/12fc2571a6e2 Merge - test/runtime/6294277/Test6294277.sh Changeset: bd54fe36b5e5 Author: amurillo Date: 2012-07-23 12:54 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/bd54fe36b5e5 Merge - test/runtime/6294277/Test6294277.sh Changeset: 15eb2b903b04 Author: amurillo Date: 2012-07-23 12:54 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/15eb2b903b04 Added tag hs24-b17 for changeset bd54fe36b5e5 ! .hgtags Changeset: aba91a731143 Author: amurillo Date: 2012-07-23 13:04 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/aba91a731143 7185775: new hotspot build - hs24-b18 Reviewed-by: jcoomes ! make/hotspot_version Changeset: fe94b4e7212b Author: asaha Date: 2012-07-23 14:28 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/fe94b4e7212b 7185550: TEST: runtime/7020373/Test7020373.sh fails because there is no test/runtime/7020373/testcase.jar Reviewed-by: coleenp ! test/runtime/7020373/Test7020373.sh + test/runtime/7020373/testcase.jar Changeset: 43541217e9f7 Author: jiangli Date: 2012-07-26 17:24 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/43541217e9f7 7187046: Crash in ClassFileParser on solaris-ia32 during RetransformClasses. Summary: Lower compiler optimization level when compiling jvmtiClassFileReconstituter.cpp as a workaround for the solaris x86 5.10 cc bug. Reviewed-by: kvn, coleenp ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make Changeset: 611e8a669a2c Author: dlong Date: 2012-07-16 15:31 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/611e8a669a2c 7147464: Java crashed while executing method with over 8k of dneg operations Summary: replace recursive method with iterative Reviewed-by: kvn, twisti Contributed-by: dean.long at oracle.com ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp Changeset: a93a6d2c9e6c Author: jiangli Date: 2012-07-24 13:16 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a93a6d2c9e6c Merge Changeset: bcd1b9d98558 Author: jiangli Date: 2012-07-26 16:55 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/bcd1b9d98558 Merge Changeset: 72e0362c3f0c Author: amurillo Date: 2012-07-27 12:08 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/72e0362c3f0c Merge ! .hgtags - test/runtime/6294277/Test6294277.sh Changeset: 58f237a9e83a Author: amurillo Date: 2012-07-27 12:08 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/58f237a9e83a Added tag hs24-b18 for changeset 72e0362c3f0c ! .hgtags From david.katleman at oracle.com Wed Aug 1 22:29:41 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 01 Aug 2012 22:29:41 +0000 Subject: hg: jdk8/build/jaxp: Added tag jdk8-b49 for changeset f81e981eca7b Message-ID: <20120801222945.981CC472FB@hg.openjdk.java.net> Changeset: 2791ec55f66b Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/2791ec55f66b Added tag jdk8-b49 for changeset f81e981eca7b ! .hgtags From david.katleman at oracle.com Wed Aug 1 22:29:52 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 01 Aug 2012 22:29:52 +0000 Subject: hg: jdk8/build/jaxws: Added tag jdk8-b49 for changeset b48865af8ac5 Message-ID: <20120801222956.1B3B8472FC@hg.openjdk.java.net> Changeset: bdab72e87b83 Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/bdab72e87b83 Added tag jdk8-b49 for changeset b48865af8ac5 ! .hgtags From david.katleman at oracle.com Wed Aug 1 22:30:09 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 01 Aug 2012 22:30:09 +0000 Subject: hg: jdk8/build/jdk: Added tag jdk8-b49 for changeset 51707c3b75c0 Message-ID: <20120801223041.B9D2E472FD@hg.openjdk.java.net> Changeset: e4bae5c53fca Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e4bae5c53fca Added tag jdk8-b49 for changeset 51707c3b75c0 ! .hgtags From david.katleman at oracle.com Wed Aug 1 22:33:06 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 01 Aug 2012 22:33:06 +0000 Subject: hg: jdk8/build/langtools: Added tag jdk8-b49 for changeset c72c164ced67 Message-ID: <20120801223310.7949F472FE@hg.openjdk.java.net> Changeset: b2d8a270f5f2 Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/b2d8a270f5f2 Added tag jdk8-b49 for changeset c72c164ced67 ! .hgtags From ahughes at redhat.com Thu Aug 2 10:18:44 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Thu, 2 Aug 2012 06:18:44 -0400 (EDT) Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <488466687.5562242.1343690667873.JavaMail.root@redhat.com> Message-ID: <440643475.7539644.1343902724375.JavaMail.root@redhat.com> ----- Original Message ----- > Hi all, > > In OpenJDK 8, some support has already been added for using the > system installation of zlib > (see the thread > http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-July/010967.html), > which is very similar to the support we've had in IcedTea for the > last five years (wow, has > it really been that long?). > > This is great news for us, as it's less work we have to do in > upstreaming the patch (though > 7 still needs to be dealt with). As is, the following webrev: > > http://cr.openjdk.java.net/~andrew/syslibs/zlib/webrev.01/ > > just fixes a few minor issues to match our existing setup, and fixes > a bug found when testing > the existing support. In detail, the webrev: > > * Replaces the hardcoded use of "-lz" with $(ZLIB_LIBS) and > $(ZLIB_CFLAGS), now set in > make_jdk_generic_profile.sh. > * Replaces "zlib.h" usage with (mainly to reduce difference, > searching '.' has no effect either way) > * Stops uLong being defined if SYSTEM_ZLIB is set, even if we're not > on Mac OS X. Without this fix, the build fails. > > Ok for the build forest? If so, can I please have a bug ID for this? > > Thanks, > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: 248BDC07 (https://keys.indymedia.org/) > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > > Any update on this? Submission to tl, rather than build, now planned, as suggested by Alan. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From daniel.daugherty at oracle.com Thu Aug 2 15:20:49 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 02 Aug 2012 09:20:49 -0600 Subject: Code review request for Linux DEBUG_BINARIES/FDS fix (7188168) In-Reply-To: <501A9615.1070808@oracle.com> References: <501965E8.2080209@oracle.com> <501A9615.1070808@oracle.com> Message-ID: <501A9AD1.307@oracle.com> Thanks Fred! Dan On 8/2/12 9:00 AM, Frederic Parain wrote: > Looks good. > > Fred > > On 8/1/2012 19:22, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a fix for the following Linux specific FDS bug: >> >> 7188168 4/4 7071904 broke the DEBUG_BINARIES option on Linux >> >> Here is the URL for the webrev: >> >> http://cr.openjdk.java.net/~dcubed/fds_revamp/7188168-webrev/0/ >> >> What the fix does is reorder and slightly tweak the Makefile logic >> that supports the DEBUG_BINARIES make option: >> >> - when 'DEBUG_BINARIES=true' is specified, the '-g' option is >> added to the CFLAGS make variable and none of the other >> {DEBUG,FASTDEBUG,OPT}_CFLAGS variables are touched >> - this fix prevents doubled '-g' options and combined '-g' and >> '-gstabs' options >> - depending on the particular Linux config being built, a >> compilation will have a single '-g' or a single '-gstabs' or >> neither of those options >> >> The Linux embedded builds doesn't support FDS yet so most of >> those compiles fall into the "neither" bucket... >> >> Thanks, in advance, for any reviews. >> >> Dan >> > From ahughes at redhat.com Thu Aug 2 15:53:18 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Thu, 2 Aug 2012 11:53:18 -0400 (EDT) Subject: Code review request for Linux DEBUG_BINARIES/FDS fix (7188168) In-Reply-To: <501965E8.2080209@oracle.com> Message-ID: <604202083.7749717.1343922798542.JavaMail.root@redhat.com> ----- Original Message ----- > Greetings, > > I have a fix for the following Linux specific FDS bug: > > 7188168 4/4 7071904 broke the DEBUG_BINARIES option on Linux > > Here is the URL for the webrev: > > http://cr.openjdk.java.net/~dcubed/fds_revamp/7188168-webrev/0/ > > What the fix does is reorder and slightly tweak the Makefile logic > that supports the DEBUG_BINARIES make option: > > - when 'DEBUG_BINARIES=true' is specified, the '-g' option is > added to the CFLAGS make variable and none of the other > {DEBUG,FASTDEBUG,OPT}_CFLAGS variables are touched > - this fix prevents doubled '-g' options and combined '-g' and > '-gstabs' options > - depending on the particular Linux config being built, a > compilation will have a single '-g' or a single '-gstabs' or > neither of those options > > The Linux embedded builds doesn't support FDS yet so most of > those compiles fall into the "neither" bucket... > > Thanks, in advance, for any reviews. > > Dan > > Looks good to me. Makes it much clearer than the early version that DEBUG_BINARIES effectively overrides everything else. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From daniel.daugherty at oracle.com Thu Aug 2 16:02:21 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 02 Aug 2012 10:02:21 -0600 Subject: Code review request for Linux DEBUG_BINARIES/FDS fix (7188168) In-Reply-To: <604202083.7749717.1343922798542.JavaMail.root@redhat.com> References: <604202083.7749717.1343922798542.JavaMail.root@redhat.com> Message-ID: <501AA48D.4060207@oracle.com> Thanks Andrew! Dan On 8/2/12 9:53 AM, Andrew Hughes wrote: > > ----- Original Message ----- >> Greetings, >> >> I have a fix for the following Linux specific FDS bug: >> >> 7188168 4/4 7071904 broke the DEBUG_BINARIES option on Linux >> >> Here is the URL for the webrev: >> >> http://cr.openjdk.java.net/~dcubed/fds_revamp/7188168-webrev/0/ >> >> What the fix does is reorder and slightly tweak the Makefile logic >> that supports the DEBUG_BINARIES make option: >> >> - when 'DEBUG_BINARIES=true' is specified, the '-g' option is >> added to the CFLAGS make variable and none of the other >> {DEBUG,FASTDEBUG,OPT}_CFLAGS variables are touched >> - this fix prevents doubled '-g' options and combined '-g' and >> '-gstabs' options >> - depending on the particular Linux config being built, a >> compilation will have a single '-g' or a single '-gstabs' or >> neither of those options >> >> The Linux embedded builds doesn't support FDS yet so most of >> those compiles fall into the "neither" bucket... >> >> Thanks, in advance, for any reviews. >> >> Dan >> >> > Looks good to me. Makes it much clearer than the early version that > DEBUG_BINARIES effectively overrides everything else. From tim.bell at oracle.com Thu Aug 2 17:30:51 2012 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 02 Aug 2012 10:30:51 -0700 Subject: RFR: 7181175 Enable hotspot builds on Windows with MinGW/MSYS In-Reply-To: <50088BCD.2050207@oracle.com> References: <4FF26C88.8000305@oracle.com> <4FF27E19.5070904@oracle.com> <50060047.6000301@oracle.com> <50063F9F.7020107@oracle.com> <86CC2268-E71B-4AD2-9A4E-E987619C7E14@oracle.com> <5006FA09.7010905@oracle.com> <500707B7.4000102@oracle.com> <50088BCD.2050207@oracle.com> Message-ID: <501AB94B.5050909@oracle.com> Ping? I need someone on hotspot-runtime to sponsor this change and shepherd it through a JPRT push: http://cr.openjdk.java.net/~tbell/7181175/webrev.01/ I believe I have addressed the review feedback received so far, and I'd like to get this off my desk so I can focus on build-infra work. Thanks in advance- Tim On 07/19/12 15:35, Tim Bell wrote: > I wrote: >> My test build is running now. I'll update the webrev and send out a >> new URL. > > The test builds were successful. I also ran full hotspot builds on > JPRT using '-release jdk8' and '-release jdk7u6', so there is no > regression in the old builds. I believe I have addressed the review > feedback received so far: > > http://cr.openjdk.java.net/~tbell/7181175/webrev.01/ > > Thanks- > > Tim > >> http://mail.openjdk.java.net/pipermail/build-dev/2012-March/005729.html >> http://cr.openjdk.java.net/~simonis/MinGW_MSYS_hotspot.v1/ > > From daniel.daugherty at oracle.com Thu Aug 2 17:46:41 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 02 Aug 2012 11:46:41 -0600 Subject: RFR: 7181175 Enable hotspot builds on Windows with MinGW/MSYS In-Reply-To: <501AB94B.5050909@oracle.com> References: <4FF26C88.8000305@oracle.com> <4FF27E19.5070904@oracle.com> <50060047.6000301@oracle.com> <50063F9F.7020107@oracle.com> <86CC2268-E71B-4AD2-9A4E-E987619C7E14@oracle.com> <5006FA09.7010905@oracle.com> <500707B7.4000102@oracle.com> <50088BCD.2050207@oracle.com> <501AB94B.5050909@oracle.com> Message-ID: <501ABD01.609@oracle.com> Tim, I'm the RT_Baseline gatekeeper this month so I'll take a look at the changes and shepherd them into RT_Baseline. Dan On 8/2/12 11:30 AM, Tim Bell wrote: > Ping? I need someone on hotspot-runtime to sponsor this change and > shepherd it through a JPRT push: > > http://cr.openjdk.java.net/~tbell/7181175/webrev.01/ > > I believe I have addressed the review feedback received so far, and > I'd like to get this off my desk so I can focus on build-infra work. > > Thanks in advance- > > Tim > > > On 07/19/12 15:35, Tim Bell wrote: >> I wrote: >>> My test build is running now. I'll update the webrev and send out a >>> new URL. >> >> The test builds were successful. I also ran full hotspot builds on >> JPRT using '-release jdk8' and '-release jdk7u6', so there is no >> regression in the old builds. I believe I have addressed the review >> feedback received so far: >> >> http://cr.openjdk.java.net/~tbell/7181175/webrev.01/ >> >> Thanks- >> >> Tim >> >>> http://mail.openjdk.java.net/pipermail/build-dev/2012-March/005729.html >>> http://cr.openjdk.java.net/~simonis/MinGW_MSYS_hotspot.v1/ >> >> > > From tim.bell at oracle.com Thu Aug 2 18:12:51 2012 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 02 Aug 2012 11:12:51 -0700 Subject: RFR: 7181175 Enable hotspot builds on Windows with MinGW/MSYS In-Reply-To: <501ABD01.609@oracle.com> References: <4FF26C88.8000305@oracle.com> <4FF27E19.5070904@oracle.com> <50060047.6000301@oracle.com> <50063F9F.7020107@oracle.com> <86CC2268-E71B-4AD2-9A4E-E987619C7E14@oracle.com> <5006FA09.7010905@oracle.com> <500707B7.4000102@oracle.com> <50088BCD.2050207@oracle.com> <501AB94B.5050909@oracle.com> <501ABD01.609@oracle.com> Message-ID: <501AC323.7090500@oracle.com> Thanks, Dan. The patch off the webrev applies cleanly to a fresh clone of hotspot-rt % gpatch -p 1 < ../hotspot.patch patching file make/windows/makefiles/defs.make patching file make/windows/makefiles/rules.make patching file make/windows/makefiles/sa.make patching file make/windows/makefiles/shared.make Let me know if there is anything I can do to help you out. Tim On 08/02/12 10:46, Daniel D. Daugherty wrote: > Tim, > > I'm the RT_Baseline gatekeeper this month so I'll take a > look at the changes and shepherd them into RT_Baseline. > > Dan > > > On 8/2/12 11:30 AM, Tim Bell wrote: >> Ping? I need someone on hotspot-runtime to sponsor this change and >> shepherd it through a JPRT push: >> >> http://cr.openjdk.java.net/~tbell/7181175/webrev.01/ >> >> I believe I have addressed the review feedback received so far, and >> I'd like to get this off my desk so I can focus on build-infra work. >> >> Thanks in advance- >> >> Tim >> >> >> On 07/19/12 15:35, Tim Bell wrote: >>> I wrote: >>>> My test build is running now. I'll update the webrev and send out >>>> a new URL. >>> >>> The test builds were successful. I also ran full hotspot builds on >>> JPRT using '-release jdk8' and '-release jdk7u6', so there is no >>> regression in the old builds. I believe I have addressed the review >>> feedback received so far: >>> >>> http://cr.openjdk.java.net/~tbell/7181175/webrev.01/ >>> >>> Thanks- >>> >>> Tim >>> >>>> http://mail.openjdk.java.net/pipermail/build-dev/2012-March/005729.html >>>> >>>> http://cr.openjdk.java.net/~simonis/MinGW_MSYS_hotspot.v1/ >>> >>> >> >> From daniel.daugherty at oracle.com Thu Aug 2 21:20:24 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 02 Aug 2012 15:20:24 -0600 Subject: RFR: 7181175 Enable hotspot builds on Windows with MinGW/MSYS In-Reply-To: <501AB94B.5050909@oracle.com> References: <4FF26C88.8000305@oracle.com> <4FF27E19.5070904@oracle.com> <50060047.6000301@oracle.com> <50063F9F.7020107@oracle.com> <86CC2268-E71B-4AD2-9A4E-E987619C7E14@oracle.com> <5006FA09.7010905@oracle.com> <500707B7.4000102@oracle.com> <50088BCD.2050207@oracle.com> <501AB94B.5050909@oracle.com> Message-ID: <501AEF18.6020701@oracle.com> On 8/2/12 11:30 AM, Tim Bell wrote: > Ping? I need someone on hotspot-runtime to sponsor this change and > shepherd it through a JPRT push: > > http://cr.openjdk.java.net/~tbell/7181175/webrev.01/ make/windows/makefiles/defs.make No comments. make/windows/makefiles/rules.make lines 28-33: Might want to comment on why these paths still use backslash instead of forward slash. make/windows/makefiles/sa.make lines 88, 90: These lines drop the "/YX" option instead of changing it to "-YX". line 97: This line adds back the "-Z" option and drops the "/YX" option instead of changing it to "-YX". The "-Z" option is conditionally added on line 99. line 106: This line adds back the "-map -debug" options. The "-map" and "-debug" options are conditionally added on line 108. make/windows/makefiles/shared.make line 43: Might want to comment on why these paths still use backslash instead of forward slash. > > I believe I have addressed the review feedback received so far, and > I'd like to get this off my desk so I can focus on build-infra work. > > Thanks in advance- > > Tim > > > On 07/19/12 15:35, Tim Bell wrote: >> I wrote: >>> My test build is running now. I'll update the webrev and send out a >>> new URL. >> >> The test builds were successful. I also ran full hotspot builds on >> JPRT using '-release jdk8' and '-release jdk7u6', so there is no >> regression in the old builds. I believe I have addressed the review >> feedback received so far: >> >> http://cr.openjdk.java.net/~tbell/7181175/webrev.01/ >> >> Thanks- >> >> Tim >> >>> http://mail.openjdk.java.net/pipermail/build-dev/2012-March/005729.html >>> http://cr.openjdk.java.net/~simonis/MinGW_MSYS_hotspot.v1/ >> >> > > From tim.bell at oracle.com Fri Aug 3 19:26:20 2012 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 03 Aug 2012 12:26:20 -0700 Subject: RFR: 7181175 Enable hotspot builds on Windows with MinGW/MSYS In-Reply-To: <501AEF18.6020701@oracle.com> References: <4FF26C88.8000305@oracle.com> <4FF27E19.5070904@oracle.com> <50060047.6000301@oracle.com> <50063F9F.7020107@oracle.com> <86CC2268-E71B-4AD2-9A4E-E987619C7E14@oracle.com> <5006FA09.7010905@oracle.com> <500707B7.4000102@oracle.com> <50088BCD.2050207@oracle.com> <501AB94B.5050909@oracle.com> <501AEF18.6020701@oracle.com> Message-ID: <501C25DC.70202@oracle.com> On 08/02/12 14:20, Daniel D. Daugherty wrote: >> http://cr.openjdk.java.net/~tbell/7181175/webrev.01/ > Thanks for the review, Dan. > make/windows/makefiles/defs.make > No comments. > > make/windows/makefiles/rules.make > lines 28-33: Might want to comment on why these paths still > use backslash instead of forward slash. OK - done. > make/windows/makefiles/sa.make Oops, my error. Thanks for catching these, Dan. This goes to show how long these MinGW/MSYS changes have been in play... > lines 88, 90: > These lines drop the "/YX" option instead of changing it to > "-YX". Fixed. > line 97: > This line adds back the "-Z" option and drops the "/YX" option > instead of changing it to "-YX". I added back the -YX and removed -Z. > The "-Z" option is conditionally added on line 99. Ah - I see it now. Good. > line 106: > This line adds back the "-map -debug" options. > > The "-map" and "-debug" options are conditionally added on > line 108. Fixed. > make/windows/makefiles/shared.make > line 43: Might want to comment on why these paths still > use backslash instead of forward slash. OK - done. I submittted a new JPRT test job with these changes (2012-08-03-171845.tbell.hotspot) that completed successfully. New webrev here: http://cr.openjdk.java.net/~tbell/7181175/webrev.02/ Or if you prefer, here are the diffs relative to my previous webrev: > +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D > "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" > -YX -FD -c > !elseif "$(BUILDARCH)" == "amd64" > -SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D > "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" > -FD -c > +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D > "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" > -YX -FD -c > !if "$(COMPILER_NAME)" == "VS2005" > # On amd64, VS2005 compiler requires bufferoverflowU.lib on the link > command line, > # otherwise we get missing __security_check_cookie externals at link > time. > SA_LD_FLAGS = bufferoverflowU.lib > !endif > !else > -SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) -ZI -Od > -D "WIN32" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" -FD -GZ -c > +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) -Od -D > "WIN32" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" -YX -FD -GZ -c > !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" > SA_CFLAGS = $(SA_CFLAGS) -ZI > !endif > @@ -103,7 +103,7 @@ > SA_LD_FLAGS = -manifest $(SA_LD_FLAGS) > !endif > SASRCFILE = $(AGENT_DIR)/src/os/win32/windbg/sawindbg.cpp > -SA_LFLAGS = $(SA_LD_FLAGS) -nologo -subsystem:console -map -debug > -machine:$(MACHINE) > +SA_LFLAGS = $(SA_LD_FLAGS) -nologo -subsystem:console -machine:$(MACHINE) > !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" > SA_LFLAGS = $(SA_LFLAGS) -map -debug > !endif > --- /x/jdk8/7181175/hotspot.00/make/windows/makefiles/shared.make > 2012-07-18 12:11:25.954735638 -0700 > +++ /x/jdk8/7181175/hotspot/make/windows/makefiles/shared.make > 2012-08-03 10:15:53.249176409 -0700 > @@ -36,6 +36,7 @@ > > > !ifdef SUBDIRS > +# \ is used below because $(MAKE) is nmake here, which expects > Windows paths > $(SUBDIRS): FORCE > @if not exist $@ mkdir $@ > @if not exist $@/local.make echo # Empty > $@/local.make > From daniel.daugherty at oracle.com Fri Aug 3 20:45:11 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 03 Aug 2012 14:45:11 -0600 Subject: RFR: 7181175 Enable hotspot builds on Windows with MinGW/MSYS In-Reply-To: <501C25DC.70202@oracle.com> References: <4FF26C88.8000305@oracle.com> <4FF27E19.5070904@oracle.com> <50060047.6000301@oracle.com> <50063F9F.7020107@oracle.com> <86CC2268-E71B-4AD2-9A4E-E987619C7E14@oracle.com> <5006FA09.7010905@oracle.com> <500707B7.4000102@oracle.com> <50088BCD.2050207@oracle.com> <501AB94B.5050909@oracle.com> <501AEF18.6020701@oracle.com> <501C25DC.70202@oracle.com> Message-ID: <501C3857.4030300@oracle.com> Thumbs up on this version. Do you have a commit message ready for this patch? Dan On 8/3/12 1:26 PM, Tim Bell wrote: > On 08/02/12 14:20, Daniel D. Daugherty wrote: >>> http://cr.openjdk.java.net/~tbell/7181175/webrev.01/ >> > Thanks for the review, Dan. > >> make/windows/makefiles/defs.make >> No comments. >> >> make/windows/makefiles/rules.make >> lines 28-33: Might want to comment on why these paths still >> use backslash instead of forward slash. > > OK - done. > >> make/windows/makefiles/sa.make > > Oops, my error. Thanks for catching these, Dan. This goes to show > how long these MinGW/MSYS changes have been in play... > >> lines 88, 90: >> These lines drop the "/YX" option instead of changing it to >> "-YX". > > Fixed. > >> line 97: >> This line adds back the "-Z" option and drops the "/YX" option >> instead of changing it to "-YX". > > I added back the -YX and removed -Z. > >> The "-Z" option is conditionally added on line 99. > > Ah - I see it now. Good. > >> line 106: >> This line adds back the "-map -debug" options. >> >> The "-map" and "-debug" options are conditionally added on >> line 108. > > Fixed. > >> make/windows/makefiles/shared.make >> line 43: Might want to comment on why these paths still >> use backslash instead of forward slash. > > OK - done. > > > I submittted a new JPRT test job with these changes > (2012-08-03-171845.tbell.hotspot) that completed successfully. > > New webrev here: > > http://cr.openjdk.java.net/~tbell/7181175/webrev.02/ > > Or if you prefer, here are the diffs relative to my previous webrev: > >> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D >> "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" >> -YX -FD -c >> !elseif "$(BUILDARCH)" == "amd64" >> -SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D >> "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" >> -FD -c >> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D >> "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" >> -YX -FD -c >> !if "$(COMPILER_NAME)" == "VS2005" >> # On amd64, VS2005 compiler requires bufferoverflowU.lib on the link >> command line, >> # otherwise we get missing __security_check_cookie externals at link >> time. >> SA_LD_FLAGS = bufferoverflowU.lib >> !endif >> !else >> -SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) -ZI >> -Od -D "WIN32" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" -FD >> -GZ -c >> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) -Od -D >> "WIN32" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" -YX -FD >> -GZ -c >> !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" >> SA_CFLAGS = $(SA_CFLAGS) -ZI >> !endif >> @@ -103,7 +103,7 @@ >> SA_LD_FLAGS = -manifest $(SA_LD_FLAGS) >> !endif >> SASRCFILE = $(AGENT_DIR)/src/os/win32/windbg/sawindbg.cpp >> -SA_LFLAGS = $(SA_LD_FLAGS) -nologo -subsystem:console -map -debug >> -machine:$(MACHINE) >> +SA_LFLAGS = $(SA_LD_FLAGS) -nologo -subsystem:console >> -machine:$(MACHINE) >> !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" >> SA_LFLAGS = $(SA_LFLAGS) -map -debug >> !endif >> --- /x/jdk8/7181175/hotspot.00/make/windows/makefiles/shared.make >> 2012-07-18 12:11:25.954735638 -0700 >> +++ /x/jdk8/7181175/hotspot/make/windows/makefiles/shared.make >> 2012-08-03 10:15:53.249176409 -0700 >> @@ -36,6 +36,7 @@ >> >> >> !ifdef SUBDIRS >> +# \ is used below because $(MAKE) is nmake here, which expects >> Windows paths >> $(SUBDIRS): FORCE >> @if not exist $@ mkdir $@ >> @if not exist $@/local.make echo # Empty > $@/local.make >> > > From tim.bell at oracle.com Fri Aug 3 21:58:30 2012 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 03 Aug 2012 14:58:30 -0700 Subject: RFR: 7181175 Enable hotspot builds on Windows with MinGW/MSYS In-Reply-To: <501C3857.4030300@oracle.com> References: <4FF26C88.8000305@oracle.com> <4FF27E19.5070904@oracle.com> <50060047.6000301@oracle.com> <50063F9F.7020107@oracle.com> <86CC2268-E71B-4AD2-9A4E-E987619C7E14@oracle.com> <5006FA09.7010905@oracle.com> <500707B7.4000102@oracle.com> <50088BCD.2050207@oracle.com> <501AB94B.5050909@oracle.com> <501AEF18.6020701@oracle.com> <501C25DC.70202@oracle.com> <501C3857.4030300@oracle.com> Message-ID: <501C4986.4050704@oracle.com> Thanks, Dan How about this for a commit message: 7181175: Enable builds on Windows with MinGW/MSYS Summary: This fix is the minimum number of Makefile changes to enable building HotSpot with MinGW/MSYS Contributed-by: volker.simonis at gmail.com Reviewed-by: jcoomes, dcubed, Tim On 08/03/12 13:45, Daniel D. Daugherty wrote: > Thumbs up on this version. > > Do you have a commit message ready for this patch? > > Dan > > > On 8/3/12 1:26 PM, Tim Bell wrote: >> On 08/02/12 14:20, Daniel D. Daugherty wrote: >>>> http://cr.openjdk.java.net/~tbell/7181175/webrev.01/ >>> >> Thanks for the review, Dan. >> >>> make/windows/makefiles/defs.make >>> No comments. >>> >>> make/windows/makefiles/rules.make >>> lines 28-33: Might want to comment on why these paths still >>> use backslash instead of forward slash. >> >> OK - done. >> >>> make/windows/makefiles/sa.make >> >> Oops, my error. Thanks for catching these, Dan. This goes to show >> how long these MinGW/MSYS changes have been in play... >> >>> lines 88, 90: >>> These lines drop the "/YX" option instead of changing it to >>> "-YX". >> >> Fixed. >> >>> line 97: >>> This line adds back the "-Z" option and drops the "/YX" option >>> instead of changing it to "-YX". >> >> I added back the -YX and removed -Z. >> >>> The "-Z" option is conditionally added on line 99. >> >> Ah - I see it now. Good. >> >>> line 106: >>> This line adds back the "-map -debug" options. >>> >>> The "-map" and "-debug" options are conditionally added on >>> line 108. >> >> Fixed. >> >>> make/windows/makefiles/shared.make >>> line 43: Might want to comment on why these paths still >>> use backslash instead of forward slash. >> >> OK - done. >> >> >> I submittted a new JPRT test job with these changes >> (2012-08-03-171845.tbell.hotspot) that completed successfully. >> >> New webrev here: >> >> http://cr.openjdk.java.net/~tbell/7181175/webrev.02/ >> >> Or if you prefer, here are the diffs relative to my previous webrev: >> >>> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D >>> "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D >>> "_MBCS" -YX -FD -c >>> !elseif "$(BUILDARCH)" == "amd64" >>> -SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D >>> "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D >>> "_MBCS" -FD -c >>> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D >>> "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D >>> "_MBCS" -YX -FD -c >>> !if "$(COMPILER_NAME)" == "VS2005" >>> # On amd64, VS2005 compiler requires bufferoverflowU.lib on the >>> link command line, >>> # otherwise we get missing __security_check_cookie externals at >>> link time. >>> SA_LD_FLAGS = bufferoverflowU.lib >>> !endif >>> !else >>> -SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) -ZI >>> -Od -D "WIN32" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" >>> -FD -GZ -c >>> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) -Od >>> -D "WIN32" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" -YX >>> -FD -GZ -c >>> !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" >>> SA_CFLAGS = $(SA_CFLAGS) -ZI >>> !endif >>> @@ -103,7 +103,7 @@ >>> SA_LD_FLAGS = -manifest $(SA_LD_FLAGS) >>> !endif >>> SASRCFILE = $(AGENT_DIR)/src/os/win32/windbg/sawindbg.cpp >>> -SA_LFLAGS = $(SA_LD_FLAGS) -nologo -subsystem:console -map -debug >>> -machine:$(MACHINE) >>> +SA_LFLAGS = $(SA_LD_FLAGS) -nologo -subsystem:console >>> -machine:$(MACHINE) >>> !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" >>> SA_LFLAGS = $(SA_LFLAGS) -map -debug >>> !endif >>> --- /x/jdk8/7181175/hotspot.00/make/windows/makefiles/shared.make >>> 2012-07-18 12:11:25.954735638 -0700 >>> +++ /x/jdk8/7181175/hotspot/make/windows/makefiles/shared.make >>> 2012-08-03 10:15:53.249176409 -0700 >>> @@ -36,6 +36,7 @@ >>> >>> >>> !ifdef SUBDIRS >>> +# \ is used below because $(MAKE) is nmake here, which expects >>> Windows paths >>> $(SUBDIRS): FORCE >>> @if not exist $@ mkdir $@ >>> @if not exist $@/local.make echo # Empty > $@/local.make >>> >> >> From daniel.daugherty at oracle.com Fri Aug 3 22:09:09 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 03 Aug 2012 16:09:09 -0600 Subject: RFR: 7181175 Enable hotspot builds on Windows with MinGW/MSYS In-Reply-To: <501C4986.4050704@oracle.com> References: <4FF26C88.8000305@oracle.com> <4FF27E19.5070904@oracle.com> <50060047.6000301@oracle.com> <50063F9F.7020107@oracle.com> <86CC2268-E71B-4AD2-9A4E-E987619C7E14@oracle.com> <5006FA09.7010905@oracle.com> <500707B7.4000102@oracle.com> <50088BCD.2050207@oracle.com> <501AB94B.5050909@oracle.com> <501AEF18.6020701@oracle.com> <501C25DC.70202@oracle.com> <501C3857.4030300@oracle.com> <501C4986.4050704@oracle.com> Message-ID: <501C4C05.3030300@oracle.com> Gotta put 'tbell' in there some where... Can I add you as a reviewer? Dan On 8/3/12 3:58 PM, Tim Bell wrote: > Thanks, Dan > > How about this for a commit message: > > 7181175: Enable builds on Windows with MinGW/MSYS > Summary: This fix is the minimum number of Makefile changes to enable > building HotSpot with MinGW/MSYS > Contributed-by: volker.simonis at gmail.com > Reviewed-by: jcoomes, dcubed, > > Tim > > On 08/03/12 13:45, Daniel D. Daugherty wrote: >> Thumbs up on this version. >> >> Do you have a commit message ready for this patch? >> >> Dan >> >> >> On 8/3/12 1:26 PM, Tim Bell wrote: >>> On 08/02/12 14:20, Daniel D. Daugherty wrote: >>>>> http://cr.openjdk.java.net/~tbell/7181175/webrev.01/ >>>> >>> Thanks for the review, Dan. >>> >>>> make/windows/makefiles/defs.make >>>> No comments. >>>> >>>> make/windows/makefiles/rules.make >>>> lines 28-33: Might want to comment on why these paths still >>>> use backslash instead of forward slash. >>> >>> OK - done. >>> >>>> make/windows/makefiles/sa.make >>> >>> Oops, my error. Thanks for catching these, Dan. This goes to show >>> how long these MinGW/MSYS changes have been in play... >>> >>>> lines 88, 90: >>>> These lines drop the "/YX" option instead of changing it to >>>> "-YX". >>> >>> Fixed. >>> >>>> line 97: >>>> This line adds back the "-Z" option and drops the "/YX" option >>>> instead of changing it to "-YX". >>> >>> I added back the -YX and removed -Z. >>> >>>> The "-Z" option is conditionally added on line 99. >>> >>> Ah - I see it now. Good. >>> >>>> line 106: >>>> This line adds back the "-map -debug" options. >>>> >>>> The "-map" and "-debug" options are conditionally added on >>>> line 108. >>> >>> Fixed. >>> >>>> make/windows/makefiles/shared.make >>>> line 43: Might want to comment on why these paths still >>>> use backslash instead of forward slash. >>> >>> OK - done. >>> >>> >>> I submittted a new JPRT test job with these changes >>> (2012-08-03-171845.tbell.hotspot) that completed successfully. >>> >>> New webrev here: >>> >>> http://cr.openjdk.java.net/~tbell/7181175/webrev.02/ >>> >>> Or if you prefer, here are the diffs relative to my previous webrev: >>> >>>> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D >>>> "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D >>>> "_MBCS" -YX -FD -c >>>> !elseif "$(BUILDARCH)" == "amd64" >>>> -SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D >>>> "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D >>>> "_MBCS" -FD -c >>>> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D >>>> "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D >>>> "_MBCS" -YX -FD -c >>>> !if "$(COMPILER_NAME)" == "VS2005" >>>> # On amd64, VS2005 compiler requires bufferoverflowU.lib on the >>>> link command line, >>>> # otherwise we get missing __security_check_cookie externals at >>>> link time. >>>> SA_LD_FLAGS = bufferoverflowU.lib >>>> !endif >>>> !else >>>> -SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) -ZI >>>> -Od -D "WIN32" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" >>>> -FD -GZ -c >>>> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) -Od >>>> -D "WIN32" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" -YX >>>> -FD -GZ -c >>>> !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" >>>> SA_CFLAGS = $(SA_CFLAGS) -ZI >>>> !endif >>>> @@ -103,7 +103,7 @@ >>>> SA_LD_FLAGS = -manifest $(SA_LD_FLAGS) >>>> !endif >>>> SASRCFILE = $(AGENT_DIR)/src/os/win32/windbg/sawindbg.cpp >>>> -SA_LFLAGS = $(SA_LD_FLAGS) -nologo -subsystem:console -map -debug >>>> -machine:$(MACHINE) >>>> +SA_LFLAGS = $(SA_LD_FLAGS) -nologo -subsystem:console >>>> -machine:$(MACHINE) >>>> !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" >>>> SA_LFLAGS = $(SA_LFLAGS) -map -debug >>>> !endif >>>> --- /x/jdk8/7181175/hotspot.00/make/windows/makefiles/shared.make >>>> 2012-07-18 12:11:25.954735638 -0700 >>>> +++ /x/jdk8/7181175/hotspot/make/windows/makefiles/shared.make >>>> 2012-08-03 10:15:53.249176409 -0700 >>>> @@ -36,6 +36,7 @@ >>>> >>>> >>>> !ifdef SUBDIRS >>>> +# \ is used below because $(MAKE) is nmake here, which expects >>>> Windows paths >>>> $(SUBDIRS): FORCE >>>> @if not exist $@ mkdir $@ >>>> @if not exist $@/local.make echo # Empty > $@/local.make >>>> >>> >>> > > From tim.bell at oracle.com Fri Aug 3 23:08:16 2012 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 03 Aug 2012 16:08:16 -0700 Subject: RFR: 7181175 Enable hotspot builds on Windows with MinGW/MSYS In-Reply-To: <501C4C05.3030300@oracle.com> References: <4FF26C88.8000305@oracle.com> <4FF27E19.5070904@oracle.com> <50060047.6000301@oracle.com> <50063F9F.7020107@oracle.com> <86CC2268-E71B-4AD2-9A4E-E987619C7E14@oracle.com> <5006FA09.7010905@oracle.com> <500707B7.4000102@oracle.com> <50088BCD.2050207@oracle.com> <501AB94B.5050909@oracle.com> <501AEF18.6020701@oracle.com> <501C25DC.70202@oracle.com> <501C3857.4030300@oracle.com> <501C4986.4050704@oracle.com> <501C4C05.3030300@oracle.com> Message-ID: <501C59E0.8070404@oracle.com> On 08/03/12 15:09, Daniel D. Daugherty wrote: > Gotta put 'tbell' in there some where... > > Can I add you as a reviewer? Oh - that's right. Sure, add me as a reviewer. Tim > > Dan > > > On 8/3/12 3:58 PM, Tim Bell wrote: >> Thanks, Dan >> >> How about this for a commit message: >> >> 7181175: Enable builds on Windows with MinGW/MSYS >> Summary: This fix is the minimum number of Makefile changes to enable >> building HotSpot with MinGW/MSYS >> Contributed-by: volker.simonis at gmail.com >> Reviewed-by: jcoomes, dcubed, >> >> Tim >> >> On 08/03/12 13:45, Daniel D. Daugherty wrote: >>> Thumbs up on this version. >>> >>> Do you have a commit message ready for this patch? >>> >>> Dan >>> >>> >>> On 8/3/12 1:26 PM, Tim Bell wrote: >>>> On 08/02/12 14:20, Daniel D. Daugherty wrote: >>>>>> http://cr.openjdk.java.net/~tbell/7181175/webrev.01/ >>>>> >>>> Thanks for the review, Dan. >>>> >>>>> make/windows/makefiles/defs.make >>>>> No comments. >>>>> >>>>> make/windows/makefiles/rules.make >>>>> lines 28-33: Might want to comment on why these paths still >>>>> use backslash instead of forward slash. >>>> >>>> OK - done. >>>> >>>>> make/windows/makefiles/sa.make >>>> >>>> Oops, my error. Thanks for catching these, Dan. This goes to show >>>> how long these MinGW/MSYS changes have been in play... >>>> >>>>> lines 88, 90: >>>>> These lines drop the "/YX" option instead of changing it >>>>> to "-YX". >>>> >>>> Fixed. >>>> >>>>> line 97: >>>>> This line adds back the "-Z" option and drops the "/YX" >>>>> option >>>>> instead of changing it to "-YX". >>>> >>>> I added back the -YX and removed -Z. >>>> >>>>> The "-Z" option is conditionally added on line 99. >>>> >>>> Ah - I see it now. Good. >>>> >>>>> line 106: >>>>> This line adds back the "-map -debug" options. >>>>> >>>>> The "-map" and "-debug" options are conditionally added on >>>>> line 108. >>>> >>>> Fixed. >>>> >>>>> make/windows/makefiles/shared.make >>>>> line 43: Might want to comment on why these paths still >>>>> use backslash instead of forward slash. >>>> >>>> OK - done. >>>> >>>> >>>> I submittted a new JPRT test job with these changes >>>> (2012-08-03-171845.tbell.hotspot) that completed successfully. >>>> >>>> New webrev here: >>>> >>>> http://cr.openjdk.java.net/~tbell/7181175/webrev.02/ >>>> >>>> Or if you prefer, here are the diffs relative to my previous webrev: >>>> >>>>> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D >>>>> "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D >>>>> "_MBCS" -YX -FD -c >>>>> !elseif "$(BUILDARCH)" == "amd64" >>>>> -SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D >>>>> "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D >>>>> "_MBCS" -FD -c >>>>> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D >>>>> "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D >>>>> "_MBCS" -YX -FD -c >>>>> !if "$(COMPILER_NAME)" == "VS2005" >>>>> # On amd64, VS2005 compiler requires bufferoverflowU.lib on the >>>>> link command line, >>>>> # otherwise we get missing __security_check_cookie externals at >>>>> link time. >>>>> SA_LD_FLAGS = bufferoverflowU.lib >>>>> !endif >>>>> !else >>>>> -SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) -ZI >>>>> -Od -D "WIN32" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" >>>>> -FD -GZ -c >>>>> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) -Od >>>>> -D "WIN32" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" -YX >>>>> -FD -GZ -c >>>>> !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" >>>>> SA_CFLAGS = $(SA_CFLAGS) -ZI >>>>> !endif >>>>> @@ -103,7 +103,7 @@ >>>>> SA_LD_FLAGS = -manifest $(SA_LD_FLAGS) >>>>> !endif >>>>> SASRCFILE = $(AGENT_DIR)/src/os/win32/windbg/sawindbg.cpp >>>>> -SA_LFLAGS = $(SA_LD_FLAGS) -nologo -subsystem:console -map -debug >>>>> -machine:$(MACHINE) >>>>> +SA_LFLAGS = $(SA_LD_FLAGS) -nologo -subsystem:console >>>>> -machine:$(MACHINE) >>>>> !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" >>>>> SA_LFLAGS = $(SA_LFLAGS) -map -debug >>>>> !endif >>>>> --- /x/jdk8/7181175/hotspot.00/make/windows/makefiles/shared.make >>>>> 2012-07-18 12:11:25.954735638 -0700 >>>>> +++ /x/jdk8/7181175/hotspot/make/windows/makefiles/shared.make >>>>> 2012-08-03 10:15:53.249176409 -0700 >>>>> @@ -36,6 +36,7 @@ >>>>> >>>>> >>>>> !ifdef SUBDIRS >>>>> +# \ is used below because $(MAKE) is nmake here, which expects >>>>> Windows paths >>>>> $(SUBDIRS): FORCE >>>>> @if not exist $@ mkdir $@ >>>>> @if not exist $@/local.make echo # Empty > $@/local.make >>>>> >>>> >>>> >> >> From daniel.daugherty at oracle.com Fri Aug 3 23:21:26 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 03 Aug 2012 17:21:26 -0600 Subject: RFR: 7181175 Enable hotspot builds on Windows with MinGW/MSYS In-Reply-To: <501C59E0.8070404@oracle.com> References: <4FF26C88.8000305@oracle.com> <4FF27E19.5070904@oracle.com> <50060047.6000301@oracle.com> <50063F9F.7020107@oracle.com> <86CC2268-E71B-4AD2-9A4E-E987619C7E14@oracle.com> <5006FA09.7010905@oracle.com> <500707B7.4000102@oracle.com> <50088BCD.2050207@oracle.com> <501AB94B.5050909@oracle.com> <501AEF18.6020701@oracle.com> <501C25DC.70202@oracle.com> <501C3857.4030300@oracle.com> <501C4986.4050704@oracle.com> <501C4C05.3030300@oracle.com> <501C59E0.8070404@oracle.com> Message-ID: <501C5CF6.3060309@oracle.com> Added you to the reviewer list. You're also the "user" for the changeset. The job is in the JPRT-hotspotwest queue heading to RT_Baseline. Dan On 8/3/12 5:08 PM, Tim Bell wrote: > On 08/03/12 15:09, Daniel D. Daugherty wrote: >> Gotta put 'tbell' in there some where... >> >> Can I add you as a reviewer? > > Oh - that's right. Sure, add me as a reviewer. > > Tim > >> >> Dan >> >> >> On 8/3/12 3:58 PM, Tim Bell wrote: >>> Thanks, Dan >>> >>> How about this for a commit message: >>> >>> 7181175: Enable builds on Windows with MinGW/MSYS >>> Summary: This fix is the minimum number of Makefile changes to >>> enable building HotSpot with MinGW/MSYS >>> Contributed-by: volker.simonis at gmail.com >>> Reviewed-by: jcoomes, dcubed, >>> >>> Tim >>> >>> On 08/03/12 13:45, Daniel D. Daugherty wrote: >>>> Thumbs up on this version. >>>> >>>> Do you have a commit message ready for this patch? >>>> >>>> Dan >>>> >>>> >>>> On 8/3/12 1:26 PM, Tim Bell wrote: >>>>> On 08/02/12 14:20, Daniel D. Daugherty wrote: >>>>>>> http://cr.openjdk.java.net/~tbell/7181175/webrev.01/ >>>>>> >>>>> Thanks for the review, Dan. >>>>> >>>>>> make/windows/makefiles/defs.make >>>>>> No comments. >>>>>> >>>>>> make/windows/makefiles/rules.make >>>>>> lines 28-33: Might want to comment on why these paths still >>>>>> use backslash instead of forward slash. >>>>> >>>>> OK - done. >>>>> >>>>>> make/windows/makefiles/sa.make >>>>> >>>>> Oops, my error. Thanks for catching these, Dan. This goes to >>>>> show how long these MinGW/MSYS changes have been in play... >>>>> >>>>>> lines 88, 90: >>>>>> These lines drop the "/YX" option instead of changing it >>>>>> to "-YX". >>>>> >>>>> Fixed. >>>>> >>>>>> line 97: >>>>>> This line adds back the "-Z" option and drops the "/YX" >>>>>> option >>>>>> instead of changing it to "-YX". >>>>> >>>>> I added back the -YX and removed -Z. >>>>> >>>>>> The "-Z" option is conditionally added on line 99. >>>>> >>>>> Ah - I see it now. Good. >>>>> >>>>>> line 106: >>>>>> This line adds back the "-map -debug" options. >>>>>> >>>>>> The "-map" and "-debug" options are conditionally added >>>>>> on line 108. >>>>> >>>>> Fixed. >>>>> >>>>>> make/windows/makefiles/shared.make >>>>>> line 43: Might want to comment on why these paths still >>>>>> use backslash instead of forward slash. >>>>> >>>>> OK - done. >>>>> >>>>> >>>>> I submittted a new JPRT test job with these changes >>>>> (2012-08-03-171845.tbell.hotspot) that completed successfully. >>>>> >>>>> New webrev here: >>>>> >>>>> http://cr.openjdk.java.net/~tbell/7181175/webrev.02/ >>>>> >>>>> Or if you prefer, here are the diffs relative to my previous webrev: >>>>> >>>>>> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D >>>>>> "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D >>>>>> "_MBCS" -YX -FD -c >>>>>> !elseif "$(BUILDARCH)" == "amd64" >>>>>> -SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D >>>>>> "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D >>>>>> "_MBCS" -FD -c >>>>>> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D >>>>>> "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D >>>>>> "_MBCS" -YX -FD -c >>>>>> !if "$(COMPILER_NAME)" == "VS2005" >>>>>> # On amd64, VS2005 compiler requires bufferoverflowU.lib on the >>>>>> link command line, >>>>>> # otherwise we get missing __security_check_cookie externals at >>>>>> link time. >>>>>> SA_LD_FLAGS = bufferoverflowU.lib >>>>>> !endif >>>>>> !else >>>>>> -SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) >>>>>> -ZI -Od -D "WIN32" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D >>>>>> "_MBCS" -FD -GZ -c >>>>>> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) >>>>>> -Od -D "WIN32" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" >>>>>> -YX -FD -GZ -c >>>>>> !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" >>>>>> SA_CFLAGS = $(SA_CFLAGS) -ZI >>>>>> !endif >>>>>> @@ -103,7 +103,7 @@ >>>>>> SA_LD_FLAGS = -manifest $(SA_LD_FLAGS) >>>>>> !endif >>>>>> SASRCFILE = $(AGENT_DIR)/src/os/win32/windbg/sawindbg.cpp >>>>>> -SA_LFLAGS = $(SA_LD_FLAGS) -nologo -subsystem:console -map >>>>>> -debug -machine:$(MACHINE) >>>>>> +SA_LFLAGS = $(SA_LD_FLAGS) -nologo -subsystem:console >>>>>> -machine:$(MACHINE) >>>>>> !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" >>>>>> SA_LFLAGS = $(SA_LFLAGS) -map -debug >>>>>> !endif >>>>>> --- /x/jdk8/7181175/hotspot.00/make/windows/makefiles/shared.make >>>>>> 2012-07-18 12:11:25.954735638 -0700 >>>>>> +++ /x/jdk8/7181175/hotspot/make/windows/makefiles/shared.make >>>>>> 2012-08-03 10:15:53.249176409 -0700 >>>>>> @@ -36,6 +36,7 @@ >>>>>> >>>>>> >>>>>> !ifdef SUBDIRS >>>>>> +# \ is used below because $(MAKE) is nmake here, which expects >>>>>> Windows paths >>>>>> $(SUBDIRS): FORCE >>>>>> @if not exist $@ mkdir $@ >>>>>> @if not exist $@/local.make echo # Empty > $@/local.make >>>>>> >>>>> >>>>> >>> >>> > > > From kelly.ohair at oracle.com Sat Aug 4 00:08:52 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 3 Aug 2012 17:08:52 -0700 Subject: RFR: 7181175 Enable hotspot builds on Windows with MinGW/MSYS In-Reply-To: <501C5CF6.3060309@oracle.com> References: <4FF26C88.8000305@oracle.com> <4FF27E19.5070904@oracle.com> <50060047.6000301@oracle.com> <50063F9F.7020107@oracle.com> <86CC2268-E71B-4AD2-9A4E-E987619C7E14@oracle.com> <5006FA09.7010905@oracle.com> <500707B7.4000102@oracle.com> <50088BCD.2050207@oracle.com> <501AB94B.5050909@oracle.com> <501AEF18.6020701@oracle.com> <501C25DC.70202@oracle.com> <501C3857.4030300@oracle.com> <501C4986.4050704@oracle.com> <501C4C05.3030300@oracle.com> <501C59E0.8070404@oracle.com> <501C5CF6.3060309@oracle.com> Message-ID: <3F0EB121-5D61-4BFE-9760-D10487832378@oracle.com> I thought you would have done a hg commit --user tbell so it belongs to Tim? I did a review too, but no big deal. -kto On Aug 3, 2012, at 4:21 PM, Daniel D. Daugherty wrote: > Added you to the reviewer list. You're also the "user" for the > changeset. The job is in the JPRT-hotspotwest queue heading to > RT_Baseline. > > Dan > > > On 8/3/12 5:08 PM, Tim Bell wrote: >> On 08/03/12 15:09, Daniel D. Daugherty wrote: >>> Gotta put 'tbell' in there some where... >>> >>> Can I add you as a reviewer? >> >> Oh - that's right. Sure, add me as a reviewer. >> >> Tim >> >>> >>> Dan >>> >>> >>> On 8/3/12 3:58 PM, Tim Bell wrote: >>>> Thanks, Dan >>>> >>>> How about this for a commit message: >>>> >>>> 7181175: Enable builds on Windows with MinGW/MSYS >>>> Summary: This fix is the minimum number of Makefile changes to enable building HotSpot with MinGW/MSYS >>>> Contributed-by: volker.simonis at gmail.com >>>> Reviewed-by: jcoomes, dcubed, >>>> >>>> Tim >>>> >>>> On 08/03/12 13:45, Daniel D. Daugherty wrote: >>>>> Thumbs up on this version. >>>>> >>>>> Do you have a commit message ready for this patch? >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 8/3/12 1:26 PM, Tim Bell wrote: >>>>>> On 08/02/12 14:20, Daniel D. Daugherty wrote: >>>>>>>> http://cr.openjdk.java.net/~tbell/7181175/webrev.01/ >>>>>>> >>>>>> Thanks for the review, Dan. >>>>>> >>>>>>> make/windows/makefiles/defs.make >>>>>>> No comments. >>>>>>> >>>>>>> make/windows/makefiles/rules.make >>>>>>> lines 28-33: Might want to comment on why these paths still >>>>>>> use backslash instead of forward slash. >>>>>> >>>>>> OK - done. >>>>>> >>>>>>> make/windows/makefiles/sa.make >>>>>> >>>>>> Oops, my error. Thanks for catching these, Dan. This goes to show how long these MinGW/MSYS changes have been in play... >>>>>> >>>>>>> lines 88, 90: >>>>>>> These lines drop the "/YX" option instead of changing it to "-YX". >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> line 97: >>>>>>> This line adds back the "-Z" option and drops the "/YX" option >>>>>>> instead of changing it to "-YX". >>>>>> >>>>>> I added back the -YX and removed -Z. >>>>>> >>>>>>> The "-Z" option is conditionally added on line 99. >>>>>> >>>>>> Ah - I see it now. Good. >>>>>> >>>>>>> line 106: >>>>>>> This line adds back the "-map -debug" options. >>>>>>> >>>>>>> The "-map" and "-debug" options are conditionally added on line 108. >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> make/windows/makefiles/shared.make >>>>>>> line 43: Might want to comment on why these paths still >>>>>>> use backslash instead of forward slash. >>>>>> >>>>>> OK - done. >>>>>> >>>>>> >>>>>> I submittted a new JPRT test job with these changes (2012-08-03-171845.tbell.hotspot) that completed successfully. >>>>>> >>>>>> New webrev here: >>>>>> >>>>>> http://cr.openjdk.java.net/~tbell/7181175/webrev.02/ >>>>>> >>>>>> Or if you prefer, here are the diffs relative to my previous webrev: >>>>>> >>>>>>> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" -YX -FD -c >>>>>>> !elseif "$(BUILDARCH)" == "amd64" >>>>>>> -SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" -FD -c >>>>>>> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" -YX -FD -c >>>>>>> !if "$(COMPILER_NAME)" == "VS2005" >>>>>>> # On amd64, VS2005 compiler requires bufferoverflowU.lib on the link command line, >>>>>>> # otherwise we get missing __security_check_cookie externals at link time. >>>>>>> SA_LD_FLAGS = bufferoverflowU.lib >>>>>>> !endif >>>>>>> !else >>>>>>> -SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) -ZI -Od -D "WIN32" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" -FD -GZ -c >>>>>>> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) -Od -D "WIN32" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" -YX -FD -GZ -c >>>>>>> !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" >>>>>>> SA_CFLAGS = $(SA_CFLAGS) -ZI >>>>>>> !endif >>>>>>> @@ -103,7 +103,7 @@ >>>>>>> SA_LD_FLAGS = -manifest $(SA_LD_FLAGS) >>>>>>> !endif >>>>>>> SASRCFILE = $(AGENT_DIR)/src/os/win32/windbg/sawindbg.cpp >>>>>>> -SA_LFLAGS = $(SA_LD_FLAGS) -nologo -subsystem:console -map -debug -machine:$(MACHINE) >>>>>>> +SA_LFLAGS = $(SA_LD_FLAGS) -nologo -subsystem:console -machine:$(MACHINE) >>>>>>> !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" >>>>>>> SA_LFLAGS = $(SA_LFLAGS) -map -debug >>>>>>> !endif >>>>>>> --- /x/jdk8/7181175/hotspot.00/make/windows/makefiles/shared.make 2012-07-18 12:11:25.954735638 -0700 >>>>>>> +++ /x/jdk8/7181175/hotspot/make/windows/makefiles/shared.make 2012-08-03 10:15:53.249176409 -0700 >>>>>>> @@ -36,6 +36,7 @@ >>>>>>> >>>>>>> >>>>>>> !ifdef SUBDIRS >>>>>>> +# \ is used below because $(MAKE) is nmake here, which expects Windows paths >>>>>>> $(SUBDIRS): FORCE >>>>>>> @if not exist $@ mkdir $@ >>>>>>> @if not exist $@/local.make echo # Empty > $@/local.make >>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> >> From daniel.daugherty at oracle.com Sat Aug 4 01:34:46 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 03 Aug 2012 19:34:46 -0600 Subject: RFR: 7181175 Enable hotspot builds on Windows with MinGW/MSYS In-Reply-To: <3F0EB121-5D61-4BFE-9760-D10487832378@oracle.com> References: <4FF26C88.8000305@oracle.com> <4FF27E19.5070904@oracle.com> <50060047.6000301@oracle.com> <50063F9F.7020107@oracle.com> <86CC2268-E71B-4AD2-9A4E-E987619C7E14@oracle.com> <5006FA09.7010905@oracle.com> <500707B7.4000102@oracle.com> <50088BCD.2050207@oracle.com> <501AB94B.5050909@oracle.com> <501AEF18.6020701@oracle.com> <501C25DC.70202@oracle.com> <501C3857.4030300@oracle.com> <501C4986.4050704@oracle.com> <501C4C05.3030300@oracle.com> <501C59E0.8070404@oracle.com> <501C5CF6.3060309@oracle.com> <3F0EB121-5D61-4BFE-9760-D10487832378@oracle.com> Message-ID: <501C7C36.9060901@oracle.com> On 8/3/12 6:08 PM, Kelly O'Hair wrote: > I thought you would have done a hg commit --user tbell so it belongs to Tim? Yes, the changeset belongs to Tim, but I also listed him as a reviewer since he reviewed the code as well. > I did a review too, but no big deal. Sorry, I wasn't aware of that. I'll fix that in a minute. Dan > -kto > > On Aug 3, 2012, at 4:21 PM, Daniel D. Daugherty wrote: > >> Added you to the reviewer list. You're also the "user" for the >> changeset. The job is in the JPRT-hotspotwest queue heading to >> RT_Baseline. >> >> Dan >> >> >> On 8/3/12 5:08 PM, Tim Bell wrote: >>> On 08/03/12 15:09, Daniel D. Daugherty wrote: >>>> Gotta put 'tbell' in there some where... >>>> >>>> Can I add you as a reviewer? >>> Oh - that's right. Sure, add me as a reviewer. >>> >>> Tim >>> >>>> Dan >>>> >>>> >>>> On 8/3/12 3:58 PM, Tim Bell wrote: >>>>> Thanks, Dan >>>>> >>>>> How about this for a commit message: >>>>> >>>>> 7181175: Enable builds on Windows with MinGW/MSYS >>>>> Summary: This fix is the minimum number of Makefile changes to enable building HotSpot with MinGW/MSYS >>>>> Contributed-by: volker.simonis at gmail.com >>>>> Reviewed-by: jcoomes, dcubed, >>>>> >>>>> Tim >>>>> >>>>> On 08/03/12 13:45, Daniel D. Daugherty wrote: >>>>>> Thumbs up on this version. >>>>>> >>>>>> Do you have a commit message ready for this patch? >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> On 8/3/12 1:26 PM, Tim Bell wrote: >>>>>>> On 08/02/12 14:20, Daniel D. Daugherty wrote: >>>>>>>>> http://cr.openjdk.java.net/~tbell/7181175/webrev.01/ >>>>>>> Thanks for the review, Dan. >>>>>>> >>>>>>>> make/windows/makefiles/defs.make >>>>>>>> No comments. >>>>>>>> >>>>>>>> make/windows/makefiles/rules.make >>>>>>>> lines 28-33: Might want to comment on why these paths still >>>>>>>> use backslash instead of forward slash. >>>>>>> OK - done. >>>>>>> >>>>>>>> make/windows/makefiles/sa.make >>>>>>> Oops, my error. Thanks for catching these, Dan. This goes to show how long these MinGW/MSYS changes have been in play... >>>>>>> >>>>>>>> lines 88, 90: >>>>>>>> These lines drop the "/YX" option instead of changing it to "-YX". >>>>>>> Fixed. >>>>>>> >>>>>>>> line 97: >>>>>>>> This line adds back the "-Z" option and drops the "/YX" option >>>>>>>> instead of changing it to "-YX". >>>>>>> I added back the -YX and removed -Z. >>>>>>> >>>>>>>> The "-Z" option is conditionally added on line 99. >>>>>>> Ah - I see it now. Good. >>>>>>> >>>>>>>> line 106: >>>>>>>> This line adds back the "-map -debug" options. >>>>>>>> >>>>>>>> The "-map" and "-debug" options are conditionally added on line 108. >>>>>>> Fixed. >>>>>>> >>>>>>>> make/windows/makefiles/shared.make >>>>>>>> line 43: Might want to comment on why these paths still >>>>>>>> use backslash instead of forward slash. >>>>>>> OK - done. >>>>>>> >>>>>>> >>>>>>> I submittted a new JPRT test job with these changes (2012-08-03-171845.tbell.hotspot) that completed successfully. >>>>>>> >>>>>>> New webrev here: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~tbell/7181175/webrev.02/ >>>>>>> >>>>>>> Or if you prefer, here are the diffs relative to my previous webrev: >>>>>>> >>>>>>>> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" -YX -FD -c >>>>>>>> !elseif "$(BUILDARCH)" == "amd64" >>>>>>>> -SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" -FD -c >>>>>>>> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" -YX -FD -c >>>>>>>> !if "$(COMPILER_NAME)" == "VS2005" >>>>>>>> # On amd64, VS2005 compiler requires bufferoverflowU.lib on the link command line, >>>>>>>> # otherwise we get missing __security_check_cookie externals at link time. >>>>>>>> SA_LD_FLAGS = bufferoverflowU.lib >>>>>>>> !endif >>>>>>>> !else >>>>>>>> -SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) -ZI -Od -D "WIN32" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" -FD -GZ -c >>>>>>>> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) -Od -D "WIN32" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D "_MBCS" -YX -FD -GZ -c >>>>>>>> !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" >>>>>>>> SA_CFLAGS = $(SA_CFLAGS) -ZI >>>>>>>> !endif >>>>>>>> @@ -103,7 +103,7 @@ >>>>>>>> SA_LD_FLAGS = -manifest $(SA_LD_FLAGS) >>>>>>>> !endif >>>>>>>> SASRCFILE = $(AGENT_DIR)/src/os/win32/windbg/sawindbg.cpp >>>>>>>> -SA_LFLAGS = $(SA_LD_FLAGS) -nologo -subsystem:console -map -debug -machine:$(MACHINE) >>>>>>>> +SA_LFLAGS = $(SA_LD_FLAGS) -nologo -subsystem:console -machine:$(MACHINE) >>>>>>>> !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" >>>>>>>> SA_LFLAGS = $(SA_LFLAGS) -map -debug >>>>>>>> !endif >>>>>>>> --- /x/jdk8/7181175/hotspot.00/make/windows/makefiles/shared.make 2012-07-18 12:11:25.954735638 -0700 >>>>>>>> +++ /x/jdk8/7181175/hotspot/make/windows/makefiles/shared.make 2012-08-03 10:15:53.249176409 -0700 >>>>>>>> @@ -36,6 +36,7 @@ >>>>>>>> >>>>>>>> >>>>>>>> !ifdef SUBDIRS >>>>>>>> +# \ is used below because $(MAKE) is nmake here, which expects Windows paths >>>>>>>> $(SUBDIRS): FORCE >>>>>>>> @if not exist $@ mkdir $@ >>>>>>>> @if not exist $@/local.make echo # Empty> $@/local.make >>>>>>>> >>>>>>> >>>>> >>> >>> From tim.bell at oracle.com Sat Aug 4 02:56:33 2012 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 03 Aug 2012 19:56:33 -0700 Subject: RFR: 7181175 Enable hotspot builds on Windows with MinGW/MSYS In-Reply-To: <501C7C36.9060901@oracle.com> References: <4FF26C88.8000305@oracle.com> <4FF27E19.5070904@oracle.com> <50060047.6000301@oracle.com> <50063F9F.7020107@oracle.com> <86CC2268-E71B-4AD2-9A4E-E987619C7E14@oracle.com> <5006FA09.7010905@oracle.com> <500707B7.4000102@oracle.com> <50088BCD.2050207@oracle.com> <501AB94B.5050909@oracle.com> <501AEF18.6020701@oracle.com> <501C25DC.70202@oracle.com> <501C3857.4030300@oracle.com> <501C4986.4050704@oracle.com> <501C4C05.3030300@oracle.com> <501C59E0.8070404@oracle.com> <501C5CF6.3060309@oracle.com> <3F0EB121-5D61-4BFE-9760-D10487832378@oracle.com> <501C7C36.9060901@oracle.com> Message-ID: <501C8F61.6060907@oracle.com> Kelly, that's correct, you did. It was my oversight that you were not listed. Dan - thanks again. Brace yourselves for the rest of the MinGW/MSYS changes in bug #7152336 - hotspot got off relatively easily. Tim On 08/03/12 18:34, Daniel D. Daugherty wrote: > On 8/3/12 6:08 PM, Kelly O'Hair wrote: >> I thought you would have done a hg commit --user tbell so it >> belongs to Tim? > > Yes, the changeset belongs to Tim, but I also listed > him as a reviewer since he reviewed the code as well. > > >> I did a review too, but no big deal. > > Sorry, I wasn't aware of that. I'll fix that in a minute. > > Dan > > >> -kto >> >> On Aug 3, 2012, at 4:21 PM, Daniel D. Daugherty wrote: >> >>> Added you to the reviewer list. You're also the "user" for the >>> changeset. The job is in the JPRT-hotspotwest queue heading to >>> RT_Baseline. >>> >>> Dan >>> >>> >>> On 8/3/12 5:08 PM, Tim Bell wrote: >>>> On 08/03/12 15:09, Daniel D. Daugherty wrote: >>>>> Gotta put 'tbell' in there some where... >>>>> >>>>> Can I add you as a reviewer? >>>> Oh - that's right. Sure, add me as a reviewer. >>>> >>>> Tim >>>> >>>>> Dan >>>>> >>>>> >>>>> On 8/3/12 3:58 PM, Tim Bell wrote: >>>>>> Thanks, Dan >>>>>> >>>>>> How about this for a commit message: >>>>>> >>>>>> 7181175: Enable builds on Windows with MinGW/MSYS >>>>>> Summary: This fix is the minimum number of Makefile changes to >>>>>> enable building HotSpot with MinGW/MSYS >>>>>> Contributed-by: volker.simonis at gmail.com >>>>>> Reviewed-by: jcoomes, dcubed, >>>>>> >>>>>> Tim >>>>>> >>>>>> On 08/03/12 13:45, Daniel D. Daugherty wrote: >>>>>>> Thumbs up on this version. >>>>>>> >>>>>>> Do you have a commit message ready for this patch? >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> On 8/3/12 1:26 PM, Tim Bell wrote: >>>>>>>> On 08/02/12 14:20, Daniel D. Daugherty wrote: >>>>>>>>>> http://cr.openjdk.java.net/~tbell/7181175/webrev.01/ >>>>>>>> Thanks for the review, Dan. >>>>>>>> >>>>>>>>> make/windows/makefiles/defs.make >>>>>>>>> No comments. >>>>>>>>> >>>>>>>>> make/windows/makefiles/rules.make >>>>>>>>> lines 28-33: Might want to comment on why these paths still >>>>>>>>> use backslash instead of forward slash. >>>>>>>> OK - done. >>>>>>>> >>>>>>>>> make/windows/makefiles/sa.make >>>>>>>> Oops, my error. Thanks for catching these, Dan. This goes to >>>>>>>> show how long these MinGW/MSYS changes have been in play... >>>>>>>> >>>>>>>>> lines 88, 90: >>>>>>>>> These lines drop the "/YX" option instead of changing >>>>>>>>> it to "-YX". >>>>>>>> Fixed. >>>>>>>> >>>>>>>>> line 97: >>>>>>>>> This line adds back the "-Z" option and drops the >>>>>>>>> "/YX" option >>>>>>>>> instead of changing it to "-YX". >>>>>>>> I added back the -YX and removed -Z. >>>>>>>> >>>>>>>>> The "-Z" option is conditionally added on line 99. >>>>>>>> Ah - I see it now. Good. >>>>>>>> >>>>>>>>> line 106: >>>>>>>>> This line adds back the "-map -debug" options. >>>>>>>>> >>>>>>>>> The "-map" and "-debug" options are conditionally >>>>>>>>> added on line 108. >>>>>>>> Fixed. >>>>>>>> >>>>>>>>> make/windows/makefiles/shared.make >>>>>>>>> line 43: Might want to comment on why these paths still >>>>>>>>> use backslash instead of forward slash. >>>>>>>> OK - done. >>>>>>>> >>>>>>>> >>>>>>>> I submittted a new JPRT test job with these changes >>>>>>>> (2012-08-03-171845.tbell.hotspot) that completed successfully. >>>>>>>> >>>>>>>> New webrev here: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~tbell/7181175/webrev.02/ >>>>>>>> >>>>>>>> Or if you prefer, here are the diffs relative to my previous >>>>>>>> webrev: >>>>>>>> >>>>>>>>> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od >>>>>>>>> -D "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" >>>>>>>>> -D "_MBCS" -YX -FD -c >>>>>>>>> !elseif "$(BUILDARCH)" == "amd64" >>>>>>>>> -SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od >>>>>>>>> -D "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" >>>>>>>>> -D "_MBCS" -FD -c >>>>>>>>> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od >>>>>>>>> -D "WIN32" -D "WIN64" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" >>>>>>>>> -D "_MBCS" -YX -FD -c >>>>>>>>> !if "$(COMPILER_NAME)" == "VS2005" >>>>>>>>> # On amd64, VS2005 compiler requires bufferoverflowU.lib on >>>>>>>>> the link command line, >>>>>>>>> # otherwise we get missing __security_check_cookie externals >>>>>>>>> at link time. >>>>>>>>> SA_LD_FLAGS = bufferoverflowU.lib >>>>>>>>> !endif >>>>>>>>> !else >>>>>>>>> -SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) >>>>>>>>> -ZI -Od -D "WIN32" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D >>>>>>>>> "_MBCS" -FD -GZ -c >>>>>>>>> +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) >>>>>>>>> -Od -D "WIN32" -D "_WINDOWS" -D "_DEBUG" -D "_CONSOLE" -D >>>>>>>>> "_MBCS" -YX -FD -GZ -c >>>>>>>>> !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" >>>>>>>>> SA_CFLAGS = $(SA_CFLAGS) -ZI >>>>>>>>> !endif >>>>>>>>> @@ -103,7 +103,7 @@ >>>>>>>>> SA_LD_FLAGS = -manifest $(SA_LD_FLAGS) >>>>>>>>> !endif >>>>>>>>> SASRCFILE = $(AGENT_DIR)/src/os/win32/windbg/sawindbg.cpp >>>>>>>>> -SA_LFLAGS = $(SA_LD_FLAGS) -nologo -subsystem:console -map >>>>>>>>> -debug -machine:$(MACHINE) >>>>>>>>> +SA_LFLAGS = $(SA_LD_FLAGS) -nologo -subsystem:console >>>>>>>>> -machine:$(MACHINE) >>>>>>>>> !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" >>>>>>>>> SA_LFLAGS = $(SA_LFLAGS) -map -debug >>>>>>>>> !endif >>>>>>>>> --- >>>>>>>>> /x/jdk8/7181175/hotspot.00/make/windows/makefiles/shared.make >>>>>>>>> 2012-07-18 12:11:25.954735638 -0700 >>>>>>>>> +++ /x/jdk8/7181175/hotspot/make/windows/makefiles/shared.make >>>>>>>>> 2012-08-03 10:15:53.249176409 -0700 >>>>>>>>> @@ -36,6 +36,7 @@ >>>>>>>>> >>>>>>>>> >>>>>>>>> !ifdef SUBDIRS >>>>>>>>> +# \ is used below because $(MAKE) is nmake here, which >>>>>>>>> expects Windows paths >>>>>>>>> $(SUBDIRS): FORCE >>>>>>>>> @if not exist $@ mkdir $@ >>>>>>>>> @if not exist $@/local.make echo # Empty> $@/local.make >>>>>>>>> >>>>>>>> >>>>>> >>>> >>>> From erik.joelsson at oracle.com Mon Aug 6 09:33:38 2012 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 06 Aug 2012 11:33:38 +0200 Subject: jdk builds on the mac In-Reply-To: <501310E5.2070007@oracle.COM> References: <041963DD-5D06-4CDB-8E23-0FEC94DAAC1B@oracle.com> <501310E5.2070007@oracle.COM> Message-ID: <501F8F72.4060205@oracle.com> The classpath reference was added on my request for build-infra. The reason was to get javax.annotation.GenerateNativeHeader on the classpath. The javac used in that ant script is the bootjdk javac, which usually doesn't provide the annotation. I suppose the correct fix would be to change the ant script to use the bootstrap javac instead. /Erik On 2012-07-28 00:06, Kumar Srinivasan wrote: > On 7/25/2012 2:23 PM, Kelly O'Hair wrote: >> Naoto has noticed this build failure on the Mac (just the Mac) when >> building just the jdk repository. >> >> From what I can tell, the Mac build of the jdk repository now >> depends on the langtools repository also >> being built, which means that partial builds of just the jdk >> repository will no longer work on the Mac? >> There is an ant script at jdk/src/macosx/native/jobjc/build.xml that >> has a baked in classpath reference to >> ../../langtools/dist/lib/classes.jar >> >> Has anyone seen this, or have any additional information on it? > > This is preventing me to test certain things I can only run from a jdk > build under > jprt on the macosx machine. > > Kumar > >> >> -kto >> >> ------------------------------------------------------------------------------ >> >> build-core: >> [mkdir] Created dir: >> /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core >> [javac] com/apple/jobjc/PrimitiveCoder.java added as >> com/apple/jobjc/PrimitiveCoder.class doesn't exist. >> [javac] Compiling 1 source file to >> /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core >> [javac] Using modern compiler >> dropping >> /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/langtools/dist/lib/classes.jar >> from path as it doesn't exist >> [javac] Compilation arguments: >> [javac] '-d' >> [javac] >> '/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core' >> [javac] '-classpath' >> [javac] >> '/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core' >> [javac] '-sourcepath' >> [javac] >> '/private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java' >> [javac] '-target' >> [javac] '1.5' >> [javac] '-g' >> [javac] '-source' >> [javac] '1.5' >> [javac] >> [javac] The ' characters around the executable and arguments are >> [javac] not part of the command. >> [javac] File to be compiled: >> [javac] >> /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/PrimitiveCoder.java >> [javac] warning: [options] bootstrap class path not set in >> conjunction with -source 1.5 >> [javac] >> /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java:32: >> warning: Unsafe is internal proprietary API and may be removed in a >> future release >> [javac] import sun.misc.Unsafe; >> [javac] ^ >> >> ..... >> >> [javac] @GenerateNativeHeader >> [javac] ^ >> [javac] symbol: class GenerateNativeHeader >> [javac] Note: Some input files use unchecked or unsafe operations. >> [javac] Note: Recompile with -Xlint:unchecked for details. >> [javac] 61 errors >> [javac] 7 warnings >> >> BUILD FAILED >> /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/build.xml:143: >> Compile failed; see the compiler error output for details. >> at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:1079) >> at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:882) >> at >> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) >> at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:601) >> at >> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) >> at org.apache.tools.ant.Task.perform(Task.java:348) >> at org.apache.tools.ant.Target.execute(Target.java:357) >> at org.apache.tools.ant.Target.performTasks(Target.java:385) >> at >> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) >> at org.apache.tools.ant.Project.executeTarget(Project.java:1306) >> at >> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) >> at org.apache.tools.ant.Project.executeTargets(Project.java:1189) >> at org.apache.tools.ant.Main.runBuild(Main.java:758) >> at org.apache.tools.ant.Main.startAnt(Main.java:217) >> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) >> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) >> >> Total time: 1 second >> make[2]: *** [../../../build/macosx-x86_64/JObjC.build/JObjC.jar] >> Error 1 >> make[1]: *** [all] Error 1 >> make: *** [all] Error 1 > From erik.joelsson at oracle.com Tue Aug 7 09:57:45 2012 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 07 Aug 2012 11:57:45 +0200 Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data In-Reply-To: References: <4FFC93CF.40105@oracle.com> Message-ID: <5020E699.3000600@oracle.com> See inline On 2012-07-13 22:20, Kelly O'Hair wrote: > Something seems strange here: > http://cr.openjdk.java.net/~naoto/6336885/webrev.00/make/java/java/localegen.sh.sdiff.html > It's like someone was avoiding overall quotes, but using them to add spaces somehow... > I sure would like to get rid of this shell logic, seems like there are lots repeated logic that > this script does over and over or could be done with makefile pattern subst's instead of exec's. The new version isn't any worse than the old in my opinion. In build-infra, this file is indeed replaced with make logic. After having decoded both versions I'm confident in converting the changes. > Overall, just looking at the makefiles, the build-infra team may need some time to fully absorb this into the > new makefiles, some of it will be trivial, not sure all of it will be. > I have applied the patch to a clone of build-infra and done the minimal changes to keep build-infra building, which was rather trivial. The resulting build has large differences since I haven't converted all of it yet. There are a couple of things that will require some more work, but not more than a day or two. > Not sure how to proceed here, the build-infra team does need an action item to deal with this, maybe > before it gets integrated because I suspect the new makefiles will break with all the filename or > directory changes. But I hate to hold up your integration plans. I see these as possible options: 1. Let this go in, build-infra will break in jdk8 until we do our next push and it trickles through the repos. 2. The build-infra project provides a patch with the full conversion that can go in together with these changes. 3. The build-infra project provides a simple patch which just keeps the build-infra-build from failing that can go in with these changes. The conversion needs to happen regardless of option. The changes required are pretty isolated from remaining build-infra work. What do you think? Other than that, I have no objections to the review. /Erik > I'd like to get some advice from Erik on this before saying anything further. > > -kto > > On Jul 10, 2012, at 1:42 PM, Naoto Sato wrote: > >> Hello, >> >> Please review the JDK8 changes for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data (http://openjdk.java.net/jeps/127). The webrev is located at: >> >> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/ >> >> The main bug id for this enhancement is: >> >> 6336885: RFE: Locale Data Deployment Enhancements >> >> Along with this, the following bugs/enhancements are also implemented in this change: >> >> 4609153 Provide locale data for Indic locales >> 5104387 Support for gl_ES locale (galician language) >> 6337471 desktop/system locale preferences support >> 7056139 (cal) SPI support for locale-dependent Calendar parameters >> 7058206 Provide CalendarData SPI for week params and display field value names >> 7073852 Support multiple scripts for digits and decimal symbols per locale >> 7079560 [Fmt-Da] Context dependent month names support in SimpleDateFormat >> 7171324 getAvailableLocales() of locale sensitive services should return the actual availability of locales >> 7151414 (cal) Support calendar type identification >> 7168528 LocaleServiceProvider needs to be aware of Locale extensions >> 7171372 (cal) locale's default Calendar should be created if unknown calendar is specified >> >> Please note that packaging changes that relate to Jigsaw module system aren't included in this changeset. >> >> Naoto Sato and Masayoshi Okutsu From dalibor.topic at oracle.com Wed Aug 8 10:54:13 2012 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 08 Aug 2012 12:54:13 +0200 Subject: 7u6 mac os x build vs. test_gamma Message-ID: <50224555.2020603@oracle.com> $ export ALT_BOOTDIR=/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home $ time make | tee 7u6b23build.log [snip] Doing vm.make build: All done. cd bsd_amd64_compiler2/product && ./test_gamma Error occurred during initialization of VM java.lang.NullPointerException at java.util.Hashtable.put(Hashtable.java:432) at java.lang.System.initProperties(Native Method) at java.lang.System.initializeSystemClass(System.java:1115) Using java runtime at: /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre make[6]: *** [product] Error 1 make[5]: *** [generic_build2] Error 2 make[4]: *** [product] Error 2 make[3]: *** [all_product_universal] Error 2 make[2]: *** [universal_product] Error 2 make[1]: *** [hotspot-build] Error 2 make: *** [build_product_image] Error 2 real 43m59.056s user 16m47.436s sys 2m44.408s -> It seems like it's using the wrong java runtime to run test_gamma to begin with, right? cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From david.holmes at oracle.com Wed Aug 8 11:44:09 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 08 Aug 2012 21:44:09 +1000 Subject: 7u6 mac os x build vs. test_gamma In-Reply-To: <50224555.2020603@oracle.com> References: <50224555.2020603@oracle.com> Message-ID: <50225109.8000306@oracle.com> On 8/08/2012 8:54 PM, Dalibor Topic wrote: > $ export ALT_BOOTDIR=/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home > $ time make | tee 7u6b23build.log > [snip] > Doing vm.make build: > All done. > cd bsd_amd64_compiler2/product&& ./test_gamma > Error occurred during initialization of VM > java.lang.NullPointerException > at java.util.Hashtable.put(Hashtable.java:432) > at java.lang.System.initProperties(Native Method) > at java.lang.System.initializeSystemClass(System.java:1115) > > Using java runtime at: /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre > make[6]: *** [product] Error 1 > make[5]: *** [generic_build2] Error 2 > make[4]: *** [product] Error 2 > make[3]: *** [all_product_universal] Error 2 > make[2]: *** [universal_product] Error 2 > make[1]: *** [hotspot-build] Error 2 > make: *** [build_product_image] Error 2 > > real 43m59.056s > user 16m47.436s > sys 2m44.408s > > > -> It seems like it's using the wrong java runtime to run test_gamma to begin with, right? Right. After the hashtable changes the minimum requirement for the JDK runtime went up. David > cheers, > dalibor topic From ahughes at redhat.com Wed Aug 8 12:10:04 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Wed, 8 Aug 2012 08:10:04 -0400 (EDT) Subject: 7u6 mac os x build vs. test_gamma In-Reply-To: <50225109.8000306@oracle.com> Message-ID: <631279536.1871957.1344427804001.JavaMail.root@redhat.com> ----- Original Message ----- > On 8/08/2012 8:54 PM, Dalibor Topic wrote: > > $ export > > ALT_BOOTDIR=/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home > > $ time make | tee 7u6b23build.log > > [snip] > > Doing vm.make build: > > All done. > > cd bsd_amd64_compiler2/product&& ./test_gamma > > Error occurred during initialization of VM > > java.lang.NullPointerException > > at java.util.Hashtable.put(Hashtable.java:432) > > at java.lang.System.initProperties(Native Method) > > at java.lang.System.initializeSystemClass(System.java:1115) > > > > Using java runtime at: > > /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre > > make[6]: *** [product] Error 1 > > make[5]: *** [generic_build2] Error 2 > > make[4]: *** [product] Error 2 > > make[3]: *** [all_product_universal] Error 2 > > make[2]: *** [universal_product] Error 2 > > make[1]: *** [hotspot-build] Error 2 > > make: *** [build_product_image] Error 2 > > > > real 43m59.056s > > user 16m47.436s > > sys 2m44.408s > > > > > > -> It seems like it's using the wrong java runtime to run > > test_gamma to begin with, right? > > Right. After the hashtable changes the minimum requirement for the > JDK > runtime went up. > > David > > > > cheers, > > dalibor topic > This looks like the error I saw if the JDK has the newer java.lang.String: changeset: 5315:e1c679a00712 user: mduigou date: Thu May 17 10:06:19 2012 -0700 summary: 6924259: Remove offset and count fields from java.lang.String but HotSpot doesn't have support for it. Hit the same thing while getting the older Zero HotSpot to work with u6. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From dalibor.topic at oracle.com Wed Aug 8 14:44:04 2012 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 08 Aug 2012 16:44:04 +0200 Subject: 7u6 mac os x build vs. test_gamma In-Reply-To: <631279536.1871957.1344427804001.JavaMail.root@redhat.com> References: <631279536.1871957.1344427804001.JavaMail.root@redhat.com> Message-ID: <50227B34.4020104@oracle.com> On 8/8/12 2:10 PM, Andrew Hughes wrote: > ----- Original Message ----- >> On 8/08/2012 8:54 PM, Dalibor Topic wrote: >>> $ export >>> ALT_BOOTDIR=/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home >>> $ time make | tee 7u6b23build.log >>> [snip] >>> Doing vm.make build: >>> All done. >>> cd bsd_amd64_compiler2/product&& ./test_gamma >>> Error occurred during initialization of VM >>> java.lang.NullPointerException >>> at java.util.Hashtable.put(Hashtable.java:432) >>> at java.lang.System.initProperties(Native Method) >>> at java.lang.System.initializeSystemClass(System.java:1115) >>> >>> Using java runtime at: >>> /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre >>> make[6]: *** [product] Error 1 >>> make[5]: *** [generic_build2] Error 2 >>> make[4]: *** [product] Error 2 >>> make[3]: *** [all_product_universal] Error 2 >>> make[2]: *** [universal_product] Error 2 >>> make[1]: *** [hotspot-build] Error 2 >>> make: *** [build_product_image] Error 2 >>> >>> real 43m59.056s >>> user 16m47.436s >>> sys 2m44.408s >>> >>> >>> -> It seems like it's using the wrong java runtime to run >>> test_gamma to begin with, right? >> >> Right. After the hashtable changes the minimum requirement for the >> JDK >> runtime went up. >> >> David >> >> >>> cheers, >>> dalibor topic >> > > This looks like the error I saw if the JDK has the newer java.lang.String: > > changeset: 5315:e1c679a00712 > user: mduigou > date: Thu May 17 10:06:19 2012 -0700 > summary: 6924259: Remove offset and count fields from java.lang.String > > but HotSpot doesn't have support for it. Hit the same thing while getting > the older Zero HotSpot to work with u6. > Oddly enough, $ export LANG=C fixed it for the subsequent make clean && make run, which printed the same "Using java runtime at: /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jr" message after printing the test results, and carried on. I think we should document the export LANG=C setting in the Mac OS X section of the build README for 7u. cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From naoto.sato at oracle.com Wed Aug 8 21:13:42 2012 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 08 Aug 2012 14:13:42 -0700 Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data In-Reply-To: <5020E699.3000600@oracle.com> References: <4FFC93CF.40105@oracle.com> <5020E699.3000600@oracle.com> Message-ID: <5022D686.9070203@oracle.com> On 8/7/12 2:57 AM, Erik Joelsson wrote: > See inline > > On 2012-07-13 22:20, Kelly O'Hair wrote: >> Something seems strange here: >> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/make/java/java/localegen.sh.sdiff.html >> >> It's like someone was avoiding overall quotes, but using them to add >> spaces somehow... >> I sure would like to get rid of this shell logic, seems like there are >> lots repeated logic that >> this script does over and over or could be done with makefile pattern >> subst's instead of exec's. > The new version isn't any worse than the old in my opinion. In > build-infra, this file is indeed replaced with make logic. After having > decoded both versions I'm confident in converting the changes. >> Overall, just looking at the makefiles, the build-infra team may need >> some time to fully absorb this into the >> new makefiles, some of it will be trivial, not sure all of it will be. >> > I have applied the patch to a clone of build-infra and done the minimal > changes to keep build-infra building, which was rather trivial. The > resulting build has large differences since I haven't converted all of > it yet. There are a couple of things that will require some more work, > but not more than a day or two. >> Not sure how to proceed here, the build-infra team does need an action >> item to deal with this, maybe >> before it gets integrated because I suspect the new makefiles will >> break with all the filename or >> directory changes. But I hate to hold up your integration plans. > I see these as possible options: > > 1. Let this go in, build-infra will break in jdk8 until we do our next > push and it trickles through the repos. > 2. The build-infra project provides a patch with the full conversion > that can go in together with these changes. > 3. The build-infra project provides a simple patch which just keeps the > build-infra-build from failing that can go in with these changes. > > The conversion needs to happen regardless of option. The changes > required are pretty isolated from remaining build-infra work. What do > you think? Either way is fine with me. If build-infra team prefers 2 or 3, please give me the patch, and I will go ahead and merge them to my changeset. Naoto > > Other than that, I have no objections to the review. > > /Erik > >> I'd like to get some advice from Erik on this before saying anything >> further. >> >> -kto >> >> On Jul 10, 2012, at 1:42 PM, Naoto Sato wrote: >> >>> Hello, >>> >>> Please review the JDK8 changes for JEP 127: Improve Locale Data >>> Packaging and Adopt Unicode CLDR Data >>> (http://openjdk.java.net/jeps/127). The webrev is located at: >>> >>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/ >>> >>> The main bug id for this enhancement is: >>> >>> 6336885: RFE: Locale Data Deployment Enhancements >>> >>> Along with this, the following bugs/enhancements are also implemented >>> in this change: >>> >>> 4609153 Provide locale data for Indic locales >>> 5104387 Support for gl_ES locale (galician language) >>> 6337471 desktop/system locale preferences support >>> 7056139 (cal) SPI support for locale-dependent Calendar parameters >>> 7058206 Provide CalendarData SPI for week params and display field >>> value names >>> 7073852 Support multiple scripts for digits and decimal symbols per >>> locale >>> 7079560 [Fmt-Da] Context dependent month names support in >>> SimpleDateFormat >>> 7171324 getAvailableLocales() of locale sensitive services should >>> return the actual availability of locales >>> 7151414 (cal) Support calendar type identification >>> 7168528 LocaleServiceProvider needs to be aware of Locale extensions >>> 7171372 (cal) locale's default Calendar should be created if unknown >>> calendar is specified >>> >>> Please note that packaging changes that relate to Jigsaw module >>> system aren't included in this changeset. >>> >>> Naoto Sato and Masayoshi Okutsu From david.katleman at oracle.com Wed Aug 8 22:57:22 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 08 Aug 2012 22:57:22 +0000 Subject: hg: jdk8/build: Added tag jdk8-b50 for changeset 2fd67618b9a3 Message-ID: <20120808225722.4F98A47435@hg.openjdk.java.net> Changeset: 57c0aee73090 Author: katleman Date: 2012-08-02 15:32 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/57c0aee73090 Added tag jdk8-b50 for changeset 2fd67618b9a3 ! .hgtags From david.katleman at oracle.com Wed Aug 8 22:57:30 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 08 Aug 2012 22:57:30 +0000 Subject: hg: jdk8/build/corba: Added tag jdk8-b50 for changeset d20d9eb9f093 Message-ID: <20120808225731.128A547436@hg.openjdk.java.net> Changeset: 9b0f841ca9f7 Author: katleman Date: 2012-08-02 15:32 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/9b0f841ca9f7 Added tag jdk8-b50 for changeset d20d9eb9f093 ! .hgtags From david.katleman at oracle.com Wed Aug 8 22:59:34 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 08 Aug 2012 22:59:34 +0000 Subject: hg: jdk8/build/hotspot: 15 new changesets Message-ID: <20120808230006.4C54B47437@hg.openjdk.java.net> Changeset: c01c8e05ec8c Author: katleman Date: 2012-08-02 15:33 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c01c8e05ec8c Added tag jdk8-b50 for changeset 58f237a9e83a ! .hgtags Changeset: 86a687be3f02 Author: amurillo Date: 2012-07-27 16:51 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/86a687be3f02 7187463: new hotspot build - hs24-b19 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 594dff5e3c2e Author: johnc Date: 2012-07-17 11:52 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/594dff5e3c2e 7173712: G1: Duplicated code in G1UpdateRSOrPushRefOopClosure::do_oop_nv() Summary: Duplicated code from G1RemSet::par_write_ref() inlined into G1UpdateRSOrPushRefOopClosure::do_oop_nv() was showing up in profiles with a fairly high amount of CPU time. Manually inline the main part of G1RemSet::par_write_ref() to eliminate the code duplication. Reviewed-by: azeemj, brutisso ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp Changeset: d42fe3c3001d Author: johnc Date: 2012-07-17 14:57 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d42fe3c3001d 7184772: G1: Incorrect assert in HeapRegionLinkedList::add_as_head() Summary: Assertion incorrectly checks that _head is NULL and should be checking that _tail is NULL instead. Reviewed-by: johnc Contributed-by: Brandon Mitchell ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp Changeset: db823a892a55 Author: johnc Date: 2012-07-17 12:24 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/db823a892a55 7182260: G1: Fine grain RSet freeing bottleneck Summary: Chain the fine grain PerRegionTables in an individual RSet together and free them in bulk using a single operation. Reviewed-by: johnc, brutisso Contributed-by: Thomas Schatzl ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp Changeset: a2f7274eb6ef Author: tonyp Date: 2012-07-19 15:15 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a2f7274eb6ef 7114678: G1: various small fixes, code cleanup, and refactoring Summary: Various cleanups as a prelude to introducing iterators for HeapRegions. Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp Changeset: 113f4c73df61 Author: jmasa Date: 2012-07-24 14:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/113f4c73df61 Merge Changeset: 3080f4743cf2 Author: jmasa Date: 2012-07-26 23:43 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3080f4743cf2 Merge Changeset: ff58dfd5b977 Author: jmasa Date: 2012-07-27 21:41 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ff58dfd5b977 Merge Changeset: 3b01d0321dfa Author: zgu Date: 2012-07-30 10:25 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3b01d0321dfa 7186778: MachO decoder implementation for MacOSX Summary: Implementation of decoder for Apple's MacOSX. The implementation is based on the patch provided by Kevin Walls. Reviewed-by: coleenp, kamg, kevinw ! src/os/bsd/vm/decoder_machO.cpp ! src/os/bsd/vm/decoder_machO.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/decoder_windows.hpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/decoder_elf.hpp Changeset: 4bfef6df8881 Author: zgu Date: 2012-07-30 07:21 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4bfef6df8881 Merge Changeset: 5e2dc722e70d Author: andrew Date: 2012-07-31 16:01 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5e2dc722e70d 7186278: Build error after CR#6995781 / 7151532 with GCC 4.7.0 Summary: Templates need this object if not using template parameter in call Reviewed-by: coleenp, kamg, dholmes ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: e37a5219e297 Author: dcubed Date: 2012-07-31 18:37 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e37a5219e297 Merge Changeset: 3b3ad1642970 Author: amurillo Date: 2012-08-03 13:13 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3b3ad1642970 Merge Changeset: 663fc23da8d5 Author: amurillo Date: 2012-08-03 13:13 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/663fc23da8d5 Added tag hs24-b19 for changeset 3b3ad1642970 ! .hgtags From david.katleman at oracle.com Wed Aug 8 23:02:29 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 08 Aug 2012 23:02:29 +0000 Subject: hg: jdk8/build/jaxp: Added tag jdk8-b50 for changeset 2791ec55f66b Message-ID: <20120808230232.5FCF147438@hg.openjdk.java.net> Changeset: dc1ea77ed9d9 Author: katleman Date: 2012-08-02 15:35 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/dc1ea77ed9d9 Added tag jdk8-b50 for changeset 2791ec55f66b ! .hgtags From david.katleman at oracle.com Wed Aug 8 23:02:50 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 08 Aug 2012 23:02:50 +0000 Subject: hg: jdk8/build/jaxws: Added tag jdk8-b50 for changeset bdab72e87b83 Message-ID: <20120808230253.1A5F547439@hg.openjdk.java.net> Changeset: 1a70b6333ebe Author: katleman Date: 2012-08-02 15:35 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/1a70b6333ebe Added tag jdk8-b50 for changeset bdab72e87b83 ! .hgtags From david.katleman at oracle.com Wed Aug 8 23:04:02 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 08 Aug 2012 23:04:02 +0000 Subject: hg: jdk8/build/jdk: 30 new changesets Message-ID: <20120808230916.4F24E4743A@hg.openjdk.java.net> Changeset: 79c9847d4a5f Author: katleman Date: 2012-08-02 15:36 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/79c9847d4a5f Added tag jdk8-b50 for changeset e4bae5c53fca ! .hgtags Changeset: 28665fa73b4a Author: rupashka Date: 2012-07-19 19:09 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/28665fa73b4a 7124330: [macosx] javax.swing.JComboBox throws unexpected ClassCastException Reviewed-by: kizune ! src/macosx/classes/com/apple/laf/AquaComboBoxUI.java Changeset: b1c5e4a843f3 Author: leonidr Date: 2012-07-19 19:41 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b1c5e4a843f3 7181027: [macosx] Unable to use headless mode Reviewed-by: anthony ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/solaris/native/java/lang/java_props_md.c Changeset: f04d8dee2da9 Author: alexsch Date: 2012-07-23 17:41 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f04d8dee2da9 7185512: The printout doesn't match image on screen. Reviewed-by: serb, bagiras ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextComponent.h Changeset: 8a5a71e853ed Author: alexsch Date: 2012-07-24 16:26 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/8a5a71e853ed 7129800: [macosx] Regression test OverrideRedirectWindowActivationTest fails due to timing issue Reviewed-by: rupashka + test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java Changeset: 3502753a9d66 Author: rupashka Date: 2012-07-25 13:41 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3502753a9d66 7167780: Hang javasoft.sqe.tests.api.javax.swing.Timer.Ctor2Tests Reviewed-by: alexsch ! src/share/classes/javax/swing/TimerQueue.java Changeset: 1a410846d85b Author: malenkov Date: 2012-07-25 19:14 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1a410846d85b 4650871: Classes in sunw.* should be removed from workspace and rt.jar Reviewed-by: art, rupashka ! make/Makefile ! make/common/Release.gmk ! make/docs/CORE_PKGS.gmk - make/sunw/Makefile ! makefiles/CreateJars.gmk ! makefiles/docs/CORE_PKGS.gmk ! src/share/classes/sun/misc/MetaIndex.java - src/share/classes/sunw/io/Serializable.java - src/share/classes/sunw/util/EventListener.java - src/share/classes/sunw/util/EventObject.java Changeset: 80b1ecc79852 Author: denis Date: 2012-07-27 19:41 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/80b1ecc79852 7149068: java/awt/Window/Grab/GrabTest.java failed Reviewed-by: art, ant + test/java/awt/Window/Grab/GrabTest.java Changeset: 1579507a736f Author: lana Date: 2012-07-27 22:39 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1579507a736f Merge - src/share/classes/sun/security/krb5/ServiceName.java - test/sun/security/krb5/ServiceNameClone.java - test/sun/security/mscapi/ShortRSAKey512.sh - test/sun/security/mscapi/ShortRSAKey768.sh Changeset: 1abb270d9038 Author: malenkov Date: 2012-07-30 13:35 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1abb270d9038 7187618: PropertyDescriptor Performance Slow Reviewed-by: rupashka ! src/share/classes/com/sun/beans/TypeResolver.java ! src/share/classes/com/sun/beans/finder/MethodFinder.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Performance/Test7122740.java + test/java/beans/Performance/Test7184799.java Changeset: 896322c6f35f Author: alexsch Date: 2012-07-30 14:31 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/896322c6f35f 7184365: closed/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest fails Reviewed-by: serb, bagiras ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/share/classes/java/awt/TextComponent.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java + test/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest.java Changeset: 773474da570b Author: khazra Date: 2012-07-18 15:19 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/773474da570b 7185051: Remove TestProviderLeak.java from the ProblemList Summary: Remove TestProviderLeak.java from jdk test problem list. Reviewed-by: khazra Contributed-by: dan.xu at oracle.com ! test/ProblemList.txt Changeset: 2c2e4ecc8f7e Author: chegar Date: 2012-07-19 18:19 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/2c2e4ecc8f7e 7081476: test/java/net/InetSocketAddress/B6469803.java failing intermittently Reviewed-by: chegar Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/net/DatagramPacket/ReuseBuf.java Changeset: 84cd98a5641c Author: sherman Date: 2012-07-19 21:23 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/84cd98a5641c 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X Summary: to support Unicode nfd/nfc file path on Macos Reviewed-by: alanb ! make/java/nio/Makefile ! src/share/native/java/io/io_util.h ! src/solaris/classes/sun/nio/fs/BsdNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java + src/solaris/classes/sun/nio/fs/MacOSXFileSystem.java + src/solaris/classes/sun/nio/fs/MacOSXFileSystemProvider.java + src/solaris/classes/sun/nio/fs/MacOSXNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixFileSystem.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/native/java/io/UnixFileSystem_md.c ! src/solaris/native/java/io/io_util_md.c ! src/solaris/native/java/io/io_util_md.h + src/solaris/native/sun/nio/fs/MacOSXNativeDispatcher.c + test/java/io/File/MacPathTest.java + test/java/io/File/MacPathTest.sh + test/java/nio/file/Path/MacPathTest.java + test/java/nio/file/Path/MacPathTest.sh Changeset: 5dc3f32c0d26 Author: weijun Date: 2012-07-21 19:56 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5dc3f32c0d26 7180907: Jarsigner -verify fails if rsa file used sha-256 with authenticated attributes Reviewed-by: xuelei ! src/share/classes/com/sun/crypto/provider/OAEPParameters.java ! src/share/classes/sun/security/pkcs/PKCS7.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! src/share/classes/sun/security/x509/AlgorithmId.java + test/sun/security/x509/AlgorithmId/NonStandardNames.java Changeset: 7e49c6f7507e Author: weijun Date: 2012-07-21 19:56 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/7e49c6f7507e 7178649: TEST BUG: BadKdc3.java needs improvement to ignore the unlikely but possible timeout Reviewed-by: xuelei ! test/sun/security/krb5/auto/BadKdc.java ! test/sun/security/krb5/auto/BadKdc1.java ! test/sun/security/krb5/auto/BadKdc2.java ! test/sun/security/krb5/auto/BadKdc3.java ! test/sun/security/krb5/auto/BadKdc4.java Changeset: 11d5ddc6a6d4 Author: alanb Date: 2012-07-22 20:32 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/11d5ddc6a6d4 6633549: (dc) Include-mode filtering of IPv6 sources does not block datagrams on Linux Reviewed-by: chegar ! src/solaris/native/sun/nio/ch/DatagramDispatcher.c ! src/solaris/native/sun/nio/ch/Net.c ! test/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java Changeset: f7731fc8c98a Author: weijun Date: 2012-07-24 09:20 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f7731fc8c98a 7179796: GSSExceptionImpl outputs duplicate mech oid Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/GSSCredentialImpl.java Changeset: e0e7cc711bda Author: xuelei Date: 2012-07-24 03:31 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e0e7cc711bda 7185576: Need to consider the connection timeout at test/com/sun/jndi/ldap/InvalidLdapFilters.java Reviewed-by: vinnie ! test/com/sun/jndi/ldap/InvalidLdapFilters.java Changeset: a18f2806bef2 Author: sherman Date: 2012-07-24 12:17 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a18f2806bef2 6653797: Reimplement JDK charset repository charsets.jar Summary: Migrated all jis based charsets to new implementation Reviewed-by: okutsu ! make/java/nio/FILES_java.gmk ! make/java/sun_nio/FILES_java.gmk ! make/sun/nio/cs/FILES_java.gmk ! make/tools/CharsetMapping/DoubleByte-X.java.template + make/tools/CharsetMapping/JIS_X_0201.c2b ! make/tools/CharsetMapping/JIS_X_0201.map + make/tools/CharsetMapping/JIS_X_0208.map + make/tools/CharsetMapping/JIS_X_0208_MS5022X.c2b + make/tools/CharsetMapping/JIS_X_0208_MS5022X.map + make/tools/CharsetMapping/JIS_X_0208_MS932.map + make/tools/CharsetMapping/JIS_X_0208_MS932.nr + make/tools/CharsetMapping/JIS_X_0208_Solaris.map + make/tools/CharsetMapping/JIS_X_0208_Solaris.nr + make/tools/CharsetMapping/JIS_X_0212.map + make/tools/CharsetMapping/JIS_X_0212_MS5022X.map + make/tools/CharsetMapping/JIS_X_0212_Solaris.map + make/tools/CharsetMapping/JIS_X_0212_Solaris.nr + make/tools/CharsetMapping/PCK.c2b + make/tools/CharsetMapping/PCK.map + make/tools/CharsetMapping/PCK.nr + make/tools/CharsetMapping/SJIS.c2b + make/tools/CharsetMapping/SJIS.map ! make/tools/CharsetMapping/dbcs ! make/tools/CharsetMapping/extsbcs ! make/tools/src/build/tools/charsetmapping/DBCS.java ! make/tools/src/build/tools/charsetmapping/SBCS.java ! src/share/classes/sun/nio/cs/SingleByte.java - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java ! src/share/classes/sun/nio/cs/ext/DoubleByte.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java ! src/share/classes/sun/nio/cs/ext/EUC_JP.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_Open.java ! src/share/classes/sun/nio/cs/ext/IBM834.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP_2.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java ! src/share/classes/sun/nio/cs/ext/MS50220.java ! src/share/classes/sun/nio/cs/ext/MS50221.java ! src/share/classes/sun/nio/cs/ext/MSISO2022JP.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java ! src/solaris/classes/sun/awt/motif/X11JIS0201.java ! src/solaris/classes/sun/awt/motif/X11JIS0208.java ! src/solaris/classes/sun/awt/motif/X11JIS0212.java ! test/java/nio/charset/Charset/NIOCharsetAvailabilityTest.java ! test/sun/nio/cs/OLD/DoubleByteDecoder.java ! test/sun/nio/cs/OLD/DoubleByteEncoder.java + test/sun/nio/cs/OLD/EUC_JP_LINUX_OLD.java + test/sun/nio/cs/OLD/EUC_JP_OLD.java + test/sun/nio/cs/OLD/EUC_JP_Open_OLD.java + test/sun/nio/cs/OLD/JIS_X_0201_OLD.java + test/sun/nio/cs/OLD/JIS_X_0208_Decoder.java + test/sun/nio/cs/OLD/JIS_X_0208_Encoder.java + test/sun/nio/cs/OLD/JIS_X_0208_OLD.java + test/sun/nio/cs/OLD/JIS_X_0208_Solaris_Decoder.java + test/sun/nio/cs/OLD/JIS_X_0208_Solaris_Encoder.java + test/sun/nio/cs/OLD/JIS_X_0212_Decoder.java + test/sun/nio/cs/OLD/JIS_X_0212_Encoder.java + test/sun/nio/cs/OLD/JIS_X_0212_OLD.java + test/sun/nio/cs/OLD/JIS_X_0212_Solaris_Decoder.java + test/sun/nio/cs/OLD/JIS_X_0212_Solaris_Encoder.java ! test/sun/nio/cs/OLD/MS932_OLD.java + test/sun/nio/cs/OLD/PCK_OLD.java + test/sun/nio/cs/OLD/SJIS_OLD.java + test/sun/nio/cs/OLD/SingleByteDecoder.java + test/sun/nio/cs/OLD/SingleByteEncoder.java ! test/sun/nio/cs/OLD/TestIBMDB.java ! test/sun/nio/cs/TestX11JIS0201.java Changeset: 74ceda3a98a0 Author: khazra Date: 2012-07-24 13:38 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/74ceda3a98a0 7184287: (prefs) BackingStoreException when calling flush on root node[macosx] Summary: Change implementation to enable user without administrative privileges to call flush Reviewed-by: alanb ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! test/ProblemList.txt Changeset: 42eac77355d2 Author: sherman Date: 2012-07-25 12:47 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/42eac77355d2 7186829: test/sun/nio/cs/OLD/JIS_X_0201_OLD.java failed in jdk8 TL nightly build Summary: fixed the test case Reviewed-by: alanb ! test/sun/nio/cs/OLD/JIS_X_0201_OLD.java Changeset: f267302093d4 Author: weijun Date: 2012-07-26 20:38 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f267302093d4 7187051: ShortRSAKeynnn.sh tests should do cleanup before start test Reviewed-by: xuelei ! test/sun/security/mscapi/ShortRSAKey1024.sh Changeset: 35fec642fd32 Author: coffeys Date: 2012-07-26 22:00 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/35fec642fd32 7179879: SSLSocket connect times out instead of throwing socket closed exception Reviewed-by: xuelei, chegar ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: 018e555a7a07 Author: dmocek Date: 2012-07-27 16:53 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/018e555a7a07 7186111: fix bugs in java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup Reviewed-by: smarks, jgish ! test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/group.security.policy ! test/java/rmi/activation/ActivationSystem/unregisterGroup/rmid.security.policy ! test/java/rmi/activation/ActivationSystem/unregisterGroup/security.policy Changeset: a093f6247b52 Author: lana Date: 2012-07-27 22:26 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a093f6247b52 Merge Changeset: 78644d4a9a32 Author: dxu Date: 2012-07-30 04:57 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/78644d4a9a32 7185340: TEST_BUG: java/nio/channels/AsynchronousSocketChannel/Leaky.java failing intermittently [win] Reviewed-by: alanb ! test/java/nio/channels/AsynchronousSocketChannel/Leaky.java Changeset: 38263aa28324 Author: michaelm Date: 2012-07-30 22:32 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/38263aa28324 7120665: Change Java SE spec so that external networking not required Reviewed-by: alanb ! src/share/classes/java/net/NetworkInterface.java ! src/share/classes/java/net/package.html Changeset: b08697af1c56 Author: lana Date: 2012-07-31 18:38 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b08697af1c56 Merge - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java Changeset: e865efbc7105 Author: lana Date: 2012-08-06 15:53 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e865efbc7105 Merge - make/sunw/Makefile - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java - src/share/classes/sunw/io/Serializable.java - src/share/classes/sunw/util/EventListener.java - src/share/classes/sunw/util/EventObject.java From omajid at redhat.com Wed Aug 8 23:08:10 2012 From: omajid at redhat.com (Omair Majid) Date: Wed, 08 Aug 2012 19:08:10 -0400 Subject: [PATCH] Update RPATH to make loading libjawt possible (was: Re: RPATHS in binaries) In-Reply-To: <500D6B6A.6070606@oracle.COM> References: <50083A53.1040103@redhat.com> <3663E5CA-DC24-4E7A-9C1F-EED4F2E59535@oracle.com> <50088B16.2070709@redhat.com> <500D6B6A.6070606@oracle.COM> Message-ID: <5022F15A.7060209@redhat.com> Hi Kumar, On 07/23/2012 11:19 AM, Kumar Srinivasan wrote: > My suggestion is to see if System.loadLibrary can be used, this will > bode well for the modularization effort. I discussed this with the folks at awt-dev and they would prefer to avoid loading as much as possible. They are strongly against always preloading libjawt.so. > If this *must* be added to RPATH in which case, append this last to > ensure we don't break anything. Yes, the awt folks have asked me to use this approach. The attached patch updates the RPATH in the launchers to add the arch dir to RPATH. A couple of questions: 1. I am not sure if this problem exists on windows or on other operating systems and what sort of fixes are appropriate there. How do I deal with this? 2. This patch uses RPATH (and not RUNPATH). This makes it impossible to use LD_LIBRARY_PATH to override the linker path. I don't see any potential dangerous effects (pretty much all libraries in the have an RPATH), and I suspect it's even intentional (so JDK6 can exec JDK7 with an LD_LIBRARY_PATH set and things will continue working). Does OpenJDK support platforms with RUNPATH (-Wl,--enable-new-dtags) ? 3. I cant seem to get http://hg.openjdk.java.net/jdk8/build to build. It seems to be missing a number of fixes needed to build with newer versions of gcc and glibc. The patch applies to both jdk8/build and jdk7u/jdk7u-dev. I have only build with 7. Thanks, Omair From david.katleman at oracle.com Wed Aug 8 23:13:22 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 08 Aug 2012 23:13:22 +0000 Subject: hg: jdk8/build/langtools: Added tag jdk8-b50 for changeset b2d8a270f5f2 Message-ID: <20120808231324.AB7CF4743C@hg.openjdk.java.net> Changeset: c4cd4cab2220 Author: katleman Date: 2012-08-02 15:37 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/c4cd4cab2220 Added tag jdk8-b50 for changeset b2d8a270f5f2 ! .hgtags From ahughes at redhat.com Thu Aug 9 11:15:54 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Thu, 9 Aug 2012 07:15:54 -0400 (EDT) Subject: [PATCH] Update RPATH to make loading libjawt possible (was: Re: RPATHS in binaries) In-Reply-To: <5022F15A.7060209@redhat.com> Message-ID: <2050199910.2465202.1344510954312.JavaMail.root@redhat.com> ----- Original Message ----- > Hi Kumar, > > On 07/23/2012 11:19 AM, Kumar Srinivasan wrote: > > My suggestion is to see if System.loadLibrary can be used, this > > will > > bode well for the modularization effort. > > I discussed this with the folks at awt-dev and they would prefer to > avoid loading as much as possible. They are strongly against always > preloading libjawt.so. > For my 2c, I'm against it too. It doesn't seem the right fix. > > If this *must* be added to RPATH in which case, append this last > > to > > ensure we don't break anything. > > Yes, the awt folks have asked me to use this approach. The attached > patch updates the RPATH in the launchers to add the arch dir to > RPATH. > I don't see an attachment :-( Shouldn't it be a webrev anyway? > A couple of questions: > > 1. I am not sure if this problem exists on windows or on other > operating > systems and what sort of fixes are appropriate there. How do I deal > with > this? Worry about it if someone reports issues there? :-D I guess some kind person at Oracle could build and test there... > > 2. This patch uses RPATH (and not RUNPATH). This makes it impossible > to > use LD_LIBRARY_PATH to override the linker path. I don't see any > potential dangerous effects (pretty much all libraries in the have an > RPATH), and I suspect it's even intentional (so JDK6 can exec JDK7 > with > an LD_LIBRARY_PATH set and things will continue working). Does > OpenJDK > support platforms with RUNPATH (-Wl,--enable-new-dtags) ? > > 3. I cant seem to get http://hg.openjdk.java.net/jdk8/build to build. > It > seems to be missing a number of fixes needed to build with newer > versions of gcc and glibc. The patch applies to both jdk8/build and > jdk7u/jdk7u-dev. I have only build with 7. > I built jdk8/build successfully just last week. What issues are you seeing? You can always push to a different 8 tree which builds, I guess. > Thanks, > Omair > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From kumar.x.srinivasan at oracle.COM Thu Aug 9 12:39:55 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Thu, 09 Aug 2012 05:39:55 -0700 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <5022F15A.7060209@redhat.com> References: <50083A53.1040103@redhat.com> <3663E5CA-DC24-4E7A-9C1F-EED4F2E59535@oracle.com> <50088B16.2070709@redhat.com> <500D6B6A.6070606@oracle.COM> <5022F15A.7060209@redhat.com> Message-ID: <5023AF9B.6090301@oracle.COM> Hello Omair, > Hi Kumar, > > On 07/23/2012 11:19 AM, Kumar Srinivasan wrote: >> My suggestion is to see if System.loadLibrary can be used, this will >> bode well for the modularization effort. > I discussed this with the folks at awt-dev and they would prefer to > avoid loading as much as possible. They are strongly against always > preloading libjawt.so. > >> If this *must* be added to RPATH in which case, append this last to >> ensure we don't break anything. > Yes, the awt folks have asked me to use this approach. The attached > patch updates the RPATH in the launchers to add the arch dir to RPATH. > > A couple of questions: > > 1. I am not sure if this problem exists on windows or on other operating > systems and what sort of fixes are appropriate there. How do I deal with > this?e No on window the %PATH% variable is used to load all dynamic libraries. > > 2. This patch uses RPATH (and not RUNPATH). This makes it impossible to > use LD_LIBRARY_PATH to override the linker path. I don't see any > potential dangerous effects (pretty much all libraries in the have an > RPATH), and I suspect it's even intentional (so JDK6 can exec JDK7 with > an LD_LIBRARY_PATH set and things will continue working). Does OpenJDK > support platforms with RUNPATH (-Wl,--enable-new-dtags) ? Yes if jdk6 is used to exec jdk7+, the launcher will set the LD_LIBRARY_PATH to protects itself from jdk6's LLP, and exec itself. Please see http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/d8dfd1a0bd8d I don't know what --enable-new-dtags is and what it does. > > 3. I cant seem to get http://hg.openjdk.java.net/jdk8/build to build. It > seems to be missing a number of fixes needed to build with newer > versions of gcc and glibc. The patch applies to both jdk8/build and > jdk7u/jdk7u-dev. I have only build with 7. jdk8 will need to be built and tested with your changes!. I will try to apply your patch and submit it to our build system, when I get a spare cycle. Thanks Kumar > > Thanks, > Omair From aph at redhat.com Thu Aug 9 13:58:20 2012 From: aph at redhat.com (Andrew Haley) Date: Thu, 09 Aug 2012 14:58:20 +0100 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <5023AF9B.6090301@oracle.COM> References: <50083A53.1040103@redhat.com> <3663E5CA-DC24-4E7A-9C1F-EED4F2E59535@oracle.com> <50088B16.2070709@redhat.com> <500D6B6A.6070606@oracle.COM> <5022F15A.7060209@redhat.com> <5023AF9B.6090301@oracle.COM> Message-ID: <5023C1FC.2050200@redhat.com> On 08/09/2012 01:39 PM, Kumar Srinivasan wrote: >> 2. This patch uses RPATH (and not RUNPATH). This makes it impossible to >> > use LD_LIBRARY_PATH to override the linker path. I don't see any >> > potential dangerous effects (pretty much all libraries in the have an >> > RPATH), and I suspect it's even intentional (so JDK6 can exec JDK7 with >> > an LD_LIBRARY_PATH set and things will continue working). Does OpenJDK >> > support platforms with RUNPATH (-Wl,--enable-new-dtags) ? > > Yes if jdk6 is used to exec jdk7+, the launcher will set the > LD_LIBRARY_PATH to > protects itself from jdk6's LLP, and exec itself. > > Please see > http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/d8dfd1a0bd8d > > I don't know what --enable-new-dtags is and what it does. RPATH has been deprecated for more than ten years. See man ld,so(8): o (ELF only) Using the directories specified in the DT_RPATH dynamic section attribute of the binary if present and DT_RUNPATH attribute does not exist. Use of DT_RPATH is deprecated. DT_RUNPATH is the modern equivalent, and it's what you get if you use --enable-new-dtags . Andrew. From omajid at redhat.com Thu Aug 9 21:48:02 2012 From: omajid at redhat.com (Omair Majid) Date: Thu, 09 Aug 2012 17:48:02 -0400 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <2050199910.2465202.1344510954312.JavaMail.root@redhat.com> References: <2050199910.2465202.1344510954312.JavaMail.root@redhat.com> Message-ID: <50243012.6010300@redhat.com> On 08/09/2012 07:15 AM, Andrew Hughes wrote: > ----- Original Message ----- >> Hi Kumar, >> >> On 07/23/2012 11:19 AM, Kumar Srinivasan wrote: >>> My suggestion is to see if System.loadLibrary can be used, this >>> will >>> bode well for the modularization effort. >> >> I discussed this with the folks at awt-dev and they would prefer to >> avoid loading as much as possible. They are strongly against always >> preloading libjawt.so. >> > > For my 2c, I'm against it too. It doesn't seem the right fix. I can see your point, but both the solutions feel wrong to me. I can't make up my mind which is the less bad. > I don't see an attachment :-( I guess the mailing list software stripped it out. I did attach it. > Shouldn't it be a webrev anyway? Old habits :) Webrev is at: http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/00/ I have also put up a test case at: http://cr.openjdk.java.net/~omajid/jawt-test.tar.gz The test case is the exact same as that on http://download.java.net/jdk8/docs/technotes/guides/awt/AWT_Native_Interface.html, except it automates the building and running. You will have to edit the makefile to set the value of JDK_HOME. It should point to a j2sdk-image directory. Then do: $ make $ make run Without the fix it should print an UnsatisfiedLinkError. With the fix, it should show a window. > I built jdk8/build successfully just last week. What issues are you seeing? Errors building hotspot, I seem to recall. But I cant reproduce it anymore after pulling today. I can now confirm that the fix works for me with jdk8 too. Thanks, Omair From kelly.ohair at oracle.com Fri Aug 10 01:00:06 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 9 Aug 2012 18:00:06 -0700 Subject: jdk builds on the mac In-Reply-To: <501F8F72.4060205@oracle.com> References: <041963DD-5D06-4CDB-8E23-0FEC94DAAC1B@oracle.com> <501310E5.2070007@oracle.COM> <501F8F72.4060205@oracle.com> Message-ID: I think we need to make sure that the only thing that gets built with the bootjdk javac is the langtools bootstrap javac.jar, all other javac compilations needs to be done by the bootstrap javac. Does that fix this issue? -kto On Aug 6, 2012, at 2:33 AM, Erik Joelsson wrote: > The classpath reference was added on my request for build-infra. The reason was to get javax.annotation.GenerateNativeHeader on the classpath. The javac used in that ant script is the bootjdk javac, which usually doesn't provide the annotation. I suppose the correct fix would be to change the ant script to use the bootstrap javac instead. > > /Erik > > On 2012-07-28 00:06, Kumar Srinivasan wrote: >> On 7/25/2012 2:23 PM, Kelly O'Hair wrote: >>> Naoto has noticed this build failure on the Mac (just the Mac) when building just the jdk repository. >>> >>> From what I can tell, the Mac build of the jdk repository now depends on the langtools repository also >>> being built, which means that partial builds of just the jdk repository will no longer work on the Mac? >>> There is an ant script at jdk/src/macosx/native/jobjc/build.xml that has a baked in classpath reference to >>> ../../langtools/dist/lib/classes.jar >>> >>> Has anyone seen this, or have any additional information on it? >> >> This is preventing me to test certain things I can only run from a jdk build under >> jprt on the macosx machine. >> >> Kumar >> >>> >>> -kto >>> >>> ------------------------------------------------------------------------------ >>> build-core: >>> [mkdir] Created dir: /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core >>> [javac] com/apple/jobjc/PrimitiveCoder.java added as com/apple/jobjc/PrimitiveCoder.class doesn't exist. >>> [javac] Compiling 1 source file to /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core >>> [javac] Using modern compiler >>> dropping /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/langtools/dist/lib/classes.jar from path as it doesn't exist >>> [javac] Compilation arguments: >>> [javac] '-d' >>> [javac] '/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core' >>> [javac] '-classpath' >>> [javac] '/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core' >>> [javac] '-sourcepath' >>> [javac] '/private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java' >>> [javac] '-target' >>> [javac] '1.5' >>> [javac] '-g' >>> [javac] '-source' >>> [javac] '1.5' >>> [javac] >>> [javac] The ' characters around the executable and arguments are >>> [javac] not part of the command. >>> [javac] File to be compiled: >>> [javac] /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/PrimitiveCoder.java >>> [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.5 >>> [javac] /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java:32: warning: Unsafe is internal proprietary API and may be removed in a future release >>> [javac] import sun.misc.Unsafe; >>> [javac] ^ >>> >>> ..... >>> >>> [javac] @GenerateNativeHeader >>> [javac] ^ >>> [javac] symbol: class GenerateNativeHeader >>> [javac] Note: Some input files use unchecked or unsafe operations. >>> [javac] Note: Recompile with -Xlint:unchecked for details. >>> [javac] 61 errors >>> [javac] 7 warnings >>> >>> BUILD FAILED >>> /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/build.xml:143: Compile failed; see the compiler error output for details. >>> at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:1079) >>> at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:882) >>> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) >>> at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) >>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:601) >>> at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) >>> at org.apache.tools.ant.Task.perform(Task.java:348) >>> at org.apache.tools.ant.Target.execute(Target.java:357) >>> at org.apache.tools.ant.Target.performTasks(Target.java:385) >>> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) >>> at org.apache.tools.ant.Project.executeTarget(Project.java:1306) >>> at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) >>> at org.apache.tools.ant.Project.executeTargets(Project.java:1189) >>> at org.apache.tools.ant.Main.runBuild(Main.java:758) >>> at org.apache.tools.ant.Main.startAnt(Main.java:217) >>> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) >>> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) >>> >>> Total time: 1 second >>> make[2]: *** [../../../build/macosx-x86_64/JObjC.build/JObjC.jar] Error 1 >>> make[1]: *** [all] Error 1 >>> make: *** [all] Error 1 >> From erik.joelsson at oracle.com Fri Aug 10 05:39:35 2012 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 10 Aug 2012 07:39:35 +0200 Subject: jdk builds on the mac In-Reply-To: References: <041963DD-5D06-4CDB-8E23-0FEC94DAAC1B@oracle.com> <501310E5.2070007@oracle.COM> <501F8F72.4060205@oracle.com> Message-ID: <50249E97.4090409@oracle.com> It does and I believe Joel, in the langtools team, is looking at this issue. /Erik On 2012-08-10 03:00, Kelly O'Hair wrote: > I think we need to make sure that the only thing that gets built with the bootjdk javac is the langtools > bootstrap javac.jar, all other javac compilations needs to be done by the bootstrap javac. > Does that fix this issue? > > -kto > > On Aug 6, 2012, at 2:33 AM, Erik Joelsson wrote: > >> The classpath reference was added on my request for build-infra. The reason was to get javax.annotation.GenerateNativeHeader on the classpath. The javac used in that ant script is the bootjdk javac, which usually doesn't provide the annotation. I suppose the correct fix would be to change the ant script to use the bootstrap javac instead. >> >> /Erik >> >> On 2012-07-28 00:06, Kumar Srinivasan wrote: >>> On 7/25/2012 2:23 PM, Kelly O'Hair wrote: >>>> Naoto has noticed this build failure on the Mac (just the Mac) when building just the jdk repository. >>>> >>>> From what I can tell, the Mac build of the jdk repository now depends on the langtools repository also >>>> being built, which means that partial builds of just the jdk repository will no longer work on the Mac? >>>> There is an ant script at jdk/src/macosx/native/jobjc/build.xml that has a baked in classpath reference to >>>> ../../langtools/dist/lib/classes.jar >>>> >>>> Has anyone seen this, or have any additional information on it? >>> This is preventing me to test certain things I can only run from a jdk build under >>> jprt on the macosx machine. >>> >>> Kumar >>> >>>> -kto >>>> >>>> ------------------------------------------------------------------------------ >>>> build-core: >>>> [mkdir] Created dir: /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core >>>> [javac] com/apple/jobjc/PrimitiveCoder.java added as com/apple/jobjc/PrimitiveCoder.class doesn't exist. >>>> [javac] Compiling 1 source file to /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core >>>> [javac] Using modern compiler >>>> dropping /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/langtools/dist/lib/classes.jar from path as it doesn't exist >>>> [javac] Compilation arguments: >>>> [javac] '-d' >>>> [javac] '/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core' >>>> [javac] '-classpath' >>>> [javac] '/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core' >>>> [javac] '-sourcepath' >>>> [javac] '/private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java' >>>> [javac] '-target' >>>> [javac] '1.5' >>>> [javac] '-g' >>>> [javac] '-source' >>>> [javac] '1.5' >>>> [javac] >>>> [javac] The ' characters around the executable and arguments are >>>> [javac] not part of the command. >>>> [javac] File to be compiled: >>>> [javac] /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/PrimitiveCoder.java >>>> [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.5 >>>> [javac] /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java:32: warning: Unsafe is internal proprietary API and may be removed in a future release >>>> [javac] import sun.misc.Unsafe; >>>> [javac] ^ >>>> >>>> ..... >>>> >>>> [javac] @GenerateNativeHeader >>>> [javac] ^ >>>> [javac] symbol: class GenerateNativeHeader >>>> [javac] Note: Some input files use unchecked or unsafe operations. >>>> [javac] Note: Recompile with -Xlint:unchecked for details. >>>> [javac] 61 errors >>>> [javac] 7 warnings >>>> >>>> BUILD FAILED >>>> /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/build.xml:143: Compile failed; see the compiler error output for details. >>>> at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:1079) >>>> at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:882) >>>> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) >>>> at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) >>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> at java.lang.reflect.Method.invoke(Method.java:601) >>>> at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) >>>> at org.apache.tools.ant.Task.perform(Task.java:348) >>>> at org.apache.tools.ant.Target.execute(Target.java:357) >>>> at org.apache.tools.ant.Target.performTasks(Target.java:385) >>>> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) >>>> at org.apache.tools.ant.Project.executeTarget(Project.java:1306) >>>> at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) >>>> at org.apache.tools.ant.Project.executeTargets(Project.java:1189) >>>> at org.apache.tools.ant.Main.runBuild(Main.java:758) >>>> at org.apache.tools.ant.Main.startAnt(Main.java:217) >>>> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) >>>> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) >>>> >>>> Total time: 1 second >>>> make[2]: *** [../../../build/macosx-x86_64/JObjC.build/JObjC.jar] Error 1 >>>> make[1]: *** [all] Error 1 >>>> make: *** [all] Error 1 From anthony.petrov at oracle.com Fri Aug 10 08:51:30 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 10 Aug 2012 12:51:30 +0400 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <50243012.6010300@redhat.com> References: <2050199910.2465202.1344510954312.JavaMail.root@redhat.com> <50243012.6010300@redhat.com> Message-ID: <5024CB92.6000407@oracle.com> Hi Omair, The fix looks good to me. I think Kumar needs to take a look at it, too, before the fix can be pushed to a repo. Thanks for finding and fixing this issue. -- best regards, Anthony On 8/10/2012 1:48 AM, Omair Majid wrote: > On 08/09/2012 07:15 AM, Andrew Hughes wrote: >> ----- Original Message ----- >>> Hi Kumar, >>> >>> On 07/23/2012 11:19 AM, Kumar Srinivasan wrote: >>>> My suggestion is to see if System.loadLibrary can be used, this >>>> will >>>> bode well for the modularization effort. >>> I discussed this with the folks at awt-dev and they would prefer to >>> avoid loading as much as possible. They are strongly against always >>> preloading libjawt.so. >>> >> For my 2c, I'm against it too. It doesn't seem the right fix. > > I can see your point, but both the solutions feel wrong to me. I can't > make up my mind which is the less bad. > >> I don't see an attachment :-( > > I guess the mailing list software stripped it out. I did attach it. > >> Shouldn't it be a webrev anyway? > > Old habits :) > > Webrev is at: > http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/00/ > > I have also put up a test case at: > http://cr.openjdk.java.net/~omajid/jawt-test.tar.gz > > The test case is the exact same as that on > http://download.java.net/jdk8/docs/technotes/guides/awt/AWT_Native_Interface.html, > except it automates the building and running. You will have to edit the > makefile to set the value of JDK_HOME. It should point to a j2sdk-image > directory. > > Then do: > $ make > $ make run > > Without the fix it should print an UnsatisfiedLinkError. With the fix, > it should show a window. > >> I built jdk8/build successfully just last week. What issues are you seeing? > > Errors building hotspot, I seem to recall. But I cant reproduce it > anymore after pulling today. I can now confirm that the fix works for me > with jdk8 too. > > Thanks, > Omair From kumar.x.srinivasan at oracle.COM Fri Aug 10 10:30:48 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Fri, 10 Aug 2012 03:30:48 -0700 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <5024CB92.6000407@oracle.com> References: <2050199910.2465202.1344510954312.JavaMail.root@redhat.com> <50243012.6010300@redhat.com> <5024CB92.6000407@oracle.com> Message-ID: <5024E2D8.4020208@oracle.COM> Hi Anthony, a. although this is a build change, I have requested Omair to provide a regression test, IMO if we had a regression test to begin with, this would not have been removed during the RPATH work. We may have to check in a ".so" for linux and solaris variants. So my question to you. Where should such a test be parked, in awt regression test hierarchy ? b. this should be pushed via awt integration repo, thus allowing all awt PITs to be run. Thanks Kumar > Hi Omair, > > The fix looks good to me. I think Kumar needs to take a look at it, > too, before the fix can be pushed to a repo. > > Thanks for finding and fixing this issue. > > -- > best regards, > Anthony > > On 8/10/2012 1:48 AM, Omair Majid wrote: >> On 08/09/2012 07:15 AM, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> Hi Kumar, >>>> >>>> On 07/23/2012 11:19 AM, Kumar Srinivasan wrote: >>>>> My suggestion is to see if System.loadLibrary can be used, this >>>>> will >>>>> bode well for the modularization effort. >>>> I discussed this with the folks at awt-dev and they would prefer to >>>> avoid loading as much as possible. They are strongly against always >>>> preloading libjawt.so. >>>> >>> For my 2c, I'm against it too. It doesn't seem the right fix. >> >> I can see your point, but both the solutions feel wrong to me. I can't >> make up my mind which is the less bad. >> >>> I don't see an attachment :-( >> >> I guess the mailing list software stripped it out. I did attach it. >> >>> Shouldn't it be a webrev anyway? >> >> Old habits :) >> >> Webrev is at: >> http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/00/ >> >> I have also put up a test case at: >> http://cr.openjdk.java.net/~omajid/jawt-test.tar.gz >> >> The test case is the exact same as that on >> http://download.java.net/jdk8/docs/technotes/guides/awt/AWT_Native_Interface.html, >> >> except it automates the building and running. You will have to edit the >> makefile to set the value of JDK_HOME. It should point to a j2sdk-image >> directory. >> >> Then do: >> $ make >> $ make run >> >> Without the fix it should print an UnsatisfiedLinkError. With the fix, >> it should show a window. >> >>> I built jdk8/build successfully just last week. What issues are you >>> seeing? >> >> Errors building hotspot, I seem to recall. But I cant reproduce it >> anymore after pulling today. I can now confirm that the fix works for me >> with jdk8 too. >> >> Thanks, >> Omair From kumar.x.srinivasan at oracle.COM Fri Aug 10 10:42:13 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Fri, 10 Aug 2012 03:42:13 -0700 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <5024E2D8.4020208@oracle.COM> References: <2050199910.2465202.1344510954312.JavaMail.root@redhat.com> <50243012.6010300@redhat.com> <5024CB92.6000407@oracle.com> <5024E2D8.4020208@oracle.COM> Message-ID: <5024E585.5020707@oracle.COM> Hi Anthony, Omair, Shouldn't there be a case for MacOSX as well ? Kumar > Hi Anthony, > > a. although this is a build change, I have requested Omair to provide > a regression > test, IMO if we had a regression test to begin with, this would > not have been removed > during the RPATH work. We may have to check in a ".so" for linux > and solaris > variants. So my question to you. Where should such a test be > parked, in awt regression > test hierarchy ? > > b. this should be pushed via awt integration repo, thus allowing all > awt PITs to be run. > > Thanks > > Kumar > >> Hi Omair, >> >> The fix looks good to me. I think Kumar needs to take a look at it, >> too, before the fix can be pushed to a repo. >> >> Thanks for finding and fixing this issue. >> >> -- >> best regards, >> Anthony >> >> On 8/10/2012 1:48 AM, Omair Majid wrote: >>> On 08/09/2012 07:15 AM, Andrew Hughes wrote: >>>> ----- Original Message ----- >>>>> Hi Kumar, >>>>> >>>>> On 07/23/2012 11:19 AM, Kumar Srinivasan wrote: >>>>>> My suggestion is to see if System.loadLibrary can be used, this >>>>>> will >>>>>> bode well for the modularization effort. >>>>> I discussed this with the folks at awt-dev and they would prefer to >>>>> avoid loading as much as possible. They are strongly against always >>>>> preloading libjawt.so. >>>>> >>>> For my 2c, I'm against it too. It doesn't seem the right fix. >>> >>> I can see your point, but both the solutions feel wrong to me. I can't >>> make up my mind which is the less bad. >>> >>>> I don't see an attachment :-( >>> >>> I guess the mailing list software stripped it out. I did attach it. >>> >>>> Shouldn't it be a webrev anyway? >>> >>> Old habits :) >>> >>> Webrev is at: >>> http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/00/ >>> >>> I have also put up a test case at: >>> http://cr.openjdk.java.net/~omajid/jawt-test.tar.gz >>> >>> The test case is the exact same as that on >>> http://download.java.net/jdk8/docs/technotes/guides/awt/AWT_Native_Interface.html, >>> >>> except it automates the building and running. You will have to edit the >>> makefile to set the value of JDK_HOME. It should point to a j2sdk-image >>> directory. >>> >>> Then do: >>> $ make >>> $ make run >>> >>> Without the fix it should print an UnsatisfiedLinkError. With the fix, >>> it should show a window. >>> >>>> I built jdk8/build successfully just last week. What issues are >>>> you seeing? >>> >>> Errors building hotspot, I seem to recall. But I cant reproduce it >>> anymore after pulling today. I can now confirm that the fix works >>> for me >>> with jdk8 too. >>> >>> Thanks, >>> Omair > From ahughes at redhat.com Fri Aug 10 12:20:53 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Fri, 10 Aug 2012 08:20:53 -0400 (EDT) Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <50243012.6010300@redhat.com> Message-ID: <1937898803.3144440.1344601253018.JavaMail.root@redhat.com> ----- Original Message ----- > On 08/09/2012 07:15 AM, Andrew Hughes wrote: > > ----- Original Message ----- > >> Hi Kumar, > >> > >> On 07/23/2012 11:19 AM, Kumar Srinivasan wrote: > >>> My suggestion is to see if System.loadLibrary can be used, this > >>> will > >>> bode well for the modularization effort. > >> > >> I discussed this with the folks at awt-dev and they would prefer > >> to > >> avoid loading as much as possible. They are strongly against > >> always > >> preloading libjawt.so. > >> > > > > For my 2c, I'm against it too. It doesn't seem the right fix. > > I can see your point, but both the solutions feel wrong to me. I > can't > make up my mind which is the less bad. > Yeah, neither is ideal. I just tend to think preloading it always is like using a sledgehammer to crack a nut... > > I don't see an attachment :-( > > I guess the mailing list software stripped it out. I did attach it. > > > Shouldn't it be a webrev anyway? > > Old habits :) > Preferred by me, but webrevs are the norm for OpenJDK AIUI. > Webrev is at: > http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/00/ > > I have also put up a test case at: > http://cr.openjdk.java.net/~omajid/jawt-test.tar.gz > > The test case is the exact same as that on > http://download.java.net/jdk8/docs/technotes/guides/awt/AWT_Native_Interface.html, > except it automates the building and running. You will have to edit > the > makefile to set the value of JDK_HOME. It should point to a > j2sdk-image > directory. > > Then do: > $ make > $ make run > > Without the fix it should print an UnsatisfiedLinkError. With the > fix, > it should show a window. > > > I built jdk8/build successfully just last week. What issues are > > you seeing? > > Errors building hotspot, I seem to recall. But I cant reproduce it > anymore after pulling today. I can now confirm that the fix works for > me > with jdk8 too. > This by any chance? http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-July/006259.html > Thanks, > Omair > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From ahughes at redhat.com Fri Aug 10 12:24:36 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Fri, 10 Aug 2012 08:24:36 -0400 (EDT) Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <5024E2D8.4020208@oracle.COM> Message-ID: <2065351848.3145321.1344601476979.JavaMail.root@redhat.com> ----- Original Message ----- > Hi Anthony, > > a. although this is a build change, I have requested Omair to provide > a > regression > test, IMO if we had a regression test to begin with, this would > not > have been removed > during the RPATH work. We may have to check in a ".so" for linux > and solaris > variants. So my question to you. Where should such a test be > parked, in awt regression > test hierarchy ? > > b. this should be pushed via awt integration repo, thus allowing all > awt PITs to be run. > Please don't check binaries into the repositories. Omair's test works fine with just source code. I replicated the issue using it. > Thanks > > Kumar > > > Hi Omair, > > > > The fix looks good to me. I think Kumar needs to take a look at it, > > too, before the fix can be pushed to a repo. > > > > Thanks for finding and fixing this issue. > > > > -- > > best regards, > > Anthony > > > > On 8/10/2012 1:48 AM, Omair Majid wrote: > >> On 08/09/2012 07:15 AM, Andrew Hughes wrote: > >>> ----- Original Message ----- > >>>> Hi Kumar, > >>>> > >>>> On 07/23/2012 11:19 AM, Kumar Srinivasan wrote: > >>>>> My suggestion is to see if System.loadLibrary can be used, this > >>>>> will > >>>>> bode well for the modularization effort. > >>>> I discussed this with the folks at awt-dev and they would prefer > >>>> to > >>>> avoid loading as much as possible. They are strongly against > >>>> always > >>>> preloading libjawt.so. > >>>> > >>> For my 2c, I'm against it too. It doesn't seem the right fix. > >> > >> I can see your point, but both the solutions feel wrong to me. I > >> can't > >> make up my mind which is the less bad. > >> > >>> I don't see an attachment :-( > >> > >> I guess the mailing list software stripped it out. I did attach > >> it. > >> > >>> Shouldn't it be a webrev anyway? > >> > >> Old habits :) > >> > >> Webrev is at: > >> http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/00/ > >> > >> I have also put up a test case at: > >> http://cr.openjdk.java.net/~omajid/jawt-test.tar.gz > >> > >> The test case is the exact same as that on > >> http://download.java.net/jdk8/docs/technotes/guides/awt/AWT_Native_Interface.html, > >> > >> except it automates the building and running. You will have to > >> edit the > >> makefile to set the value of JDK_HOME. It should point to a > >> j2sdk-image > >> directory. > >> > >> Then do: > >> $ make > >> $ make run > >> > >> Without the fix it should print an UnsatisfiedLinkError. With the > >> fix, > >> it should show a window. > >> > >>> I built jdk8/build successfully just last week. What issues are > >>> you > >>> seeing? > >> > >> Errors building hotspot, I seem to recall. But I cant reproduce it > >> anymore after pulling today. I can now confirm that the fix works > >> for me > >> with jdk8 too. > >> > >> Thanks, > >> Omair > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From anthony.petrov at oracle.com Fri Aug 10 12:25:09 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 10 Aug 2012 16:25:09 +0400 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <5024E2D8.4020208@oracle.COM> References: <2050199910.2465202.1344510954312.JavaMail.root@redhat.com> <50243012.6010300@redhat.com> <5024CB92.6000407@oracle.com> <5024E2D8.4020208@oracle.COM> Message-ID: <5024FDA5.3020802@oracle.com> Hi Kumar, Omair, [ adding awt-dev@ in the loop ] On 8/10/2012 2:30 PM, Kumar Srinivasan wrote: > a. although this is a build change, I have requested Omair to provide a > regression > test, IMO if we had a regression test to begin with, this would not > have been removed > during the RPATH work. We may have to check in a ".so" for linux and > solaris > variants. So my question to you. Where should such a test be parked, > in awt regression > test hierarchy ? We have a test for this already, actually, although it is closed and doesn't use jtreg. I filed 7190587 to fix this. For now Omair may proceed w/o a regression test. > b. this should be pushed via awt integration repo, thus allowing all > awt PITs to be run. I don't mind that. -- best regards, Anthony > > Thanks > > Kumar > >> Hi Omair, >> >> The fix looks good to me. I think Kumar needs to take a look at it, >> too, before the fix can be pushed to a repo. >> >> Thanks for finding and fixing this issue. >> >> -- >> best regards, >> Anthony >> >> On 8/10/2012 1:48 AM, Omair Majid wrote: >>> On 08/09/2012 07:15 AM, Andrew Hughes wrote: >>>> ----- Original Message ----- >>>>> Hi Kumar, >>>>> >>>>> On 07/23/2012 11:19 AM, Kumar Srinivasan wrote: >>>>>> My suggestion is to see if System.loadLibrary can be used, this >>>>>> will >>>>>> bode well for the modularization effort. >>>>> I discussed this with the folks at awt-dev and they would prefer to >>>>> avoid loading as much as possible. They are strongly against always >>>>> preloading libjawt.so. >>>>> >>>> For my 2c, I'm against it too. It doesn't seem the right fix. >>> >>> I can see your point, but both the solutions feel wrong to me. I can't >>> make up my mind which is the less bad. >>> >>>> I don't see an attachment :-( >>> >>> I guess the mailing list software stripped it out. I did attach it. >>> >>>> Shouldn't it be a webrev anyway? >>> >>> Old habits :) >>> >>> Webrev is at: >>> http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/00/ >>> >>> I have also put up a test case at: >>> http://cr.openjdk.java.net/~omajid/jawt-test.tar.gz >>> >>> The test case is the exact same as that on >>> http://download.java.net/jdk8/docs/technotes/guides/awt/AWT_Native_Interface.html, >>> >>> except it automates the building and running. You will have to edit the >>> makefile to set the value of JDK_HOME. It should point to a j2sdk-image >>> directory. >>> >>> Then do: >>> $ make >>> $ make run >>> >>> Without the fix it should print an UnsatisfiedLinkError. With the fix, >>> it should show a window. >>> >>>> I built jdk8/build successfully just last week. What issues are you >>>> seeing? >>> >>> Errors building hotspot, I seem to recall. But I cant reproduce it >>> anymore after pulling today. I can now confirm that the fix works for me >>> with jdk8 too. >>> >>> Thanks, >>> Omair > From anthony.petrov at oracle.com Fri Aug 10 12:26:51 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 10 Aug 2012 16:26:51 +0400 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <5024E585.5020707@oracle.COM> References: <2050199910.2465202.1344510954312.JavaMail.root@redhat.com> <50243012.6010300@redhat.com> <5024CB92.6000407@oracle.com> <5024E2D8.4020208@oracle.COM> <5024E585.5020707@oracle.COM> Message-ID: <5024FE0B.6030100@oracle.com> Well, it's complicated. There's problems with JAWT on the Mac currently, which makes it hard or even impossible to use it on that platform. We'll add support for the Mac to a test open-sourced with 7190587 once JAWT is working fine on the Mac in general. -- best regards, Anthony On 8/10/2012 2:42 PM, Kumar Srinivasan wrote: > Hi Anthony, Omair, > > Shouldn't there be a case for MacOSX as well ? > > Kumar > >> Hi Anthony, >> >> a. although this is a build change, I have requested Omair to provide >> a regression >> test, IMO if we had a regression test to begin with, this would >> not have been removed >> during the RPATH work. We may have to check in a ".so" for linux >> and solaris >> variants. So my question to you. Where should such a test be >> parked, in awt regression >> test hierarchy ? >> >> b. this should be pushed via awt integration repo, thus allowing all >> awt PITs to be run. >> >> Thanks >> >> Kumar >> >>> Hi Omair, >>> >>> The fix looks good to me. I think Kumar needs to take a look at it, >>> too, before the fix can be pushed to a repo. >>> >>> Thanks for finding and fixing this issue. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 8/10/2012 1:48 AM, Omair Majid wrote: >>>> On 08/09/2012 07:15 AM, Andrew Hughes wrote: >>>>> ----- Original Message ----- >>>>>> Hi Kumar, >>>>>> >>>>>> On 07/23/2012 11:19 AM, Kumar Srinivasan wrote: >>>>>>> My suggestion is to see if System.loadLibrary can be used, this >>>>>>> will >>>>>>> bode well for the modularization effort. >>>>>> I discussed this with the folks at awt-dev and they would prefer to >>>>>> avoid loading as much as possible. They are strongly against always >>>>>> preloading libjawt.so. >>>>>> >>>>> For my 2c, I'm against it too. It doesn't seem the right fix. >>>> >>>> I can see your point, but both the solutions feel wrong to me. I can't >>>> make up my mind which is the less bad. >>>> >>>>> I don't see an attachment :-( >>>> >>>> I guess the mailing list software stripped it out. I did attach it. >>>> >>>>> Shouldn't it be a webrev anyway? >>>> >>>> Old habits :) >>>> >>>> Webrev is at: >>>> http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/00/ >>>> >>>> I have also put up a test case at: >>>> http://cr.openjdk.java.net/~omajid/jawt-test.tar.gz >>>> >>>> The test case is the exact same as that on >>>> http://download.java.net/jdk8/docs/technotes/guides/awt/AWT_Native_Interface.html, >>>> >>>> except it automates the building and running. You will have to edit the >>>> makefile to set the value of JDK_HOME. It should point to a j2sdk-image >>>> directory. >>>> >>>> Then do: >>>> $ make >>>> $ make run >>>> >>>> Without the fix it should print an UnsatisfiedLinkError. With the fix, >>>> it should show a window. >>>> >>>>> I built jdk8/build successfully just last week. What issues are >>>>> you seeing? >>>> >>>> Errors building hotspot, I seem to recall. But I cant reproduce it >>>> anymore after pulling today. I can now confirm that the fix works >>>> for me >>>> with jdk8 too. >>>> >>>> Thanks, >>>> Omair >> > From anthony.petrov at oracle.com Fri Aug 10 12:29:29 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 10 Aug 2012 16:29:29 +0400 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <2065351848.3145321.1344601476979.JavaMail.root@redhat.com> References: <2065351848.3145321.1344601476979.JavaMail.root@redhat.com> Message-ID: <5024FEA9.4020401@oracle.com> On 8/10/2012 4:24 PM, Andrew Hughes wrote: > ----- Original Message ----- >> Hi Anthony, >> >> a. although this is a build change, I have requested Omair to provide >> a >> regression >> test, IMO if we had a regression test to begin with, this would >> not >> have been removed >> during the RPATH work. We may have to check in a ".so" for linux >> and solaris >> variants. So my question to you. Where should such a test be >> parked, in awt regression >> test hierarchy ? >> >> b. this should be pushed via awt integration repo, thus allowing all >> awt PITs to be run. >> > > Please don't check binaries into the repositories. Omair's test works fine > with just source code. I replicated the issue using it. +1 regarding binaries in repos. Actually, if Omair has a good automatic jtreg test, we would be happy to get it checked in with this fix. Could we see a webrev for the test please? -- best regards, Anthony > >> Thanks >> >> Kumar >> >>> Hi Omair, >>> >>> The fix looks good to me. I think Kumar needs to take a look at it, >>> too, before the fix can be pushed to a repo. >>> >>> Thanks for finding and fixing this issue. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 8/10/2012 1:48 AM, Omair Majid wrote: >>>> On 08/09/2012 07:15 AM, Andrew Hughes wrote: >>>>> ----- Original Message ----- >>>>>> Hi Kumar, >>>>>> >>>>>> On 07/23/2012 11:19 AM, Kumar Srinivasan wrote: >>>>>>> My suggestion is to see if System.loadLibrary can be used, this >>>>>>> will >>>>>>> bode well for the modularization effort. >>>>>> I discussed this with the folks at awt-dev and they would prefer >>>>>> to >>>>>> avoid loading as much as possible. They are strongly against >>>>>> always >>>>>> preloading libjawt.so. >>>>>> >>>>> For my 2c, I'm against it too. It doesn't seem the right fix. >>>> I can see your point, but both the solutions feel wrong to me. I >>>> can't >>>> make up my mind which is the less bad. >>>> >>>>> I don't see an attachment :-( >>>> I guess the mailing list software stripped it out. I did attach >>>> it. >>>> >>>>> Shouldn't it be a webrev anyway? >>>> Old habits :) >>>> >>>> Webrev is at: >>>> http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/00/ >>>> >>>> I have also put up a test case at: >>>> http://cr.openjdk.java.net/~omajid/jawt-test.tar.gz >>>> >>>> The test case is the exact same as that on >>>> http://download.java.net/jdk8/docs/technotes/guides/awt/AWT_Native_Interface.html, >>>> >>>> except it automates the building and running. You will have to >>>> edit the >>>> makefile to set the value of JDK_HOME. It should point to a >>>> j2sdk-image >>>> directory. >>>> >>>> Then do: >>>> $ make >>>> $ make run >>>> >>>> Without the fix it should print an UnsatisfiedLinkError. With the >>>> fix, >>>> it should show a window. >>>> >>>>> I built jdk8/build successfully just last week. What issues are >>>>> you >>>>> seeing? >>>> Errors building hotspot, I seem to recall. But I cant reproduce it >>>> anymore after pulling today. I can now confirm that the fix works >>>> for me >>>> with jdk8 too. >>>> >>>> Thanks, >>>> Omair >> > From erik.joelsson at oracle.com Fri Aug 10 12:48:05 2012 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 10 Aug 2012 14:48:05 +0200 Subject: jdk builds on the mac In-Reply-To: <173144833.3143360.1344601037141.JavaMail.root@redhat.com> References: <173144833.3143360.1344601037141.JavaMail.root@redhat.com> Message-ID: <50250305.1080003@oracle.com> Yes, that's what should be happening as I understand it. But right now, it's always the bootjdk. I also believe it's hardcoded to src and target 1.5. /Erik On 2012-08-10 14:17, Andrew Hughes wrote: > ----- Original Message ----- >> It does and I believe Joel, in the langtools team, is looking at this >> issue. >> >> /Erik >> >> On 2012-08-10 03:00, Kelly O'Hair wrote: >>> I think we need to make sure that the only thing that gets built >>> with the bootjdk javac is the langtools >>> bootstrap javac.jar, all other javac compilations needs to be done >>> by the bootstrap javac. >>> Does that fix this issue? >>> > What happens if langtools isn't built? Is the javac from the import jdk used? > >>> -kto >>> >>> On Aug 6, 2012, at 2:33 AM, Erik Joelsson wrote: >>> >>>> The classpath reference was added on my request for build-infra. >>>> The reason was to get javax.annotation.GenerateNativeHeader on >>>> the classpath. The javac used in that ant script is the bootjdk >>>> javac, which usually doesn't provide the annotation. I suppose >>>> the correct fix would be to change the ant script to use the >>>> bootstrap javac instead. >>>> >>>> /Erik >>>> >>>> On 2012-07-28 00:06, Kumar Srinivasan wrote: >>>>> On 7/25/2012 2:23 PM, Kelly O'Hair wrote: >>>>>> Naoto has noticed this build failure on the Mac (just the Mac) >>>>>> when building just the jdk repository. >>>>>> >>>>>> From what I can tell, the Mac build of the jdk repository now >>>>>> depends on the langtools repository also >>>>>> being built, which means that partial builds of just the jdk >>>>>> repository will no longer work on the Mac? >>>>>> There is an ant script at jdk/src/macosx/native/jobjc/build.xml >>>>>> that has a baked in classpath reference to >>>>>> ../../langtools/dist/lib/classes.jar >>>>>> >>>>>> Has anyone seen this, or have any additional information on it? >>>>> This is preventing me to test certain things I can only run from >>>>> a jdk build under >>>>> jprt on the macosx machine. >>>>> >>>>> Kumar >>>>> >>>>>> -kto >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> build-core: >>>>>> [mkdir] Created dir: >>>>>> /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core >>>>>> [javac] com/apple/jobjc/PrimitiveCoder.java added as >>>>>> com/apple/jobjc/PrimitiveCoder.class doesn't exist. >>>>>> [javac] Compiling 1 source file to >>>>>> /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core >>>>>> [javac] Using modern compiler >>>>>> dropping >>>>>> /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/langtools/dist/lib/classes.jar >>>>>> from path as it doesn't exist >>>>>> [javac] Compilation arguments: >>>>>> [javac] '-d' >>>>>> [javac] >>>>>> '/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core' >>>>>> [javac] '-classpath' >>>>>> [javac] >>>>>> '/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core' >>>>>> [javac] '-sourcepath' >>>>>> [javac] >>>>>> '/private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java' >>>>>> [javac] '-target' >>>>>> [javac] '1.5' >>>>>> [javac] '-g' >>>>>> [javac] '-source' >>>>>> [javac] '1.5' >>>>>> [javac] >>>>>> [javac] The ' characters around the executable and >>>>>> arguments are >>>>>> [javac] not part of the command. >>>>>> [javac] File to be compiled: >>>>>> [javac] >>>>>> /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/PrimitiveCoder.java >>>>>> [javac] warning: [options] bootstrap class path not set in >>>>>> conjunction with -source 1.5 >>>>>> [javac] >>>>>> /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java:32: >>>>>> warning: Unsafe is internal proprietary API and may be >>>>>> removed in a future release >>>>>> [javac] import sun.misc.Unsafe; >>>>>> [javac] ^ >>>>>> >>>>>> ..... >>>>>> >>>>>> [javac] @GenerateNativeHeader >>>>>> [javac] ^ >>>>>> [javac] symbol: class GenerateNativeHeader >>>>>> [javac] Note: Some input files use unchecked or unsafe >>>>>> operations. >>>>>> [javac] Note: Recompile with -Xlint:unchecked for details. >>>>>> [javac] 61 errors >>>>>> [javac] 7 warnings >>>>>> >>>>>> BUILD FAILED >>>>>> /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/build.xml:143: >>>>>> Compile failed; see the compiler error output for details. >>>>>> at >>>>>> org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:1079) >>>>>> at >>>>>> org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:882) >>>>>> at >>>>>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) >>>>>> at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown >>>>>> Source) >>>>>> at >>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>>> at java.lang.reflect.Method.invoke(Method.java:601) >>>>>> at >>>>>> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) >>>>>> at org.apache.tools.ant.Task.perform(Task.java:348) >>>>>> at org.apache.tools.ant.Target.execute(Target.java:357) >>>>>> at org.apache.tools.ant.Target.performTasks(Target.java:385) >>>>>> at >>>>>> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) >>>>>> at >>>>>> org.apache.tools.ant.Project.executeTarget(Project.java:1306) >>>>>> at >>>>>> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) >>>>>> at >>>>>> org.apache.tools.ant.Project.executeTargets(Project.java:1189) >>>>>> at org.apache.tools.ant.Main.runBuild(Main.java:758) >>>>>> at org.apache.tools.ant.Main.startAnt(Main.java:217) >>>>>> at >>>>>> org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) >>>>>> at >>>>>> org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) >>>>>> >>>>>> Total time: 1 second >>>>>> make[2]: *** >>>>>> [../../../build/macosx-x86_64/JObjC.build/JObjC.jar] Error 1 >>>>>> make[1]: *** [all] Error 1 >>>>>> make: *** [all] Error 1 >> From ahughes at redhat.com Fri Aug 10 12:59:41 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Fri, 10 Aug 2012 08:59:41 -0400 (EDT) Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <5024FEA9.4020401@oracle.com> Message-ID: <1624234680.3160519.1344603581873.JavaMail.root@redhat.com> ----- Original Message ----- > On 8/10/2012 4:24 PM, Andrew Hughes wrote: > > ----- Original Message ----- > >> Hi Anthony, > >> > >> a. although this is a build change, I have requested Omair to > >> provide > >> a > >> regression > >> test, IMO if we had a regression test to begin with, this > >> would > >> not > >> have been removed > >> during the RPATH work. We may have to check in a ".so" for > >> linux > >> and solaris > >> variants. So my question to you. Where should such a test be > >> parked, in awt regression > >> test hierarchy ? > >> > >> b. this should be pushed via awt integration repo, thus allowing > >> all > >> awt PITs to be run. > >> > > > > Please don't check binaries into the repositories. Omair's test > > works fine > > with just source code. I replicated the issue using it. > > +1 regarding binaries in repos. > > Actually, if Omair has a good automatic jtreg test, we would be happy > to > get it checked in with this fix. Could we see a webrev for the test > please? > A webrev of the patch and a separate test case are both linked in this e-mail: http://mail.openjdk.java.net/pipermail/build-dev/2012-August/006555.html The test case would need converting to use jtreg obviously, but I'm pretty sure there are similar tests already (certainly in HotSpot). > -- > best regards, > Anthony > > > > >> Thanks > >> > >> Kumar > >> > >>> Hi Omair, > >>> > >>> The fix looks good to me. I think Kumar needs to take a look at > >>> it, > >>> too, before the fix can be pushed to a repo. > >>> > >>> Thanks for finding and fixing this issue. > >>> > >>> -- > >>> best regards, > >>> Anthony > >>> > >>> On 8/10/2012 1:48 AM, Omair Majid wrote: > >>>> On 08/09/2012 07:15 AM, Andrew Hughes wrote: > >>>>> ----- Original Message ----- > >>>>>> Hi Kumar, > >>>>>> > >>>>>> On 07/23/2012 11:19 AM, Kumar Srinivasan wrote: > >>>>>>> My suggestion is to see if System.loadLibrary can be used, > >>>>>>> this > >>>>>>> will > >>>>>>> bode well for the modularization effort. > >>>>>> I discussed this with the folks at awt-dev and they would > >>>>>> prefer > >>>>>> to > >>>>>> avoid loading as much as possible. They are strongly against > >>>>>> always > >>>>>> preloading libjawt.so. > >>>>>> > >>>>> For my 2c, I'm against it too. It doesn't seem the right fix. > >>>> I can see your point, but both the solutions feel wrong to me. I > >>>> can't > >>>> make up my mind which is the less bad. > >>>> > >>>>> I don't see an attachment :-( > >>>> I guess the mailing list software stripped it out. I did attach > >>>> it. > >>>> > >>>>> Shouldn't it be a webrev anyway? > >>>> Old habits :) > >>>> > >>>> Webrev is at: > >>>> http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/00/ > >>>> > >>>> I have also put up a test case at: > >>>> http://cr.openjdk.java.net/~omajid/jawt-test.tar.gz > >>>> > >>>> The test case is the exact same as that on > >>>> http://download.java.net/jdk8/docs/technotes/guides/awt/AWT_Native_Interface.html, > >>>> > >>>> except it automates the building and running. You will have to > >>>> edit the > >>>> makefile to set the value of JDK_HOME. It should point to a > >>>> j2sdk-image > >>>> directory. > >>>> > >>>> Then do: > >>>> $ make > >>>> $ make run > >>>> > >>>> Without the fix it should print an UnsatisfiedLinkError. With > >>>> the > >>>> fix, > >>>> it should show a window. > >>>> > >>>>> I built jdk8/build successfully just last week. What issues > >>>>> are > >>>>> you > >>>>> seeing? > >>>> Errors building hotspot, I seem to recall. But I cant reproduce > >>>> it > >>>> anymore after pulling today. I can now confirm that the fix > >>>> works > >>>> for me > >>>> with jdk8 too. > >>>> > >>>> Thanks, > >>>> Omair > >> > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From anthony.petrov at oracle.com Fri Aug 10 13:05:32 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 10 Aug 2012 17:05:32 +0400 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <1624234680.3160519.1344603581873.JavaMail.root@redhat.com> References: <1624234680.3160519.1344603581873.JavaMail.root@redhat.com> Message-ID: <5025071C.3050801@oracle.com> On 8/10/2012 4:59 PM, Andrew Hughes wrote: > > ----- Original Message ----- >> On 8/10/2012 4:24 PM, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> Hi Anthony, >>>> >>>> a. although this is a build change, I have requested Omair to >>>> provide >>>> a >>>> regression >>>> test, IMO if we had a regression test to begin with, this >>>> would >>>> not >>>> have been removed >>>> during the RPATH work. We may have to check in a ".so" for >>>> linux >>>> and solaris >>>> variants. So my question to you. Where should such a test be >>>> parked, in awt regression >>>> test hierarchy ? >>>> >>>> b. this should be pushed via awt integration repo, thus allowing >>>> all >>>> awt PITs to be run. >>>> >>> Please don't check binaries into the repositories. Omair's test >>> works fine >>> with just source code. I replicated the issue using it. >> +1 regarding binaries in repos. >> >> Actually, if Omair has a good automatic jtreg test, we would be happy >> to >> get it checked in with this fix. Could we see a webrev for the test >> please? >> > > A webrev of the patch and a separate test case are both linked in this e-mail: > > http://mail.openjdk.java.net/pipermail/build-dev/2012-August/006555.html > > The test case would need converting to use jtreg obviously, but I'm pretty sure > there are similar tests already (certainly in HotSpot). Yes, I've seen those links. I would like to review the full webrev, including a jtreg-compatible test. -- best regards, Anthony > >> -- >> best regards, >> Anthony >> >>>> Thanks >>>> >>>> Kumar >>>> >>>>> Hi Omair, >>>>> >>>>> The fix looks good to me. I think Kumar needs to take a look at >>>>> it, >>>>> too, before the fix can be pushed to a repo. >>>>> >>>>> Thanks for finding and fixing this issue. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 8/10/2012 1:48 AM, Omair Majid wrote: >>>>>> On 08/09/2012 07:15 AM, Andrew Hughes wrote: >>>>>>> ----- Original Message ----- >>>>>>>> Hi Kumar, >>>>>>>> >>>>>>>> On 07/23/2012 11:19 AM, Kumar Srinivasan wrote: >>>>>>>>> My suggestion is to see if System.loadLibrary can be used, >>>>>>>>> this >>>>>>>>> will >>>>>>>>> bode well for the modularization effort. >>>>>>>> I discussed this with the folks at awt-dev and they would >>>>>>>> prefer >>>>>>>> to >>>>>>>> avoid loading as much as possible. They are strongly against >>>>>>>> always >>>>>>>> preloading libjawt.so. >>>>>>>> >>>>>>> For my 2c, I'm against it too. It doesn't seem the right fix. >>>>>> I can see your point, but both the solutions feel wrong to me. I >>>>>> can't >>>>>> make up my mind which is the less bad. >>>>>> >>>>>>> I don't see an attachment :-( >>>>>> I guess the mailing list software stripped it out. I did attach >>>>>> it. >>>>>> >>>>>>> Shouldn't it be a webrev anyway? >>>>>> Old habits :) >>>>>> >>>>>> Webrev is at: >>>>>> http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/00/ >>>>>> >>>>>> I have also put up a test case at: >>>>>> http://cr.openjdk.java.net/~omajid/jawt-test.tar.gz >>>>>> >>>>>> The test case is the exact same as that on >>>>>> http://download.java.net/jdk8/docs/technotes/guides/awt/AWT_Native_Interface.html, >>>>>> >>>>>> except it automates the building and running. You will have to >>>>>> edit the >>>>>> makefile to set the value of JDK_HOME. It should point to a >>>>>> j2sdk-image >>>>>> directory. >>>>>> >>>>>> Then do: >>>>>> $ make >>>>>> $ make run >>>>>> >>>>>> Without the fix it should print an UnsatisfiedLinkError. With >>>>>> the >>>>>> fix, >>>>>> it should show a window. >>>>>> >>>>>>> I built jdk8/build successfully just last week. What issues >>>>>>> are >>>>>>> you >>>>>>> seeing? >>>>>> Errors building hotspot, I seem to recall. But I cant reproduce >>>>>> it >>>>>> anymore after pulling today. I can now confirm that the fix >>>>>> works >>>>>> for me >>>>>> with jdk8 too. >>>>>> >>>>>> Thanks, >>>>>> Omair > From ahughes at redhat.com Fri Aug 10 12:17:17 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Fri, 10 Aug 2012 08:17:17 -0400 (EDT) Subject: jdk builds on the mac In-Reply-To: <50249E97.4090409@oracle.com> Message-ID: <173144833.3143360.1344601037141.JavaMail.root@redhat.com> ----- Original Message ----- > It does and I believe Joel, in the langtools team, is looking at this > issue. > > /Erik > > On 2012-08-10 03:00, Kelly O'Hair wrote: > > I think we need to make sure that the only thing that gets built > > with the bootjdk javac is the langtools > > bootstrap javac.jar, all other javac compilations needs to be done > > by the bootstrap javac. > > Does that fix this issue? > > What happens if langtools isn't built? Is the javac from the import jdk used? > > -kto > > > > On Aug 6, 2012, at 2:33 AM, Erik Joelsson wrote: > > > >> The classpath reference was added on my request for build-infra. > >> The reason was to get javax.annotation.GenerateNativeHeader on > >> the classpath. The javac used in that ant script is the bootjdk > >> javac, which usually doesn't provide the annotation. I suppose > >> the correct fix would be to change the ant script to use the > >> bootstrap javac instead. > >> > >> /Erik > >> > >> On 2012-07-28 00:06, Kumar Srinivasan wrote: > >>> On 7/25/2012 2:23 PM, Kelly O'Hair wrote: > >>>> Naoto has noticed this build failure on the Mac (just the Mac) > >>>> when building just the jdk repository. > >>>> > >>>> From what I can tell, the Mac build of the jdk repository now > >>>> depends on the langtools repository also > >>>> being built, which means that partial builds of just the jdk > >>>> repository will no longer work on the Mac? > >>>> There is an ant script at jdk/src/macosx/native/jobjc/build.xml > >>>> that has a baked in classpath reference to > >>>> ../../langtools/dist/lib/classes.jar > >>>> > >>>> Has anyone seen this, or have any additional information on it? > >>> This is preventing me to test certain things I can only run from > >>> a jdk build under > >>> jprt on the macosx machine. > >>> > >>> Kumar > >>> > >>>> -kto > >>>> > >>>> ------------------------------------------------------------------------------ > >>>> build-core: > >>>> [mkdir] Created dir: > >>>> /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core > >>>> [javac] com/apple/jobjc/PrimitiveCoder.java added as > >>>> com/apple/jobjc/PrimitiveCoder.class doesn't exist. > >>>> [javac] Compiling 1 source file to > >>>> /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core > >>>> [javac] Using modern compiler > >>>> dropping > >>>> /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/langtools/dist/lib/classes.jar > >>>> from path as it doesn't exist > >>>> [javac] Compilation arguments: > >>>> [javac] '-d' > >>>> [javac] > >>>> '/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core' > >>>> [javac] '-classpath' > >>>> [javac] > >>>> '/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core' > >>>> [javac] '-sourcepath' > >>>> [javac] > >>>> '/private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java' > >>>> [javac] '-target' > >>>> [javac] '1.5' > >>>> [javac] '-g' > >>>> [javac] '-source' > >>>> [javac] '1.5' > >>>> [javac] > >>>> [javac] The ' characters around the executable and > >>>> arguments are > >>>> [javac] not part of the command. > >>>> [javac] File to be compiled: > >>>> [javac] > >>>> /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/PrimitiveCoder.java > >>>> [javac] warning: [options] bootstrap class path not set in > >>>> conjunction with -source 1.5 > >>>> [javac] > >>>> /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java:32: > >>>> warning: Unsafe is internal proprietary API and may be > >>>> removed in a future release > >>>> [javac] import sun.misc.Unsafe; > >>>> [javac] ^ > >>>> > >>>> ..... > >>>> > >>>> [javac] @GenerateNativeHeader > >>>> [javac] ^ > >>>> [javac] symbol: class GenerateNativeHeader > >>>> [javac] Note: Some input files use unchecked or unsafe > >>>> operations. > >>>> [javac] Note: Recompile with -Xlint:unchecked for details. > >>>> [javac] 61 errors > >>>> [javac] 7 warnings > >>>> > >>>> BUILD FAILED > >>>> /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/build.xml:143: > >>>> Compile failed; see the compiler error output for details. > >>>> at > >>>> org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:1079) > >>>> at > >>>> org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:882) > >>>> at > >>>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) > >>>> at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown > >>>> Source) > >>>> at > >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > >>>> at java.lang.reflect.Method.invoke(Method.java:601) > >>>> at > >>>> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > >>>> at org.apache.tools.ant.Task.perform(Task.java:348) > >>>> at org.apache.tools.ant.Target.execute(Target.java:357) > >>>> at org.apache.tools.ant.Target.performTasks(Target.java:385) > >>>> at > >>>> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) > >>>> at > >>>> org.apache.tools.ant.Project.executeTarget(Project.java:1306) > >>>> at > >>>> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) > >>>> at > >>>> org.apache.tools.ant.Project.executeTargets(Project.java:1189) > >>>> at org.apache.tools.ant.Main.runBuild(Main.java:758) > >>>> at org.apache.tools.ant.Main.startAnt(Main.java:217) > >>>> at > >>>> org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) > >>>> at > >>>> org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) > >>>> > >>>> Total time: 1 second > >>>> make[2]: *** > >>>> [../../../build/macosx-x86_64/JObjC.build/JObjC.jar] Error 1 > >>>> make[1]: *** [all] Error 1 > >>>> make: *** [all] Error 1 > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From kelly.ohair at oracle.com Fri Aug 10 18:04:17 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 10 Aug 2012 11:04:17 -0700 Subject: jdk builds on the mac In-Reply-To: <173144833.3143360.1344601037141.JavaMail.root@redhat.com> References: <173144833.3143360.1344601037141.JavaMail.root@redhat.com> Message-ID: <9FB5D755-F33E-4BA9-98A6-8AE10FF35B8C@oracle.com> On Aug 10, 2012, at 5:17 AM, Andrew Hughes wrote: > ----- Original Message ----- >> It does and I believe Joel, in the langtools team, is looking at this >> issue. >> >> /Erik >> >> On 2012-08-10 03:00, Kelly O'Hair wrote: >>> I think we need to make sure that the only thing that gets built >>> with the bootjdk javac is the langtools >>> bootstrap javac.jar, all other javac compilations needs to be done >>> by the bootstrap javac. >>> Does that fix this issue? >>> > > What happens if langtools isn't built? Is the javac from the import jdk used? That's the basic strategy used in the old makefiles. Using the tools in the boot jdk should be very controlled, but we have been sloppy in the past. -kto > >>> -kto >>> >>> On Aug 6, 2012, at 2:33 AM, Erik Joelsson wrote: >>> >>>> The classpath reference was added on my request for build-infra. >>>> The reason was to get javax.annotation.GenerateNativeHeader on >>>> the classpath. The javac used in that ant script is the bootjdk >>>> javac, which usually doesn't provide the annotation. I suppose >>>> the correct fix would be to change the ant script to use the >>>> bootstrap javac instead. >>>> >>>> /Erik >>>> >>>> On 2012-07-28 00:06, Kumar Srinivasan wrote: >>>>> On 7/25/2012 2:23 PM, Kelly O'Hair wrote: >>>>>> Naoto has noticed this build failure on the Mac (just the Mac) >>>>>> when building just the jdk repository. >>>>>> >>>>>> From what I can tell, the Mac build of the jdk repository now >>>>>> depends on the langtools repository also >>>>>> being built, which means that partial builds of just the jdk >>>>>> repository will no longer work on the Mac? >>>>>> There is an ant script at jdk/src/macosx/native/jobjc/build.xml >>>>>> that has a baked in classpath reference to >>>>>> ../../langtools/dist/lib/classes.jar >>>>>> >>>>>> Has anyone seen this, or have any additional information on it? >>>>> This is preventing me to test certain things I can only run from >>>>> a jdk build under >>>>> jprt on the macosx machine. >>>>> >>>>> Kumar >>>>> >>>>>> -kto >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> build-core: >>>>>> [mkdir] Created dir: >>>>>> /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core >>>>>> [javac] com/apple/jobjc/PrimitiveCoder.java added as >>>>>> com/apple/jobjc/PrimitiveCoder.class doesn't exist. >>>>>> [javac] Compiling 1 source file to >>>>>> /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core >>>>>> [javac] Using modern compiler >>>>>> dropping >>>>>> /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/langtools/dist/lib/classes.jar >>>>>> from path as it doesn't exist >>>>>> [javac] Compilation arguments: >>>>>> [javac] '-d' >>>>>> [javac] >>>>>> '/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core' >>>>>> [javac] '-classpath' >>>>>> [javac] >>>>>> '/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core' >>>>>> [javac] '-sourcepath' >>>>>> [javac] >>>>>> '/private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java' >>>>>> [javac] '-target' >>>>>> [javac] '1.5' >>>>>> [javac] '-g' >>>>>> [javac] '-source' >>>>>> [javac] '1.5' >>>>>> [javac] >>>>>> [javac] The ' characters around the executable and >>>>>> arguments are >>>>>> [javac] not part of the command. >>>>>> [javac] File to be compiled: >>>>>> [javac] >>>>>> /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/PrimitiveCoder.java >>>>>> [javac] warning: [options] bootstrap class path not set in >>>>>> conjunction with -source 1.5 >>>>>> [javac] >>>>>> /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java:32: >>>>>> warning: Unsafe is internal proprietary API and may be >>>>>> removed in a future release >>>>>> [javac] import sun.misc.Unsafe; >>>>>> [javac] ^ >>>>>> >>>>>> ..... >>>>>> >>>>>> [javac] @GenerateNativeHeader >>>>>> [javac] ^ >>>>>> [javac] symbol: class GenerateNativeHeader >>>>>> [javac] Note: Some input files use unchecked or unsafe >>>>>> operations. >>>>>> [javac] Note: Recompile with -Xlint:unchecked for details. >>>>>> [javac] 61 errors >>>>>> [javac] 7 warnings >>>>>> >>>>>> BUILD FAILED >>>>>> /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/build.xml:143: >>>>>> Compile failed; see the compiler error output for details. >>>>>> at >>>>>> org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:1079) >>>>>> at >>>>>> org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:882) >>>>>> at >>>>>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) >>>>>> at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown >>>>>> Source) >>>>>> at >>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>>> at java.lang.reflect.Method.invoke(Method.java:601) >>>>>> at >>>>>> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) >>>>>> at org.apache.tools.ant.Task.perform(Task.java:348) >>>>>> at org.apache.tools.ant.Target.execute(Target.java:357) >>>>>> at org.apache.tools.ant.Target.performTasks(Target.java:385) >>>>>> at >>>>>> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) >>>>>> at >>>>>> org.apache.tools.ant.Project.executeTarget(Project.java:1306) >>>>>> at >>>>>> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) >>>>>> at >>>>>> org.apache.tools.ant.Project.executeTargets(Project.java:1189) >>>>>> at org.apache.tools.ant.Main.runBuild(Main.java:758) >>>>>> at org.apache.tools.ant.Main.startAnt(Main.java:217) >>>>>> at >>>>>> org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) >>>>>> at >>>>>> org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) >>>>>> >>>>>> Total time: 1 second >>>>>> make[2]: *** >>>>>> [../../../build/macosx-x86_64/JObjC.build/JObjC.jar] Error 1 >>>>>> make[1]: *** [all] Error 1 >>>>>> make: *** [all] Error 1 >> >> > > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: 248BDC07 (https://keys.indymedia.org/) > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > From tim.bell at oracle.com Fri Aug 10 21:03:41 2012 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 10 Aug 2012 14:03:41 -0700 Subject: RFR: 7190512 Fix for 7181175 broke hotspot/make/windows/create.bat builds. Message-ID: <5025772D.40409@oracle.com> Hello all- After the fixes for 7181175 hit the hotspot-rt forest, users noticed that hotspot/make/windows/create.bat builds were broken. This is a supplemental fix that restores building using that .bat file. Note that this is not on the 'product' build path at all - this is something HotSpot developers use to get a fast build of their VM changes. Dan - as gatekeeper-of-the-month, would you be able to take this? Thanks- Tim From daniel.daugherty at oracle.com Fri Aug 10 21:06:27 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 10 Aug 2012 15:06:27 -0600 Subject: RFR: 7190512 Fix for 7181175 broke hotspot/make/windows/create.bat builds. In-Reply-To: <5025772D.40409@oracle.com> References: <5025772D.40409@oracle.com> Message-ID: <502577D3.9020204@oracle.com> On 8/10/12 3:03 PM, Tim Bell wrote: > Hello all- > > After the fixes for 7181175 hit the hotspot-rt forest, users noticed > that hotspot/make/windows/create.bat builds were broken. > > This is a supplemental fix that restores building using that .bat > file. Note that this is not on the 'product' build path at all - this > is something HotSpot developers use to get a fast build of their VM > changes. > > Dan - as gatekeeper-of-the-month, would you be able to take this? > > Thanks- > > Tim Yes, I can take the fix, but the webrev link is missing... :-) Dan From tim.bell at oracle.com Fri Aug 10 21:07:05 2012 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 10 Aug 2012 14:07:05 -0700 Subject: RFR: 7190512 Fix for 7181175 broke hotspot/make/windows/create.bat builds. In-Reply-To: <5025772D.40409@oracle.com> References: <5025772D.40409@oracle.com> Message-ID: <502577F9.7030603@oracle.com> I wrote: > Hello all- > > After the fixes for 7181175 hit the hotspot-rt forest, users noticed > that hotspot/make/windows/create.bat builds were broken. > > This is a supplemental fix that restores building using that .bat > file. Note that this is not on the 'product' build path at all - this > is something HotSpot developers use to get a fast build of their VM > changes. > > Dan - as gatekeeper-of-the-month, would you be able to take this? D'oh - here is the webrev. It is a one-line fix: http://cr.openjdk.java.net/~tbell/7190512/webrev.00/ Tim From omajid at redhat.com Fri Aug 10 21:05:57 2012 From: omajid at redhat.com (Omair Majid) Date: Fri, 10 Aug 2012 17:05:57 -0400 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <1937898803.3144440.1344601253018.JavaMail.root@redhat.com> References: <1937898803.3144440.1344601253018.JavaMail.root@redhat.com> Message-ID: <502577B5.2000706@redhat.com> On 08/10/2012 08:20 AM, Andrew Hughes wrote: >>> I built jdk8/build successfully just last week. What issues are >>> you seeing? >> >> Errors building hotspot, I seem to recall. But I cant reproduce it >> anymore after pulling today. I can now confirm that the fix works for >> me >> with jdk8 too. >> > > This by any chance? > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-July/006259.html > Possibly. I don't have the build logs anymore, sorry. Omair From daniel.daugherty at oracle.com Fri Aug 10 21:08:42 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 10 Aug 2012 15:08:42 -0600 Subject: RFR: 7190512 Fix for 7181175 broke hotspot/make/windows/create.bat builds. In-Reply-To: <502577F9.7030603@oracle.com> References: <5025772D.40409@oracle.com> <502577F9.7030603@oracle.com> Message-ID: <5025785A.5020308@oracle.com> On 8/10/12 3:07 PM, Tim Bell wrote: > I wrote: >> Hello all- >> >> After the fixes for 7181175 hit the hotspot-rt forest, users noticed >> that hotspot/make/windows/create.bat builds were broken. >> >> This is a supplemental fix that restores building using that .bat >> file. Note that this is not on the 'product' build path at all - >> this is something HotSpot developers use to get a fast build of their >> VM changes. >> >> Dan - as gatekeeper-of-the-month, would you be able to take this? > > D'oh - here is the webrev. It is a one-line fix: > > http://cr.openjdk.java.net/~tbell/7190512/webrev.00/ > > Tim One-line addition of two double quotes... Gotta love Windows. Thumbs up! Dan From omajid at redhat.com Fri Aug 10 20:56:22 2012 From: omajid at redhat.com (Omair Majid) Date: Fri, 10 Aug 2012 16:56:22 -0400 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <5024FEA9.4020401@oracle.com> References: <2065351848.3145321.1344601476979.JavaMail.root@redhat.com> <5024FEA9.4020401@oracle.com> Message-ID: <50257576.7050103@redhat.com> Hi Anthony, On 08/10/2012 08:29 AM, Anthony Petrov wrote: > Actually, if Omair has a good automatic jtreg test, we would be happy to > get it checked in with this fix. Could we see a webrev for the test please? I have uploaded a new webrev that includes a test case too: http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/01/ The bug number in the jtreg test is entirely made up. Any thoughts for a better description or alternate locations for the test code? I can only run the test case on Linux, so that's what it's for. It needs gcc to build the native bits. The webrev is against jdk8/awt forest, if it matters. Thanks, Omair From tim.bell at oracle.com Sat Aug 11 02:12:06 2012 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 10 Aug 2012 19:12:06 -0700 Subject: RFR: 7190512 Fix for 7181175 broke hotspot/make/windows/create.bat builds. In-Reply-To: <5025785A.5020308@oracle.com> References: <5025772D.40409@oracle.com> <502577F9.7030603@oracle.com> <5025785A.5020308@oracle.com> Message-ID: <5025BF76.4030408@oracle.com> On 08/10/12 14:08, Daniel D. Daugherty wrote: > On 8/10/12 3:07 PM, Tim Bell wrote: >> I wrote: >>> Hello all- >>> >>> After the fixes for 7181175 hit the hotspot-rt forest, users noticed >>> that hotspot/make/windows/create.bat builds were broken. >>> >>> This is a supplemental fix that restores building using that .bat >>> file. Note that this is not on the 'product' build path at all - >>> this is something HotSpot developers use to get a fast build of >>> their VM changes. >>> >>> Dan - as gatekeeper-of-the-month, would you be able to take this? >> >> D'oh - here is the webrev. It is a one-line fix: >> >> http://cr.openjdk.java.net/~tbell/7190512/webrev.00/ >> >> Tim > > One-line addition of two double quotes... Gotta love Windows. > > Thumbs up! Thanks, Dan make/windows/create.bat and make/windows/build.bat both work OK for me with this change. I am not going to worry about make/windows/cross_build.bat because our Itanium systems were powered off in 2008. Tim From Dmitry.Samersoff at oracle.com Sat Aug 11 09:49:43 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 11 Aug 2012 13:49:43 +0400 Subject: RFR: 7190512 Fix for 7181175 broke hotspot/make/windows/create.bat builds. In-Reply-To: <5025785A.5020308@oracle.com> References: <5025772D.40409@oracle.com> <502577F9.7030603@oracle.com> <5025785A.5020308@oracle.com> Message-ID: <50262AB7.1060200@oracle.com> Dan, On 2012-08-11 01:08, Daniel D. Daugherty wrote: > One-line addition of two double quotes... Gotta love Windows. It's not about windows. Unpack workspace to "mypath with spaces" and try to build hotspot. Looks good for me. -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From martijnverburg at gmail.com Sat Aug 11 11:44:37 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sat, 11 Aug 2012 12:44:37 +0100 Subject: jdk8 makefile changes In-Reply-To: <6D686E00-4ABF-4D27-B9CA-A86004DA655A@oracle.com> References: <6E1102AE-5167-4FA8-888F-264EDA515E4C@oracle.com> <6D686E00-4ABF-4D27-B9CA-A86004DA655A@oracle.com> Message-ID: Hi all, Forgot to send this in: Ran on 10.7.2 OS X with latest Oracle JDK 7 binary as the bootstrapper. All ran fine, ../autoconf/configure did not have execute permissions though, so had to chmod u+x it. Not sure if that's a manual step you want people to take or not. A couple of errors which didn't seem to stop anything was: Generating source file: ComboBoxArrowButtonPainter.java [Error] encoded value was less than 0: encode(-8.326673E-17, 5.0, 11.0, 16.0) Generating source file: TabbedPaneTabAreaPainter.java [Error] Encountered Infinity: encode(-0.00877193, 0.0, 7.0, 7.0) There's a bunch of minor warnings as well, but a quick eyeball seemed to indicate they were warnings under the new and older style builds, we'll try to pick them off as part of the Adopt OpenJDK VM build. Maxed out my 4 cores nicely, sounds like my MBP is about to take off for Mars :-). Cheers, Martijn On 9 July 2012 23:12, Kelly O'Hair wrote: > The jdk8/build forest has been in sync for a few days, so anyone willing to try the new build system with OpenJDK 8, please > follow these instructions: > > hg clone http://hg.openjdk.java.net/jdk8/build jdk8-build > cd jdk8-build > sh ./get_source.sh > cd common/makefiles > ../autoconf/configure > make images > > Let us know what works, what doesn't. > > Many of us will be concentrating on binary comparisons over the next few days to insure that we are building > everything we did before, and the same content. > > -kto > > On Jul 3, 2012, at 11:38 AM, Kelly O'Hair wrote: > >> >> Heads up... >> >> We expect to do a sync up of the jdk8/build forest with the latest in the build-infra forest in the next few days. >> >> As the new build-infra project starts getting more solid and we contemplate when we can switch >> the default to building with the new build-infra Makefiles (we don't know exactly when yet). >> >> **** IMPORTANT NOTICE **** >> It will be important that *anyone* making *any* changes to the jdk8 Makefiles keep the build-dev >> or build-infra mailing lists informed. >> For a period of time we need to maintain two separate build mechanisms, and we want to make sure >> that both build the same thing. >> The hotspot repository is the one exception where we don't have two sets of makefiles, but we still >> would like to know when anyone is changing the makefiles or anything to do with the build process. >> ***************************** >> >> We will soon be running both builds and doing comparisons of the resulting j2sdk-image files from >> both to insure we match. So if we detect differences we will be tracking down how those differences >> happened (that's a hint that we will be watching :^). >> >> More information on the new build-infra Makefiles can be found at: >> http://openjdk.java.net/projects/build-infra/ >> >> User Guide is at: >> http://openjdk.java.net/projects/build-infra/guide.html >> >> Some preliminary timings for building the product image (effectively, build/j2sdk-image/): >> OLD NEW build-infra times (All estimates, similar VMs/Zones) >> linux_i586 (21m 59s) (08m 13s) >> linux_x64 (13m 34s) (07m 04s) >> solaris_i586 (26m 14s) (11m 31s) >> solaris_sparc (54m 02s) (28m 21s) >> windows_i586 (55m 49s) (32m 22s) (old used MKS, build-infra only uses CYGWIN) >> windows_x64 (36m 36s) (23m 50s) " " " >> >> Notes: >> * Machines with more processors will reduce the build time for build-infra builds, less so with the old Makefiles. >> * Always use local disk or /tmp (all above timings use /tmp, always local disk) >> * Above uses VMs for Windows and Linux, raw hardware would be faster >> * Use of ccache can sometimes speed things up, but can also skew the timings, >> in the above measurements OLD used ccache, NEW did not. >> >> -kto > From martijnverburg at gmail.com Sat Aug 11 16:04:14 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sat, 11 Aug 2012 17:04:14 +0100 Subject: webrev failure? Message-ID: Hi all, Apologies if these are the wrong mailing lists, but I'm assuming that the webrev tool falls under this domain somewhat. In order to get patches into the OpenJDK as cleanly as possible, we're looking to utilise webrev (since it's the std and all). Running "ksh ./make/scripts/webrev.ksh -f" over the latest jdk8/tl source (no patches, but a full build was completed using build-infra) and I got a host of errors: -------- SCM detected: mercurial hg: unknown command 'foutgoing' abort: cannot follow file not in parent revision: "Mercurial" abort: cannot follow file not in parent revision: "basic" abort: cannot follow file not in parent revision: "add" abort: cannot follow file not in parent revision: "annotate" .. .. -------- A separate, yet related set of errors are at http://pastebin.com/q0tF1A4m for sake of brevity in this mail. I assume I'm running this tool incorrectly, I expected a result of something like "You've changed nothing, nothing to se here move along please" :-) Cheers, Martijn From Dmitry.Samersoff at oracle.com Sat Aug 11 18:52:34 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 11 Aug 2012 22:52:34 +0400 Subject: webrev failure? In-Reply-To: References: Message-ID: <5026A9F2.7070605@oracle.com> Martin, 1. Make sure you have a forest extension 2. Try webrev -N to create webrev against your current workspace rather than against remote repository -Dmitry On 2012-08-11 20:04, Martijn Verburg wrote: > Hi all, > > Apologies if these are the wrong mailing lists, but I'm assuming that > the webrev tool falls under this domain somewhat. > > In order to get patches into the OpenJDK as cleanly as possible, we're > looking to utilise webrev (since it's the std and all). > > Running "ksh ./make/scripts/webrev.ksh -f" over the latest jdk8/tl > source (no patches, but a full build was completed using build-infra) > and I got a host of errors: > > -------- > > SCM detected: mercurial > hg: unknown command 'foutgoing' > abort: cannot follow file not in parent revision: "Mercurial" > abort: cannot follow file not in parent revision: "basic" > abort: cannot follow file not in parent revision: "add" > abort: cannot follow file not in parent revision: "annotate" > .. > .. > > -------- > > A separate, yet related set of errors are at > http://pastebin.com/q0tF1A4m for sake of brevity in this mail. > > I assume I'm running this tool incorrectly, I expected a result of > something like "You've changed nothing, nothing to se here move along > please" :-) > > Cheers, > Martijn > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From daniel.daugherty at oracle.com Sat Aug 11 19:12:28 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 11 Aug 2012 13:12:28 -0600 Subject: RFR: 7190512 Fix for 7181175 broke hotspot/make/windows/create.bat builds. In-Reply-To: <50262AB7.1060200@oracle.com> References: <5025772D.40409@oracle.com> <502577F9.7030603@oracle.com> <5025785A.5020308@oracle.com> <50262AB7.1060200@oracle.com> Message-ID: <5026AE9C.3080206@oracle.com> On 8/11/12 3:49 AM, Dmitry Samersoff wrote: > Dan, > > On 2012-08-11 01:08, Daniel D. Daugherty wrote: >> One-line addition of two double quotes... Gotta love Windows. > It's not about windows. Unpack workspace to "mypath with spaces" and try > to build hotspot. > > Looks good for me. I'm pretty sure that in this failure mode it was the backslashes. Tim B. can confirm. Sorry I won't be able to list you as a reviewer since the job was already in the JPRT-hotspotwest queue as of midnight last night. Dan From tim.bell at oracle.com Sat Aug 11 20:15:26 2012 From: tim.bell at oracle.com (Tim Bell) Date: Sat, 11 Aug 2012 13:15:26 -0700 Subject: RFR: 7190512 Fix for 7181175 broke hotspot/make/windows/create.bat builds. In-Reply-To: <5026AE9C.3080206@oracle.com> References: <5025772D.40409@oracle.com> <502577F9.7030603@oracle.com> <5025785A.5020308@oracle.com> <50262AB7.1060200@oracle.com> <5026AE9C.3080206@oracle.com> Message-ID: <5026BD5E.6000100@oracle.com> On 08/11/12 12:12, Daniel D. Daugherty wrote: > On 8/11/12 3:49 AM, Dmitry Samersoff wrote: >> Dan, >> >> On 2012-08-11 01:08, Daniel D. Daugherty wrote: >>> One-line addition of two double quotes... Gotta love Windows. >> It's not about windows. Unpack workspace to "mypath with spaces" and try >> to build hotspot. As in the old joke: The patient says 'Doctor, it hurts when I do this' Doctor says: 'Don't do that then' Paths with spaces in them are painful. Fixing it would take a lot of work, and the job would never stay finished. 'Don't do that' :-) >> >> Looks good for me. > > I'm pretty sure that in this failure mode it was the backslashes. > Tim B. can confirm. That was it. Thanks for the extra review- Tim > Sorry I won't be able to list you as a reviewer since the job was > already in the JPRT-hotspotwest queue as of midnight last night. > > Dan > From martijnverburg at gmail.com Sun Aug 12 10:16:34 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sun, 12 Aug 2012 11:16:34 +0100 Subject: webrev failure? In-Reply-To: <5026A9F2.7070605@oracle.com> References: <5026A9F2.7070605@oracle.com> Message-ID: Hi Dmitry, Thanks for the hints! After following the forest extension install instructions at http://hg.openjdk.java.net/jdk7u/jdk7u4/raw-file/tip/README-builds.html#hg and running "ksh ./make/scripts/webrev.ksh -N" I get: *** failed to import extension forest from forest_extension/forest.py: No module named repo SCM detected: mercurial *** failed to import extension forest from forest_extension/forest.py: No module named repo *** failed to import extension forest from forest_extension/forest.py: No module named repo *** failed to import extension forest from forest_extension/forest.py: No module named repo No outgoing, perhaps you haven't commited. *** failed to import extension forest from forest_extension/forest.py: No module named repo *** failed to import extension forest from forest_extension/forest.py: No module named repo *** failed to import extension forest from forest_extension/forest.py: No module named repo Workspace: /Users/karianna/Documents/workspace/jdk8_tl Output to: /Users/karianna/Documents/workspace/jdk8_tl/webrev Output Files: common/autoconf/configure patch cdiffs udiffs sdiffs frames old new get_source.sh patch cdiffs udiffs sdiffs frames old new index.html: Done. Output to: /Users/karianna/Documents/workspace/jdk8_tl/webrev So I'm a bit unsure about the "*** failed" messages but the "No outgoing, perhaps you haven't commited." makes complete sense. Do I need to alter forest.py in order to get the list of modules correct? Cheers, Martijn On 11 August 2012 19:52, Dmitry Samersoff wrote: > Martin, > > 1. Make sure you have a forest extension > 2. Try webrev -N to create webrev against your current workspace rather > than against remote repository > > -Dmitry > > On 2012-08-11 20:04, Martijn Verburg wrote: >> Hi all, >> >> Apologies if these are the wrong mailing lists, but I'm assuming that >> the webrev tool falls under this domain somewhat. >> >> In order to get patches into the OpenJDK as cleanly as possible, we're >> looking to utilise webrev (since it's the std and all). >> >> Running "ksh ./make/scripts/webrev.ksh -f" over the latest jdk8/tl >> source (no patches, but a full build was completed using build-infra) >> and I got a host of errors: >> >> -------- >> >> SCM detected: mercurial >> hg: unknown command 'foutgoing' >> abort: cannot follow file not in parent revision: "Mercurial" >> abort: cannot follow file not in parent revision: "basic" >> abort: cannot follow file not in parent revision: "add" >> abort: cannot follow file not in parent revision: "annotate" >> .. >> .. >> >> -------- >> >> A separate, yet related set of errors are at >> http://pastebin.com/q0tF1A4m for sake of brevity in this mail. >> >> I assume I'm running this tool incorrectly, I expected a result of >> something like "You've changed nothing, nothing to se here move along >> please" :-) >> >> Cheers, >> Martijn >> > > > -- > Dmitry Samersoff > Java Hotspot development team, SPB04 > * There will come soft rains ... > > From Dmitry.Samersoff at oracle.com Sun Aug 12 10:39:51 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Sun, 12 Aug 2012 14:39:51 +0400 Subject: webrev failure? In-Reply-To: References: <5026A9F2.7070605@oracle.com> Message-ID: <502787F7.4070501@oracle.com> Martijn, First step - you need to make hg st in your workspace working without extra warning It looks like something still wrong with your forest extension. I attached working one and below is two relevant lines from my ~/.hgrc [extensions] forest=/home/dms/.hgext/forest.py [format] usefncache=no -Dmitry On 2012-08-12 14:16, Martijn Verburg wrote: > Hi Dmitry, > > Thanks for the hints! After following the forest extension install > instructions at > http://hg.openjdk.java.net/jdk7u/jdk7u4/raw-file/tip/README-builds.html#hg > and running "ksh ./make/scripts/webrev.ksh -N" I get: > > *** failed to import extension forest from forest_extension/forest.py: > No module named repo > SCM detected: mercurial > *** failed to import extension forest from forest_extension/forest.py: > No module named repo > *** failed to import extension forest from forest_extension/forest.py: > No module named repo > *** failed to import extension forest from forest_extension/forest.py: > No module named repo > > No outgoing, perhaps you haven't commited. > *** failed to import extension forest from forest_extension/forest.py: > No module named repo > *** failed to import extension forest from forest_extension/forest.py: > No module named repo > *** failed to import extension forest from forest_extension/forest.py: > No module named repo > Workspace: /Users/karianna/Documents/workspace/jdk8_tl > Output to: /Users/karianna/Documents/workspace/jdk8_tl/webrev > Output Files: > common/autoconf/configure > patch cdiffs udiffs sdiffs frames old new > get_source.sh > patch cdiffs udiffs sdiffs frames old new > index.html: Done. > Output to: /Users/karianna/Documents/workspace/jdk8_tl/webrev > > So I'm a bit unsure about the "*** failed" messages but the "No > outgoing, perhaps you haven't commited." makes complete sense. > > Do I need to alter forest.py in order to get the list of modules correct? > > Cheers, > Martijn > > > On 11 August 2012 19:52, Dmitry Samersoff wrote: >> Martin, >> >> 1. Make sure you have a forest extension >> 2. Try webrev -N to create webrev against your current workspace rather >> than against remote repository >> >> -Dmitry >> >> On 2012-08-11 20:04, Martijn Verburg wrote: >>> Hi all, >>> >>> Apologies if these are the wrong mailing lists, but I'm assuming that >>> the webrev tool falls under this domain somewhat. >>> >>> In order to get patches into the OpenJDK as cleanly as possible, we're >>> looking to utilise webrev (since it's the std and all). >>> >>> Running "ksh ./make/scripts/webrev.ksh -f" over the latest jdk8/tl >>> source (no patches, but a full build was completed using build-infra) >>> and I got a host of errors: >>> >>> -------- >>> >>> SCM detected: mercurial >>> hg: unknown command 'foutgoing' >>> abort: cannot follow file not in parent revision: "Mercurial" >>> abort: cannot follow file not in parent revision: "basic" >>> abort: cannot follow file not in parent revision: "add" >>> abort: cannot follow file not in parent revision: "annotate" >>> .. >>> .. >>> >>> -------- >>> >>> A separate, yet related set of errors are at >>> http://pastebin.com/q0tF1A4m for sake of brevity in this mail. >>> >>> I assume I'm running this tool incorrectly, I expected a result of >>> something like "You've changed nothing, nothing to se here move along >>> please" :-) >>> >>> Cheers, >>> Martijn >>> >> >> >> -- >> Dmitry Samersoff >> Java Hotspot development team, SPB04 >> * There will come soft rains ... >> >> -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From martijnverburg at gmail.com Sun Aug 12 11:09:10 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sun, 12 Aug 2012 12:09:10 +0100 Subject: webrev failure? In-Reply-To: <502787F7.4070501@oracle.com> References: <5026A9F2.7070605@oracle.com> <502787F7.4070501@oracle.com> Message-ID: Hi Dmitry, I put your version of forest.py into my /Users/karianna/.hgext/ directory and I've altered my .hgrc file is as follows: ui.username=karianna [extensions] forest=/Users/karianna/.hgext/forest.py [format] usefncache=no Unfortunately I still get the same error. I am running on Mac OS X (10.7.2) but I don't think that should make a difference... Cheers, Martijn > Martijn, > > First step - you need to make > hg st > in your workspace working without extra warning > > It looks like something still wrong with your forest extension. > > I attached working one and below is two relevant lines from > my ~/.hgrc > > [extensions] > forest=/home/dms/.hgext/forest.py > > [format] > usefncache=no > > -Dmitry > > > On 2012-08-12 14:16, Martijn Verburg wrote: >> Hi Dmitry, >> >> Thanks for the hints! After following the forest extension install >> instructions at >> http://hg.openjdk.java.net/jdk7u/jdk7u4/raw-file/tip/README-builds.html#hg >> and running "ksh ./make/scripts/webrev.ksh -N" I get: >> >> *** failed to import extension forest from forest_extension/forest.py: >> No module named repo >> SCM detected: mercurial >> *** failed to import extension forest from forest_extension/forest.py: >> No module named repo >> *** failed to import extension forest from forest_extension/forest.py: >> No module named repo >> *** failed to import extension forest from forest_extension/forest.py: >> No module named repo >> >> No outgoing, perhaps you haven't commited. >> *** failed to import extension forest from forest_extension/forest.py: >> No module named repo >> *** failed to import extension forest from forest_extension/forest.py: >> No module named repo >> *** failed to import extension forest from forest_extension/forest.py: >> No module named repo >> Workspace: /Users/karianna/Documents/workspace/jdk8_tl >> Output to: /Users/karianna/Documents/workspace/jdk8_tl/webrev >> Output Files: >> common/autoconf/configure >> patch cdiffs udiffs sdiffs frames old new >> get_source.sh >> patch cdiffs udiffs sdiffs frames old new >> index.html: Done. >> Output to: /Users/karianna/Documents/workspace/jdk8_tl/webrev >> >> So I'm a bit unsure about the "*** failed" messages but the "No >> outgoing, perhaps you haven't commited." makes complete sense. >> >> Do I need to alter forest.py in order to get the list of modules correct? >> >> Cheers, >> Martijn >> >> >> On 11 August 2012 19:52, Dmitry Samersoff wrote: >>> Martin, >>> >>> 1. Make sure you have a forest extension >>> 2. Try webrev -N to create webrev against your current workspace rather >>> than against remote repository >>> >>> -Dmitry >>> >>> On 2012-08-11 20:04, Martijn Verburg wrote: >>>> Hi all, >>>> >>>> Apologies if these are the wrong mailing lists, but I'm assuming that >>>> the webrev tool falls under this domain somewhat. >>>> >>>> In order to get patches into the OpenJDK as cleanly as possible, we're >>>> looking to utilise webrev (since it's the std and all). >>>> >>>> Running "ksh ./make/scripts/webrev.ksh -f" over the latest jdk8/tl >>>> source (no patches, but a full build was completed using build-infra) >>>> and I got a host of errors: >>>> >>>> -------- >>>> >>>> SCM detected: mercurial >>>> hg: unknown command 'foutgoing' >>>> abort: cannot follow file not in parent revision: "Mercurial" >>>> abort: cannot follow file not in parent revision: "basic" >>>> abort: cannot follow file not in parent revision: "add" >>>> abort: cannot follow file not in parent revision: "annotate" >>>> .. >>>> .. >>>> >>>> -------- >>>> >>>> A separate, yet related set of errors are at >>>> http://pastebin.com/q0tF1A4m for sake of brevity in this mail. >>>> >>>> I assume I'm running this tool incorrectly, I expected a result of >>>> something like "You've changed nothing, nothing to se here move along >>>> please" :-) >>>> >>>> Cheers, >>>> Martijn >>>> >>> >>> >>> -- >>> Dmitry Samersoff >>> Java Hotspot development team, SPB04 >>> * There will come soft rains ... >>> >>> > > > -- > Dmitry Samersoff > Java Hotspot development team, SPB04 > * There will come soft rains ... > > From Dmitry.Samersoff at oracle.com Sun Aug 12 11:14:48 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Sun, 12 Aug 2012 15:14:48 +0400 Subject: webrev failure? In-Reply-To: References: <5026A9F2.7070605@oracle.com> <502787F7.4070501@oracle.com> Message-ID: <50279028.3040203@oracle.com> Martijn, What version of HG do you use? hg --version Can't help much with mac os, but the problem is somewhere in python/hg/forest ... -Dmitry On 2012-08-12 15:09, Martijn Verburg wrote: > Hi Dmitry, > > I put your version of forest.py into my /Users/karianna/.hgext/ > directory and I've altered my .hgrc file is as follows: > > ui.username=karianna > [extensions] > forest=/Users/karianna/.hgext/forest.py > [format] > usefncache=no > > Unfortunately I still get the same error. I am running on Mac OS X > (10.7.2) but I don't think that should make a difference... > > Cheers, > Martijn > >> Martijn, >> >> First step - you need to make >> hg st >> in your workspace working without extra warning >> >> It looks like something still wrong with your forest extension. >> >> I attached working one and below is two relevant lines from >> my ~/.hgrc >> >> [extensions] >> forest=/home/dms/.hgext/forest.py >> >> [format] >> usefncache=no >> >> -Dmitry >> >> >> On 2012-08-12 14:16, Martijn Verburg wrote: >>> Hi Dmitry, >>> >>> Thanks for the hints! After following the forest extension install >>> instructions at >>> http://hg.openjdk.java.net/jdk7u/jdk7u4/raw-file/tip/README-builds.html#hg >>> and running "ksh ./make/scripts/webrev.ksh -N" I get: >>> >>> *** failed to import extension forest from forest_extension/forest.py: >>> No module named repo >>> SCM detected: mercurial >>> *** failed to import extension forest from forest_extension/forest.py: >>> No module named repo >>> *** failed to import extension forest from forest_extension/forest.py: >>> No module named repo >>> *** failed to import extension forest from forest_extension/forest.py: >>> No module named repo >>> >>> No outgoing, perhaps you haven't commited. >>> *** failed to import extension forest from forest_extension/forest.py: >>> No module named repo >>> *** failed to import extension forest from forest_extension/forest.py: >>> No module named repo >>> *** failed to import extension forest from forest_extension/forest.py: >>> No module named repo >>> Workspace: /Users/karianna/Documents/workspace/jdk8_tl >>> Output to: /Users/karianna/Documents/workspace/jdk8_tl/webrev >>> Output Files: >>> common/autoconf/configure >>> patch cdiffs udiffs sdiffs frames old new >>> get_source.sh >>> patch cdiffs udiffs sdiffs frames old new >>> index.html: Done. >>> Output to: /Users/karianna/Documents/workspace/jdk8_tl/webrev >>> >>> So I'm a bit unsure about the "*** failed" messages but the "No >>> outgoing, perhaps you haven't commited." makes complete sense. >>> >>> Do I need to alter forest.py in order to get the list of modules correct? >>> >>> Cheers, >>> Martijn >>> >>> >>> On 11 August 2012 19:52, Dmitry Samersoff wrote: >>>> Martin, >>>> >>>> 1. Make sure you have a forest extension >>>> 2. Try webrev -N to create webrev against your current workspace rather >>>> than against remote repository >>>> >>>> -Dmitry >>>> >>>> On 2012-08-11 20:04, Martijn Verburg wrote: >>>>> Hi all, >>>>> >>>>> Apologies if these are the wrong mailing lists, but I'm assuming that >>>>> the webrev tool falls under this domain somewhat. >>>>> >>>>> In order to get patches into the OpenJDK as cleanly as possible, we're >>>>> looking to utilise webrev (since it's the std and all). >>>>> >>>>> Running "ksh ./make/scripts/webrev.ksh -f" over the latest jdk8/tl >>>>> source (no patches, but a full build was completed using build-infra) >>>>> and I got a host of errors: >>>>> >>>>> -------- >>>>> >>>>> SCM detected: mercurial >>>>> hg: unknown command 'foutgoing' >>>>> abort: cannot follow file not in parent revision: "Mercurial" >>>>> abort: cannot follow file not in parent revision: "basic" >>>>> abort: cannot follow file not in parent revision: "add" >>>>> abort: cannot follow file not in parent revision: "annotate" >>>>> .. >>>>> .. >>>>> >>>>> -------- >>>>> >>>>> A separate, yet related set of errors are at >>>>> http://pastebin.com/q0tF1A4m for sake of brevity in this mail. >>>>> >>>>> I assume I'm running this tool incorrectly, I expected a result of >>>>> something like "You've changed nothing, nothing to se here move along >>>>> please" :-) >>>>> >>>>> Cheers, >>>>> Martijn >>>>> >>>> >>>> >>>> -- >>>> Dmitry Samersoff >>>> Java Hotspot development team, SPB04 >>>> * There will come soft rains ... >>>> >>>> >> >> >> -- >> Dmitry Samersoff >> Java Hotspot development team, SPB04 >> * There will come soft rains ... >> >> -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From david.holmes at oracle.com Sun Aug 12 11:29:30 2012 From: david.holmes at oracle.com (David Holmes) Date: Sun, 12 Aug 2012 21:29:30 +1000 Subject: webrev failure? In-Reply-To: References: Message-ID: <5027939A.8060209@oracle.com> I had thought that webrev only tried to operate on a forest if you asked it to - and that that requires the forest extension. That said the forest extension is not working with recent mercurial versions. :( David On 12/08/2012 2:04 AM, Martijn Verburg wrote: > Hi all, > > Apologies if these are the wrong mailing lists, but I'm assuming that > the webrev tool falls under this domain somewhat. > > In order to get patches into the OpenJDK as cleanly as possible, we're > looking to utilise webrev (since it's the std and all). > > Running "ksh ./make/scripts/webrev.ksh -f" over the latest jdk8/tl > source (no patches, but a full build was completed using build-infra) > and I got a host of errors: > > -------- > > SCM detected: mercurial > hg: unknown command 'foutgoing' > abort: cannot follow file not in parent revision: "Mercurial" > abort: cannot follow file not in parent revision: "basic" > abort: cannot follow file not in parent revision: "add" > abort: cannot follow file not in parent revision: "annotate" > .. > .. > > -------- > > A separate, yet related set of errors are at > http://pastebin.com/q0tF1A4m for sake of brevity in this mail. > > I assume I'm running this tool incorrectly, I expected a result of > something like "You've changed nothing, nothing to se here move along > please" :-) > > Cheers, > Martijn From martijnverburg at gmail.com Sun Aug 12 11:38:44 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sun, 12 Aug 2012 12:38:44 +0100 Subject: webrev failure? In-Reply-To: <50279028.3040203@oracle.com> References: <5026A9F2.7070605@oracle.com> <502787F7.4070501@oracle.com> <50279028.3040203@oracle.com> Message-ID: Hi Dmitry, It reports Mercurial Distributed SCM (version 2.3) Cheers, Martijn On 12 August 2012 12:14, Dmitry Samersoff wrote: > Martijn, > > What version of HG do you use? > > hg --version > > > Can't help much with mac os, but the problem is somewhere in > python/hg/forest ... > > -Dmitry > > On 2012-08-12 15:09, Martijn Verburg wrote: >> Hi Dmitry, >> >> I put your version of forest.py into my /Users/karianna/.hgext/ >> directory and I've altered my .hgrc file is as follows: >> >> ui.username=karianna >> [extensions] >> forest=/Users/karianna/.hgext/forest.py >> [format] >> usefncache=no >> >> Unfortunately I still get the same error. I am running on Mac OS X >> (10.7.2) but I don't think that should make a difference... >> >> Cheers, >> Martijn >> >>> Martijn, >>> >>> First step - you need to make >>> hg st >>> in your workspace working without extra warning >>> >>> It looks like something still wrong with your forest extension. >>> >>> I attached working one and below is two relevant lines from >>> my ~/.hgrc >>> >>> [extensions] >>> forest=/home/dms/.hgext/forest.py >>> >>> [format] >>> usefncache=no >>> >>> -Dmitry >>> >>> >>> On 2012-08-12 14:16, Martijn Verburg wrote: >>>> Hi Dmitry, >>>> >>>> Thanks for the hints! After following the forest extension install >>>> instructions at >>>> http://hg.openjdk.java.net/jdk7u/jdk7u4/raw-file/tip/README-builds.html#hg >>>> and running "ksh ./make/scripts/webrev.ksh -N" I get: >>>> >>>> *** failed to import extension forest from forest_extension/forest.py: >>>> No module named repo >>>> SCM detected: mercurial >>>> *** failed to import extension forest from forest_extension/forest.py: >>>> No module named repo >>>> *** failed to import extension forest from forest_extension/forest.py: >>>> No module named repo >>>> *** failed to import extension forest from forest_extension/forest.py: >>>> No module named repo >>>> >>>> No outgoing, perhaps you haven't commited. >>>> *** failed to import extension forest from forest_extension/forest.py: >>>> No module named repo >>>> *** failed to import extension forest from forest_extension/forest.py: >>>> No module named repo >>>> *** failed to import extension forest from forest_extension/forest.py: >>>> No module named repo >>>> Workspace: /Users/karianna/Documents/workspace/jdk8_tl >>>> Output to: /Users/karianna/Documents/workspace/jdk8_tl/webrev >>>> Output Files: >>>> common/autoconf/configure >>>> patch cdiffs udiffs sdiffs frames old new >>>> get_source.sh >>>> patch cdiffs udiffs sdiffs frames old new >>>> index.html: Done. >>>> Output to: /Users/karianna/Documents/workspace/jdk8_tl/webrev >>>> >>>> So I'm a bit unsure about the "*** failed" messages but the "No >>>> outgoing, perhaps you haven't commited." makes complete sense. >>>> >>>> Do I need to alter forest.py in order to get the list of modules correct? >>>> >>>> Cheers, >>>> Martijn >>>> >>>> >>>> On 11 August 2012 19:52, Dmitry Samersoff wrote: >>>>> Martin, >>>>> >>>>> 1. Make sure you have a forest extension >>>>> 2. Try webrev -N to create webrev against your current workspace rather >>>>> than against remote repository >>>>> >>>>> -Dmitry >>>>> >>>>> On 2012-08-11 20:04, Martijn Verburg wrote: >>>>>> Hi all, >>>>>> >>>>>> Apologies if these are the wrong mailing lists, but I'm assuming that >>>>>> the webrev tool falls under this domain somewhat. >>>>>> >>>>>> In order to get patches into the OpenJDK as cleanly as possible, we're >>>>>> looking to utilise webrev (since it's the std and all). >>>>>> >>>>>> Running "ksh ./make/scripts/webrev.ksh -f" over the latest jdk8/tl >>>>>> source (no patches, but a full build was completed using build-infra) >>>>>> and I got a host of errors: >>>>>> >>>>>> -------- >>>>>> >>>>>> SCM detected: mercurial >>>>>> hg: unknown command 'foutgoing' >>>>>> abort: cannot follow file not in parent revision: "Mercurial" >>>>>> abort: cannot follow file not in parent revision: "basic" >>>>>> abort: cannot follow file not in parent revision: "add" >>>>>> abort: cannot follow file not in parent revision: "annotate" >>>>>> .. >>>>>> .. >>>>>> >>>>>> -------- >>>>>> >>>>>> A separate, yet related set of errors are at >>>>>> http://pastebin.com/q0tF1A4m for sake of brevity in this mail. >>>>>> >>>>>> I assume I'm running this tool incorrectly, I expected a result of >>>>>> something like "You've changed nothing, nothing to se here move along >>>>>> please" :-) >>>>>> >>>>>> Cheers, >>>>>> Martijn >>>>>> >>>>> >>>>> >>>>> -- >>>>> Dmitry Samersoff >>>>> Java Hotspot development team, SPB04 >>>>> * There will come soft rains ... >>>>> >>>>> >>> >>> >>> -- >>> Dmitry Samersoff >>> Java Hotspot development team, SPB04 >>> * There will come soft rains ... >>> >>> > > > -- > Dmitry Samersoff > Java Hotspot development team, SPB04 > * There will come soft rains ... > > From martijnverburg at gmail.com Sun Aug 12 11:39:57 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sun, 12 Aug 2012 12:39:57 +0100 Subject: webrev failure? In-Reply-To: <5027939A.8060209@oracle.com> References: <5027939A.8060209@oracle.com> Message-ID: Hi David, Aha! :-). Any ideas on how far I need to downgrade the version of hg? (I'm 2.3 at the moment). Cheers, Martijn On 12 August 2012 12:29, David Holmes wrote: > I had thought that webrev only tried to operate on a forest if you asked it > to - and that that requires the forest extension. > > That said the forest extension is not working with recent mercurial > versions. :( > > David > > > On 12/08/2012 2:04 AM, Martijn Verburg wrote: >> >> Hi all, >> >> Apologies if these are the wrong mailing lists, but I'm assuming that >> the webrev tool falls under this domain somewhat. >> >> In order to get patches into the OpenJDK as cleanly as possible, we're >> looking to utilise webrev (since it's the std and all). >> >> Running "ksh ./make/scripts/webrev.ksh -f" over the latest jdk8/tl >> source (no patches, but a full build was completed using build-infra) >> and I got a host of errors: >> >> -------- >> >> SCM detected: mercurial >> hg: unknown command 'foutgoing' >> abort: cannot follow file not in parent revision: "Mercurial" >> abort: cannot follow file not in parent revision: "basic" >> abort: cannot follow file not in parent revision: "add" >> abort: cannot follow file not in parent revision: "annotate" >> .. >> .. >> >> -------- >> >> A separate, yet related set of errors are at >> http://pastebin.com/q0tF1A4m for sake of brevity in this mail. >> >> I assume I'm running this tool incorrectly, I expected a result of >> something like "You've changed nothing, nothing to se here move along >> please" :-) >> >> Cheers, >> Martijn From david.holmes at oracle.com Sun Aug 12 21:49:33 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Aug 2012 07:49:33 +1000 Subject: webrev failure? In-Reply-To: References: <5027939A.8060209@oracle.com> Message-ID: <502824ED.10105@oracle.com> On 12/08/2012 9:39 PM, Martijn Verburg wrote: > Aha! :-). Any ideas on how far I need to downgrade the version of hg? > (I'm 2.3 at the moment). Unfortunately no. I just hit this myself with 2.3: > hg --version *** failed to import extension hgext.forest from ~/hg/forest.py: 'module' object has no attribute 'wirerepository' Mercurial Distributed SCM (version 2.3) but I don't know what version I had previously been using. David ----- > Cheers, > Martijn > > On 12 August 2012 12:29, David Holmes wrote: >> I had thought that webrev only tried to operate on a forest if you asked it >> to - and that that requires the forest extension. >> >> That said the forest extension is not working with recent mercurial >> versions. :( >> >> David >> >> >> On 12/08/2012 2:04 AM, Martijn Verburg wrote: >>> >>> Hi all, >>> >>> Apologies if these are the wrong mailing lists, but I'm assuming that >>> the webrev tool falls under this domain somewhat. >>> >>> In order to get patches into the OpenJDK as cleanly as possible, we're >>> looking to utilise webrev (since it's the std and all). >>> >>> Running "ksh ./make/scripts/webrev.ksh -f" over the latest jdk8/tl >>> source (no patches, but a full build was completed using build-infra) >>> and I got a host of errors: >>> >>> -------- >>> >>> SCM detected: mercurial >>> hg: unknown command 'foutgoing' >>> abort: cannot follow file not in parent revision: "Mercurial" >>> abort: cannot follow file not in parent revision: "basic" >>> abort: cannot follow file not in parent revision: "add" >>> abort: cannot follow file not in parent revision: "annotate" >>> .. >>> .. >>> >>> -------- >>> >>> A separate, yet related set of errors are at >>> http://pastebin.com/q0tF1A4m for sake of brevity in this mail. >>> >>> I assume I'm running this tool incorrectly, I expected a result of >>> something like "You've changed nothing, nothing to se here move along >>> please" :-) >>> >>> Cheers, >>> Martijn From chris.hegarty at oracle.com Sun Aug 12 22:15:05 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 12 Aug 2012 23:15:05 +0100 Subject: webrev failure? In-Reply-To: References: Message-ID: <50282AE9.7070902@oracle.com> Martin, Unless you have changes that span multiple repositories, then it can be quite straight forward to run webrev ( without '-f ) on just the individual repository that you are changing. It will run with simply 'hg out'. If you have changes in multiple repo's then you have other choices: 1) run webrev on each individually, and include all the links in the review mail 2) create a 'file.list' ( a file containing your changed files, one file name per line ), and pass it as the final arg to webrev 3) Run with a really really old hg ( I use 0.9.5 ) and an installed forest extension. Now, 'webrev -f' should work just fine ;-) -Chris. On 11/08/12 17:04, Martijn Verburg wrote: > Hi all, > > Apologies if these are the wrong mailing lists, but I'm assuming that > the webrev tool falls under this domain somewhat. > > In order to get patches into the OpenJDK as cleanly as possible, we're > looking to utilise webrev (since it's the std and all). > > Running "ksh ./make/scripts/webrev.ksh -f" over the latest jdk8/tl > source (no patches, but a full build was completed using build-infra) > and I got a host of errors: > > -------- > > SCM detected: mercurial > hg: unknown command 'foutgoing' > abort: cannot follow file not in parent revision: "Mercurial" > abort: cannot follow file not in parent revision: "basic" > abort: cannot follow file not in parent revision: "add" > abort: cannot follow file not in parent revision: "annotate" > .. > .. > > -------- > > A separate, yet related set of errors are at > http://pastebin.com/q0tF1A4m for sake of brevity in this mail. > > I assume I'm running this tool incorrectly, I expected a result of > something like "You've changed nothing, nothing to se here move along > please" :-) > > Cheers, > Martijn > From david.holmes at oracle.com Sun Aug 12 23:56:09 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Aug 2012 09:56:09 +1000 Subject: webrev failure? In-Reply-To: <502824ED.10105@oracle.com> References: <5027939A.8060209@oracle.com> <502824ED.10105@oracle.com> Message-ID: <50284299.3010500@oracle.com> Reverting to 2.2.1 seems to have fixed things for me. But I tend not to use the -f option with webrev anyway. David On 13/08/2012 7:49 AM, David Holmes wrote: > On 12/08/2012 9:39 PM, Martijn Verburg wrote: >> Aha! :-). Any ideas on how far I need to downgrade the version of hg? >> (I'm 2.3 at the moment). > > Unfortunately no. I just hit this myself with 2.3: > > > hg --version > *** failed to import extension hgext.forest from ~/hg/forest.py: > 'module' object has no attribute 'wirerepository' > Mercurial Distributed SCM (version 2.3) > > but I don't know what version I had previously been using. > > David > ----- > >> Cheers, >> Martijn >> >> On 12 August 2012 12:29, David Holmes wrote: >>> I had thought that webrev only tried to operate on a forest if you >>> asked it >>> to - and that that requires the forest extension. >>> >>> That said the forest extension is not working with recent mercurial >>> versions. :( >>> >>> David >>> >>> >>> On 12/08/2012 2:04 AM, Martijn Verburg wrote: >>>> >>>> Hi all, >>>> >>>> Apologies if these are the wrong mailing lists, but I'm assuming that >>>> the webrev tool falls under this domain somewhat. >>>> >>>> In order to get patches into the OpenJDK as cleanly as possible, we're >>>> looking to utilise webrev (since it's the std and all). >>>> >>>> Running "ksh ./make/scripts/webrev.ksh -f" over the latest jdk8/tl >>>> source (no patches, but a full build was completed using build-infra) >>>> and I got a host of errors: >>>> >>>> -------- >>>> >>>> SCM detected: mercurial >>>> hg: unknown command 'foutgoing' >>>> abort: cannot follow file not in parent revision: "Mercurial" >>>> abort: cannot follow file not in parent revision: "basic" >>>> abort: cannot follow file not in parent revision: "add" >>>> abort: cannot follow file not in parent revision: "annotate" >>>> .. >>>> .. >>>> >>>> -------- >>>> >>>> A separate, yet related set of errors are at >>>> http://pastebin.com/q0tF1A4m for sake of brevity in this mail. >>>> >>>> I assume I'm running this tool incorrectly, I expected a result of >>>> something like "You've changed nothing, nothing to se here move along >>>> please" :-) >>>> >>>> Cheers, >>>> Martijn From kumar.x.srinivasan at oracle.COM Mon Aug 13 10:22:11 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Mon, 13 Aug 2012 03:22:11 -0700 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <50257576.7050103@redhat.com> References: <2065351848.3145321.1344601476979.JavaMail.root@redhat.com> <5024FEA9.4020401@oracle.com> <50257576.7050103@redhat.com> Message-ID: <5028D553.4070501@oracle.COM> On 8/10/2012 1:56 PM, Omair Majid wrote: > Hi Anthony, > > On 08/10/2012 08:29 AM, Anthony Petrov wrote: >> Actually, if Omair has a good automatic jtreg test, we would be happy to >> get it checked in with this fix. Could we see a webrev for the test please? > I have uploaded a new webrev that includes a test case too: > http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/01/ > > The bug number in the jtreg test is entirely made up. Any thoughts for a > better description or alternate locations for the test code? I filed a bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7190813 > > I can only run the test case on Linux, so that's what it's for. It needs > gcc to build the native bits. The webrev is against jdk8/awt forest, if > it matters. I am not happy with this test!, as it tests only linux, I am in the process of creating a generic (Non-binary) test. So please stay tuned...... Kumar > > Thanks, > Omair From anthony.petrov at oracle.com Mon Aug 13 14:10:38 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 13 Aug 2012 18:10:38 +0400 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <50257576.7050103@redhat.com> References: <2065351848.3145321.1344601476979.JavaMail.root@redhat.com> <5024FEA9.4020401@oracle.com> <50257576.7050103@redhat.com> Message-ID: <50290ADE.6010308@oracle.com> Hi Omair and Kumar, As to me, the fix and the test look good. A few suggestions: 1. Mac is also a supported platform now, so you need to add the "Darwin" option to the "SunOS | Windows_* )" case in the .sh file. 2. If gcc is not present, this should be considered that the test is passed. Systems used for running tests may lack compilers, and this is perfectly OK. Having said that, let's wait and see what test Kumar has to offer. -- best regards, Anthony On 08/11/12 00:56, Omair Majid wrote: > Hi Anthony, > > On 08/10/2012 08:29 AM, Anthony Petrov wrote: >> Actually, if Omair has a good automatic jtreg test, we would be happy to >> get it checked in with this fix. Could we see a webrev for the test please? > > I have uploaded a new webrev that includes a test case too: > http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/01/ > > The bug number in the jtreg test is entirely made up. Any thoughts for a > better description or alternate locations for the test code? > > I can only run the test case on Linux, so that's what it's for. It needs > gcc to build the native bits. The webrev is against jdk8/awt forest, if > it matters. > > Thanks, > Omair From kumar.x.srinivasan at oracle.COM Mon Aug 13 14:22:13 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Mon, 13 Aug 2012 07:22:13 -0700 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <50290ADE.6010308@oracle.com> References: <2065351848.3145321.1344601476979.JavaMail.root@redhat.com> <5024FEA9.4020401@oracle.com> <50257576.7050103@redhat.com> <50290ADE.6010308@oracle.com> Message-ID: <50290D95.60009@oracle.COM> Hi Anthony, Omair. Here is the patch for the test, this will live in test/tools/launcher, also I don't have access to a MacOS system, appreciate if you can add this otherwise I will file a bug and add the macosx case later on. Thanks Kumar > Hi Omair and Kumar, > > As to me, the fix and the test look good. A few suggestions: > > 1. Mac is also a supported platform now, so you need to add the > "Darwin" option to the "SunOS | Windows_* )" case in the .sh file. > > 2. If gcc is not present, this should be considered that the test is > passed. Systems used for running tests may lack compilers, and this is > perfectly OK. > > Having said that, let's wait and see what test Kumar has to offer. > > -- > best regards, > Anthony > > On 08/11/12 00:56, Omair Majid wrote: >> Hi Anthony, >> >> On 08/10/2012 08:29 AM, Anthony Petrov wrote: >>> Actually, if Omair has a good automatic jtreg test, we would be >>> happy to >>> get it checked in with this fix. Could we see a webrev for the test >>> please? >> >> I have uploaded a new webrev that includes a test case too: >> http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/01/ >> >> The bug number in the jtreg test is entirely made up. Any thoughts for a >> better description or alternate locations for the test code? >> >> I can only run the test case on Linux, so that's what it's for. It needs >> gcc to build the native bits. The webrev is against jdk8/awt forest, if >> it matters. >> >> Thanks, >> Omair -------------- next part -------------- diff --git a/test/tools/launcher/RunpathTest.java b/test/tools/launcher/RunpathTest.java new file mode 100644 --- /dev/null +++ b/test/tools/launcher/RunpathTest.java @@ -0,0 +1,83 @@ +/* + * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 7190813 + * @summary Check for extended RPATHs on *nixes + * @compile -XDignore.symbol.file RunpathTest.java + * @run main RunpathTest + */ + +import java.io.File; + +public class RunpathTest extends TestHelper { + + final String elfreaderCmd; + RunpathTest() { + elfreaderCmd = findElfReader(); + } + + final String findElfReader() { + String[] paths = {"/bin", "/sbin", "/usr/bin", "/usr/sbin", "/usr/ccs/bin"}; + final String cmd = isSolaris ? "elfdump" : "readelf"; + for (String x : paths) { + File p = new File(x); + File e = new File(p, cmd); + if (e.canExecute()) { + return e.getAbsolutePath(); + } + } + System.err.println("Warning: no suitable elf reader!"); + return null; + } + + void elfCheck(String javacmd, String expectedRpath) { + final TestResult tr = doExec(elfreaderCmd, "-d", javacmd); + if (!tr.matches(expectedRpath)) { + System.out.println(tr); + throw new RuntimeException("FAILED: RPATH strings " + + expectedRpath + " not found in " + javaCmd); + } + System.out.println(javacmd + " contains expected RPATHS"); + } + + void testRpath() { + if (isDualMode && is64Bit) { + String expectedRpath = ".*RPATH.*\\$ORIGIN/../../lib/" + getJreArch() + + ":\\$ORIGIN/../../jre/lib/" + getJreArch() + ".*"; + elfCheck(java64Cmd, expectedRpath); + } else { + String expectedRpath = ".*RPATH.*\\$ORIGIN/../lib/" + getJreArch() + + ":\\$ORIGIN/../jre/lib/" + getJreArch() + ".*"; + elfCheck(javaCmd, expectedRpath); + } + } + + public static void main(String... args) throws Exception { + if (isSolaris || isLinux) { + RunpathTest rp = new RunpathTest(); + rp.testRpath(); + } + } +} From anthony.petrov at oracle.com Mon Aug 13 14:39:42 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 13 Aug 2012 18:39:42 +0400 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <50290D95.60009@oracle.COM> References: <2065351848.3145321.1344601476979.JavaMail.root@redhat.com> <5024FEA9.4020401@oracle.com> <50257576.7050103@redhat.com> <50290ADE.6010308@oracle.com> <50290D95.60009@oracle.COM> Message-ID: <502911AE.40902@oracle.com> The test looks great, and I like that it doesn't depend on the JAWT machinery, but tests the actual problematic RPATH entry only. +1 from me. -- best regards, Anthony On 08/13/12 18:22, Kumar Srinivasan wrote: > Hi Anthony, Omair. > > Here is the patch for the test, this will live in test/tools/launcher, > also I don't have access > to a MacOS system, appreciate if you can add this otherwise I will file > a bug and add > the macosx case later on. > > Thanks > > Kumar > >> Hi Omair and Kumar, >> >> As to me, the fix and the test look good. A few suggestions: >> >> 1. Mac is also a supported platform now, so you need to add the >> "Darwin" option to the "SunOS | Windows_* )" case in the .sh file. >> >> 2. If gcc is not present, this should be considered that the test is >> passed. Systems used for running tests may lack compilers, and this is >> perfectly OK. >> >> Having said that, let's wait and see what test Kumar has to offer. >> >> -- >> best regards, >> Anthony >> >> On 08/11/12 00:56, Omair Majid wrote: >>> Hi Anthony, >>> >>> On 08/10/2012 08:29 AM, Anthony Petrov wrote: >>>> Actually, if Omair has a good automatic jtreg test, we would be >>>> happy to >>>> get it checked in with this fix. Could we see a webrev for the test >>>> please? >>> >>> I have uploaded a new webrev that includes a test case too: >>> http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/01/ >>> >>> The bug number in the jtreg test is entirely made up. Any thoughts for a >>> better description or alternate locations for the test code? >>> >>> I can only run the test case on Linux, so that's what it's for. It needs >>> gcc to build the native bits. The webrev is against jdk8/awt forest, if >>> it matters. >>> >>> Thanks, >>> Omair > From omajid at redhat.com Mon Aug 13 15:04:55 2012 From: omajid at redhat.com (Omair Majid) Date: Mon, 13 Aug 2012 11:04:55 -0400 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <502911AE.40902@oracle.com> References: <2065351848.3145321.1344601476979.JavaMail.root@redhat.com> <5024FEA9.4020401@oracle.com> <50257576.7050103@redhat.com> <50290ADE.6010308@oracle.com> <50290D95.60009@oracle.COM> <502911AE.40902@oracle.com> Message-ID: <50291797.7060007@redhat.com> On 08/13/2012 10:39 AM, Anthony Petrov wrote: > The test looks great, and I like that it doesn't depend on the JAWT > machinery, but tests the actual problematic RPATH entry only. I generally go for tests that verify behaviour (that jawt-linked programs are working) rather than implementation details (which changed, for example, when we switched from LD_LIBRARY_PATH to RPATHS). > +1 from me. Yes, good to have something that guards us from changing something unintentionally. Looks fine to me too. Cheers, Omair From sean.coffey at oracle.com Mon Aug 13 16:09:54 2012 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Mon, 13 Aug 2012 17:09:54 +0100 Subject: RFR : 7185965 Build error in javadoc make stage for bundles not containing crypto package Message-ID: <502926D2.8040402@oracle.com> Similar to 7163470, the JDK has historically allowed builds without the javax.crypto package src. In such cases a jce.jar bootstrap should be used where necessary. One remaining use case is during javadoc building process. Simple fix and I've verified with a test build of docs. bug report : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7185965 webrev : http://cr.openjdk.java.net/~coffeys/webrev.7185965.jdk8/ Regards, Sean. From mark at klomp.org Mon Aug 13 16:05:22 2012 From: mark at klomp.org (Mark Wielaard) Date: Mon, 13 Aug 2012 18:05:22 +0200 Subject: webrev failure? In-Reply-To: References: <5027939A.8060209@oracle.com> Message-ID: <20120813160521.GE2509@toonder.wildebeest.org> On Sun, Aug 12, 2012 at 12:39:57PM +0100, Martijn Verburg wrote: > Aha! :-). Any ideas on how far I need to downgrade the version of hg? > (I'm 2.3 at the moment). I am at 2.2.3. The hgforest extension as maintained at http://icedtea.classpath.org/hg/hgforest (which is a merge of various hgforest forks) works with that. It is also the version that is installed on the icedtea server itself to host forests. If there are patches needed for 2.3 we can incorporate those too. Thanks, Mark From naoto.sato at oracle.com Mon Aug 13 21:43:33 2012 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 13 Aug 2012 14:43:33 -0700 Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data In-Reply-To: <5022D686.9070203@oracle.com> References: <4FFC93CF.40105@oracle.com> <5020E699.3000600@oracle.com> <5022D686.9070203@oracle.com> Message-ID: <50297505.7050603@oracle.com> Since I haven't heard any more comments from Erik/Kelly, I would like to push the changeset without the new build infra patch. Erik/Kelly, can you please give us an official "GO" in terms of the build related changes? Aside from build changes, I have updated the changeset based on an internal review: http://cr.openjdk.java.net/~naoto/6336885/webrev.01/ This includes: - a couple of fixes to the CLDR Converter - Added fallback for any bad SPI implementations which return null for requested instances. Still asking for review comments. Naoto On 8/8/12 2:13 PM, Naoto Sato wrote: > On 8/7/12 2:57 AM, Erik Joelsson wrote: >> See inline >> >> On 2012-07-13 22:20, Kelly O'Hair wrote: >>> Something seems strange here: >>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/make/java/java/localegen.sh.sdiff.html >>> >>> >>> It's like someone was avoiding overall quotes, but using them to add >>> spaces somehow... >>> I sure would like to get rid of this shell logic, seems like there are >>> lots repeated logic that >>> this script does over and over or could be done with makefile pattern >>> subst's instead of exec's. >> The new version isn't any worse than the old in my opinion. In >> build-infra, this file is indeed replaced with make logic. After having >> decoded both versions I'm confident in converting the changes. >>> Overall, just looking at the makefiles, the build-infra team may need >>> some time to fully absorb this into the >>> new makefiles, some of it will be trivial, not sure all of it will be. >>> >> I have applied the patch to a clone of build-infra and done the minimal >> changes to keep build-infra building, which was rather trivial. The >> resulting build has large differences since I haven't converted all of >> it yet. There are a couple of things that will require some more work, >> but not more than a day or two. >>> Not sure how to proceed here, the build-infra team does need an action >>> item to deal with this, maybe >>> before it gets integrated because I suspect the new makefiles will >>> break with all the filename or >>> directory changes. But I hate to hold up your integration plans. >> I see these as possible options: >> >> 1. Let this go in, build-infra will break in jdk8 until we do our next >> push and it trickles through the repos. >> 2. The build-infra project provides a patch with the full conversion >> that can go in together with these changes. >> 3. The build-infra project provides a simple patch which just keeps the >> build-infra-build from failing that can go in with these changes. >> >> The conversion needs to happen regardless of option. The changes >> required are pretty isolated from remaining build-infra work. What do >> you think? > > Either way is fine with me. If build-infra team prefers 2 or 3, please > give me the patch, and I will go ahead and merge them to my changeset. > > Naoto > >> >> Other than that, I have no objections to the review. >> >> /Erik >> >>> I'd like to get some advice from Erik on this before saying anything >>> further. >>> >>> -kto >>> >>> On Jul 10, 2012, at 1:42 PM, Naoto Sato wrote: >>> >>>> Hello, >>>> >>>> Please review the JDK8 changes for JEP 127: Improve Locale Data >>>> Packaging and Adopt Unicode CLDR Data >>>> (http://openjdk.java.net/jeps/127). The webrev is located at: >>>> >>>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/ >>>> >>>> The main bug id for this enhancement is: >>>> >>>> 6336885: RFE: Locale Data Deployment Enhancements >>>> >>>> Along with this, the following bugs/enhancements are also implemented >>>> in this change: >>>> >>>> 4609153 Provide locale data for Indic locales >>>> 5104387 Support for gl_ES locale (galician language) >>>> 6337471 desktop/system locale preferences support >>>> 7056139 (cal) SPI support for locale-dependent Calendar parameters >>>> 7058206 Provide CalendarData SPI for week params and display field >>>> value names >>>> 7073852 Support multiple scripts for digits and decimal symbols per >>>> locale >>>> 7079560 [Fmt-Da] Context dependent month names support in >>>> SimpleDateFormat >>>> 7171324 getAvailableLocales() of locale sensitive services should >>>> return the actual availability of locales >>>> 7151414 (cal) Support calendar type identification >>>> 7168528 LocaleServiceProvider needs to be aware of Locale extensions >>>> 7171372 (cal) locale's default Calendar should be created if unknown >>>> calendar is specified >>>> >>>> Please note that packaging changes that relate to Jigsaw module >>>> system aren't included in this changeset. >>>> >>>> Naoto Sato and Masayoshi Okutsu > From kumar.x.srinivasan at oracle.COM Mon Aug 13 21:57:32 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Mon, 13 Aug 2012 14:57:32 -0700 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <50291797.7060007@redhat.com> References: <2065351848.3145321.1344601476979.JavaMail.root@redhat.com> <5024FEA9.4020401@oracle.com> <50257576.7050103@redhat.com> <50290ADE.6010308@oracle.com> <50290D95.60009@oracle.COM> <502911AE.40902@oracle.com> <50291797.7060007@redhat.com> Message-ID: <5029784C.605@oracle.COM> I have pointed out some changes below, but there is a serious problem. You are checking for the system arch using uname but the java architecture may not be the same. For example we run 32-bit jdk on a 64bit system, this will cause test failures since we will be using the wrong path names. You can use the following to determine the java arch. % java -XshowSettings:props -version 2>&1 | grep os.arch other diffs follow..... @@ -22,16 +22,17 @@ # questions. # @test runtest.sh -# @bug 9999999 +# @bug 7190813 # @summary Native code linked against libjawt.so should be sufficent for libjawt.so to be found # @run shell runtest.sh -if [ "${TESTSRC}" = "" ] -then TESTSRC=. +set -x + +if [ "${TESTSRC}" = "" ]; then + TESTSRC=. fi -if [ "${TESTJAVA}" = "" ] -then +if [ "${TESTJAVA}" = "" ]; then PARENT=`dirname \`which java\`` TESTJAVA=`dirname ${PARENT}` echo "TESTJAVA not set, selecting " ${TESTJAVA} @@ -46,14 +47,10 @@ PS=":" FS="/" ;; - SunOS | Windows_* ) - echo "Test passed; only valid for Linux" + * ) + echo "Warning: test passes vacuously for non linux systems" exit 0; ;; - * ) - echo "Unrecognized system!" - exit 1; - ;; esac # Get ARCH specifics @@ -71,13 +68,13 @@ gcc -v > /dev/null 2>&1 if [ "$?" != 0 ] ; then - echo "No compiler found" - exit 1 + echo "Warning: No gcc compiler found, test passes vacuously" + exit 0 fi -JAVAC=${TEST_JAVA}${FS}bin${FS}javac -JAVAH=${TEST_JAVA}${FS}bin${FS}javah -JAVA=${TEST_JAVA}${FS}bin${FS}java +JAVAC=${TESTJAVA}${FS}bin${FS}javac +JAVAH=${TESTJAVA}${FS}bin${FS}javah +JAVA=${TESTJAVA}${FS}bin${FS}java $JAVAC -d . ${TESTSRC}${FS}TestJawt.java || exit 1 $JAVAH TestJawt || exit 1 Thanks Kumar > On 08/13/2012 10:39 AM, Anthony Petrov wrote: >> The test looks great, and I like that it doesn't depend on the JAWT >> machinery, but tests the actual problematic RPATH entry only. > I generally go for tests that verify behaviour (that jawt-linked > programs are working) rather than implementation details (which changed, > for example, when we switched from LD_LIBRARY_PATH to RPATHS). > >> +1 from me. > Yes, good to have something that guards us from changing something > unintentionally. Looks fine to me too. > > Cheers, > Omair From michael.fang at oracle.com Mon Aug 13 23:29:51 2012 From: michael.fang at oracle.com (michael.fang at oracle.com) Date: Mon, 13 Aug 2012 23:29:51 +0000 Subject: hg: jdk8/build/jdk: 2 new changesets Message-ID: <20120813233109.58E7A474FA@hg.openjdk.java.net> Changeset: 93ddd9560751 Author: youdwei Date: 2012-08-13 10:45 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/93ddd9560751 7189611: Venezuela current Currency should be Bs.F. Reviewed-by: okutsu ! src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 90a9acfde9e6 Author: mfang Date: 2012-08-13 16:26 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/90a9acfde9e6 Merge From vikramforum at yahoo.com Tue Aug 14 03:47:06 2012 From: vikramforum at yahoo.com (vikram_sp) Date: Mon, 13 Aug 2012 20:47:06 -0700 (PDT) Subject: /NO_BOOTDIR Message-ID: <33698607.post@talk.nabble.com> I am building openjdk for on x86 machine running Fedora 14. I have these settings ALT_BOOT_DIR=/opt/java/jdk1.7.0 After some build this problem is comming: boot strap java is not installed in /NO_BOOTDIR Why this problem is comming & what is the remedy? A call for help! ----- Vikram -- View this message in context: http://old.nabble.com/-NO_BOOTDIR-tp33698607p33698607.html Sent from the OpenJDK Build Infrastructure mailing list archive at Nabble.com. From weijun.wang at oracle.com Tue Aug 14 04:05:20 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 14 Aug 2012 12:05:20 +0800 Subject: /NO_BOOTDIR In-Reply-To: <33698607.post@talk.nabble.com> References: <33698607.post@talk.nabble.com> Message-ID: <5029CE80.6020305@oracle.com> It's ALT_BOOTDIR, not ALT_BOOT_DIR. On 08/14/2012 11:47 AM, vikram_sp wrote: > > I am building openjdk for on x86 machine running Fedora 14. I have these > settings > ALT_BOOT_DIR=/opt/java/jdk1.7.0 > > After some build this problem is comming: > boot strap java is not installed in /NO_BOOTDIR > > Why this problem is comming & what is the remedy? > A call for help! > > > ----- > Vikram > From erik.joelsson at oracle.com Tue Aug 14 06:40:05 2012 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 14 Aug 2012 08:40:05 +0200 Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data In-Reply-To: <50297505.7050603@oracle.com> References: <4FFC93CF.40105@oracle.com> <5020E699.3000600@oracle.com> <5022D686.9070203@oracle.com> <50297505.7050603@oracle.com> Message-ID: <5029F2C5.6030109@oracle.com> I finished making the changes yesterday, but didn't manage to get the patch completed before I had to run. (webrev and mercurial wouldn't cooperate). I will get it done asap today. /Erik On 2012-08-13 23:43, Naoto Sato wrote: > Since I haven't heard any more comments from Erik/Kelly, I would like > to push the changeset without the new build infra patch. Erik/Kelly, > can you please give us an official "GO" in terms of the build related > changes? > > Aside from build changes, I have updated the changeset based on an > internal review: > > http://cr.openjdk.java.net/~naoto/6336885/webrev.01/ > > This includes: > > - a couple of fixes to the CLDR Converter > - Added fallback for any bad SPI implementations which return null for > requested instances. > > Still asking for review comments. > > Naoto > > On 8/8/12 2:13 PM, Naoto Sato wrote: >> On 8/7/12 2:57 AM, Erik Joelsson wrote: >>> See inline >>> >>> On 2012-07-13 22:20, Kelly O'Hair wrote: >>>> Something seems strange here: >>>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/make/java/java/localegen.sh.sdiff.html >>>> >>>> >>>> >>>> It's like someone was avoiding overall quotes, but using them to add >>>> spaces somehow... >>>> I sure would like to get rid of this shell logic, seems like there are >>>> lots repeated logic that >>>> this script does over and over or could be done with makefile pattern >>>> subst's instead of exec's. >>> The new version isn't any worse than the old in my opinion. In >>> build-infra, this file is indeed replaced with make logic. After having >>> decoded both versions I'm confident in converting the changes. >>>> Overall, just looking at the makefiles, the build-infra team may need >>>> some time to fully absorb this into the >>>> new makefiles, some of it will be trivial, not sure all of it will be. >>>> >>> I have applied the patch to a clone of build-infra and done the minimal >>> changes to keep build-infra building, which was rather trivial. The >>> resulting build has large differences since I haven't converted all of >>> it yet. There are a couple of things that will require some more work, >>> but not more than a day or two. >>>> Not sure how to proceed here, the build-infra team does need an action >>>> item to deal with this, maybe >>>> before it gets integrated because I suspect the new makefiles will >>>> break with all the filename or >>>> directory changes. But I hate to hold up your integration plans. >>> I see these as possible options: >>> >>> 1. Let this go in, build-infra will break in jdk8 until we do our next >>> push and it trickles through the repos. >>> 2. The build-infra project provides a patch with the full conversion >>> that can go in together with these changes. >>> 3. The build-infra project provides a simple patch which just keeps the >>> build-infra-build from failing that can go in with these changes. >>> >>> The conversion needs to happen regardless of option. The changes >>> required are pretty isolated from remaining build-infra work. What do >>> you think? >> >> Either way is fine with me. If build-infra team prefers 2 or 3, please >> give me the patch, and I will go ahead and merge them to my changeset. >> >> Naoto >> >>> >>> Other than that, I have no objections to the review. >>> >>> /Erik >>> >>>> I'd like to get some advice from Erik on this before saying anything >>>> further. >>>> >>>> -kto >>>> >>>> On Jul 10, 2012, at 1:42 PM, Naoto Sato wrote: >>>> >>>>> Hello, >>>>> >>>>> Please review the JDK8 changes for JEP 127: Improve Locale Data >>>>> Packaging and Adopt Unicode CLDR Data >>>>> (http://openjdk.java.net/jeps/127). The webrev is located at: >>>>> >>>>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/ >>>>> >>>>> The main bug id for this enhancement is: >>>>> >>>>> 6336885: RFE: Locale Data Deployment Enhancements >>>>> >>>>> Along with this, the following bugs/enhancements are also implemented >>>>> in this change: >>>>> >>>>> 4609153 Provide locale data for Indic locales >>>>> 5104387 Support for gl_ES locale (galician language) >>>>> 6337471 desktop/system locale preferences support >>>>> 7056139 (cal) SPI support for locale-dependent Calendar parameters >>>>> 7058206 Provide CalendarData SPI for week params and display field >>>>> value names >>>>> 7073852 Support multiple scripts for digits and decimal symbols per >>>>> locale >>>>> 7079560 [Fmt-Da] Context dependent month names support in >>>>> SimpleDateFormat >>>>> 7171324 getAvailableLocales() of locale sensitive services should >>>>> return the actual availability of locales >>>>> 7151414 (cal) Support calendar type identification >>>>> 7168528 LocaleServiceProvider needs to be aware of Locale extensions >>>>> 7171372 (cal) locale's default Calendar should be created if unknown >>>>> calendar is specified >>>>> >>>>> Please note that packaging changes that relate to Jigsaw module >>>>> system aren't included in this changeset. >>>>> >>>>> Naoto Sato and Masayoshi Okutsu >> > From david.holmes at oracle.com Tue Aug 14 06:57:21 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Aug 2012 16:57:21 +1000 Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data In-Reply-To: <50297505.7050603@oracle.com> References: <4FFC93CF.40105@oracle.com> <5020E699.3000600@oracle.com> <5022D686.9070203@oracle.com> <50297505.7050603@oracle.com> Message-ID: <5029F6D1.1020602@oracle.com> Ni Naoto, Where will this be pushed to initially? It is a big set of changes, albeit localized (no pun intended :) ), so it would be good to see this get some bake time before propagating up. Further we're just about to have a "flag day" between hotspot and JDK due to JSR292 changes, so it would be good to also add some space between those changes and these ones - if that is feasible. This isn't my call, I'm just airing concerns :) Thanks, David On 14/08/2012 7:43 AM, Naoto Sato wrote: > Since I haven't heard any more comments from Erik/Kelly, I would like to > push the changeset without the new build infra patch. Erik/Kelly, can > you please give us an official "GO" in terms of the build related changes? > > Aside from build changes, I have updated the changeset based on an > internal review: > > http://cr.openjdk.java.net/~naoto/6336885/webrev.01/ > > This includes: > > - a couple of fixes to the CLDR Converter > - Added fallback for any bad SPI implementations which return null for > requested instances. > > Still asking for review comments. > > Naoto > > On 8/8/12 2:13 PM, Naoto Sato wrote: >> On 8/7/12 2:57 AM, Erik Joelsson wrote: >>> See inline >>> >>> On 2012-07-13 22:20, Kelly O'Hair wrote: >>>> Something seems strange here: >>>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/make/java/java/localegen.sh.sdiff.html >>>> >>>> >>>> >>>> It's like someone was avoiding overall quotes, but using them to add >>>> spaces somehow... >>>> I sure would like to get rid of this shell logic, seems like there are >>>> lots repeated logic that >>>> this script does over and over or could be done with makefile pattern >>>> subst's instead of exec's. >>> The new version isn't any worse than the old in my opinion. In >>> build-infra, this file is indeed replaced with make logic. After having >>> decoded both versions I'm confident in converting the changes. >>>> Overall, just looking at the makefiles, the build-infra team may need >>>> some time to fully absorb this into the >>>> new makefiles, some of it will be trivial, not sure all of it will be. >>>> >>> I have applied the patch to a clone of build-infra and done the minimal >>> changes to keep build-infra building, which was rather trivial. The >>> resulting build has large differences since I haven't converted all of >>> it yet. There are a couple of things that will require some more work, >>> but not more than a day or two. >>>> Not sure how to proceed here, the build-infra team does need an action >>>> item to deal with this, maybe >>>> before it gets integrated because I suspect the new makefiles will >>>> break with all the filename or >>>> directory changes. But I hate to hold up your integration plans. >>> I see these as possible options: >>> >>> 1. Let this go in, build-infra will break in jdk8 until we do our next >>> push and it trickles through the repos. >>> 2. The build-infra project provides a patch with the full conversion >>> that can go in together with these changes. >>> 3. The build-infra project provides a simple patch which just keeps the >>> build-infra-build from failing that can go in with these changes. >>> >>> The conversion needs to happen regardless of option. The changes >>> required are pretty isolated from remaining build-infra work. What do >>> you think? >> >> Either way is fine with me. If build-infra team prefers 2 or 3, please >> give me the patch, and I will go ahead and merge them to my changeset. >> >> Naoto >> >>> >>> Other than that, I have no objections to the review. >>> >>> /Erik >>> >>>> I'd like to get some advice from Erik on this before saying anything >>>> further. >>>> >>>> -kto >>>> >>>> On Jul 10, 2012, at 1:42 PM, Naoto Sato wrote: >>>> >>>>> Hello, >>>>> >>>>> Please review the JDK8 changes for JEP 127: Improve Locale Data >>>>> Packaging and Adopt Unicode CLDR Data >>>>> (http://openjdk.java.net/jeps/127). The webrev is located at: >>>>> >>>>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/ >>>>> >>>>> The main bug id for this enhancement is: >>>>> >>>>> 6336885: RFE: Locale Data Deployment Enhancements >>>>> >>>>> Along with this, the following bugs/enhancements are also implemented >>>>> in this change: >>>>> >>>>> 4609153 Provide locale data for Indic locales >>>>> 5104387 Support for gl_ES locale (galician language) >>>>> 6337471 desktop/system locale preferences support >>>>> 7056139 (cal) SPI support for locale-dependent Calendar parameters >>>>> 7058206 Provide CalendarData SPI for week params and display field >>>>> value names >>>>> 7073852 Support multiple scripts for digits and decimal symbols per >>>>> locale >>>>> 7079560 [Fmt-Da] Context dependent month names support in >>>>> SimpleDateFormat >>>>> 7171324 getAvailableLocales() of locale sensitive services should >>>>> return the actual availability of locales >>>>> 7151414 (cal) Support calendar type identification >>>>> 7168528 LocaleServiceProvider needs to be aware of Locale extensions >>>>> 7171372 (cal) locale's default Calendar should be created if unknown >>>>> calendar is specified >>>>> >>>>> Please note that packaging changes that relate to Jigsaw module >>>>> system aren't included in this changeset. >>>>> >>>>> Naoto Sato and Masayoshi Okutsu >> > From erik.joelsson at oracle.com Tue Aug 14 07:24:53 2012 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 14 Aug 2012 09:24:53 +0200 Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data In-Reply-To: <5029F2C5.6030109@oracle.com> References: <4FFC93CF.40105@oracle.com> <5020E699.3000600@oracle.com> <5022D686.9070203@oracle.com> <50297505.7050603@oracle.com> <5029F2C5.6030109@oracle.com> Message-ID: <5029FD45.7070404@oracle.com> And I'm done. http://cr.openjdk.java.net/~erikj/6336885/webrev.build-infra.00/ This is a patch on top of your latest webrev that I have verified to produce the same result on linux. This part will need some more eyes from build-infra on it too. I also changed make/java/java/localegen.sh, readding the sort to make builds easier to compare. This also has the added benefit of keeping the build more reproducible and less dependent on the file system of the build host. /Erik On 2012-08-14 08:40, Erik Joelsson wrote: > I finished making the changes yesterday, but didn't manage to get the > patch completed before I had to run. (webrev and mercurial wouldn't > cooperate). I will get it done asap today. > > /Erik > > On 2012-08-13 23:43, Naoto Sato wrote: >> Since I haven't heard any more comments from Erik/Kelly, I would like >> to push the changeset without the new build infra patch. Erik/Kelly, >> can you please give us an official "GO" in terms of the build related >> changes? >> >> Aside from build changes, I have updated the changeset based on an >> internal review: >> >> http://cr.openjdk.java.net/~naoto/6336885/webrev.01/ >> >> This includes: >> >> - a couple of fixes to the CLDR Converter >> - Added fallback for any bad SPI implementations which return null >> for requested instances. >> >> Still asking for review comments. >> >> Naoto >> >> On 8/8/12 2:13 PM, Naoto Sato wrote: >>> On 8/7/12 2:57 AM, Erik Joelsson wrote: >>>> See inline >>>> >>>> On 2012-07-13 22:20, Kelly O'Hair wrote: >>>>> Something seems strange here: >>>>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/make/java/java/localegen.sh.sdiff.html >>>>> >>>>> >>>>> >>>>> It's like someone was avoiding overall quotes, but using them to add >>>>> spaces somehow... >>>>> I sure would like to get rid of this shell logic, seems like there >>>>> are >>>>> lots repeated logic that >>>>> this script does over and over or could be done with makefile pattern >>>>> subst's instead of exec's. >>>> The new version isn't any worse than the old in my opinion. In >>>> build-infra, this file is indeed replaced with make logic. After >>>> having >>>> decoded both versions I'm confident in converting the changes. >>>>> Overall, just looking at the makefiles, the build-infra team may need >>>>> some time to fully absorb this into the >>>>> new makefiles, some of it will be trivial, not sure all of it will >>>>> be. >>>>> >>>> I have applied the patch to a clone of build-infra and done the >>>> minimal >>>> changes to keep build-infra building, which was rather trivial. The >>>> resulting build has large differences since I haven't converted all of >>>> it yet. There are a couple of things that will require some more work, >>>> but not more than a day or two. >>>>> Not sure how to proceed here, the build-infra team does need an >>>>> action >>>>> item to deal with this, maybe >>>>> before it gets integrated because I suspect the new makefiles will >>>>> break with all the filename or >>>>> directory changes. But I hate to hold up your integration plans. >>>> I see these as possible options: >>>> >>>> 1. Let this go in, build-infra will break in jdk8 until we do our next >>>> push and it trickles through the repos. >>>> 2. The build-infra project provides a patch with the full conversion >>>> that can go in together with these changes. >>>> 3. The build-infra project provides a simple patch which just keeps >>>> the >>>> build-infra-build from failing that can go in with these changes. >>>> >>>> The conversion needs to happen regardless of option. The changes >>>> required are pretty isolated from remaining build-infra work. What do >>>> you think? >>> >>> Either way is fine with me. If build-infra team prefers 2 or 3, please >>> give me the patch, and I will go ahead and merge them to my changeset. >>> >>> Naoto >>> >>>> >>>> Other than that, I have no objections to the review. >>>> >>>> /Erik >>>> >>>>> I'd like to get some advice from Erik on this before saying anything >>>>> further. >>>>> >>>>> -kto >>>>> >>>>> On Jul 10, 2012, at 1:42 PM, Naoto Sato wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> Please review the JDK8 changes for JEP 127: Improve Locale Data >>>>>> Packaging and Adopt Unicode CLDR Data >>>>>> (http://openjdk.java.net/jeps/127). The webrev is located at: >>>>>> >>>>>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/ >>>>>> >>>>>> The main bug id for this enhancement is: >>>>>> >>>>>> 6336885: RFE: Locale Data Deployment Enhancements >>>>>> >>>>>> Along with this, the following bugs/enhancements are also >>>>>> implemented >>>>>> in this change: >>>>>> >>>>>> 4609153 Provide locale data for Indic locales >>>>>> 5104387 Support for gl_ES locale (galician language) >>>>>> 6337471 desktop/system locale preferences support >>>>>> 7056139 (cal) SPI support for locale-dependent Calendar parameters >>>>>> 7058206 Provide CalendarData SPI for week params and display field >>>>>> value names >>>>>> 7073852 Support multiple scripts for digits and decimal symbols per >>>>>> locale >>>>>> 7079560 [Fmt-Da] Context dependent month names support in >>>>>> SimpleDateFormat >>>>>> 7171324 getAvailableLocales() of locale sensitive services should >>>>>> return the actual availability of locales >>>>>> 7151414 (cal) Support calendar type identification >>>>>> 7168528 LocaleServiceProvider needs to be aware of Locale extensions >>>>>> 7171372 (cal) locale's default Calendar should be created if unknown >>>>>> calendar is specified >>>>>> >>>>>> Please note that packaging changes that relate to Jigsaw module >>>>>> system aren't included in this changeset. >>>>>> >>>>>> Naoto Sato and Masayoshi Okutsu >>> >> From magnus.ihse.bursie at oracle.com Tue Aug 14 08:24:38 2012 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 14 Aug 2012 10:24:38 +0200 Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data In-Reply-To: <5029FD45.7070404@oracle.com> References: <4FFC93CF.40105@oracle.com> <5020E699.3000600@oracle.com> <5022D686.9070203@oracle.com> <50297505.7050603@oracle.com> <5029F2C5.6030109@oracle.com> <5029FD45.7070404@oracle.com> Message-ID: <502A0B46.8030106@oracle.com> On 2012-08-14 09:24, Erik Joelsson wrote: > And I'm done. > > http://cr.openjdk.java.net/~erikj/6336885/webrev.build-infra.00/ > > > This is a patch on top of your latest webrev that I have verified to > produce the same result on linux. This part will need some more eyes > from build-infra on it too. My eyes are at your disposal. ;-) I think it looks good. /Magnus From ahughes at redhat.com Tue Aug 14 09:17:45 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Tue, 14 Aug 2012 05:17:45 -0400 (EDT) Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <5029784C.605@oracle.COM> Message-ID: <1458136189.4421799.1344935865005.JavaMail.root@redhat.com> ----- Original Message ----- > I have pointed out some changes below, but there is a serious > problem. > You are checking for the system arch using uname but the > java architecture may not be the same. > > For example we run 32-bit jdk on a 64bit system, this will cause test > failures > since we will be using the wrong path names. > > You can use the following to determine the java arch. > > % java -XshowSettings:props -version 2>&1 | grep os.arch > This doesn't work (at least for me) unless the '-version' is removed. I also note that this seems to only be present in 7 and later (i.e. not 6), not that this will matter in this case. > other diffs follow..... > > @@ -22,16 +22,17 @@ > # questions. > > # @test runtest.sh > -# @bug 9999999 > +# @bug 7190813 > # @summary Native code linked against libjawt.so should be > sufficent > for libjawt.so to be found > # @run shell runtest.sh > > -if [ "${TESTSRC}" = "" ] > -then TESTSRC=. > +set -x > + > +if [ "${TESTSRC}" = "" ]; then > + TESTSRC=. > fi > > -if [ "${TESTJAVA}" = "" ] > -then > +if [ "${TESTJAVA}" = "" ]; then > PARENT=`dirname \`which java\`` > TESTJAVA=`dirname ${PARENT}` > echo "TESTJAVA not set, selecting " ${TESTJAVA} > @@ -46,14 +47,10 @@ > PS=":" > FS="/" > ;; > - SunOS | Windows_* ) > - echo "Test passed; only valid for Linux" > + * ) > + echo "Warning: test passes vacuously for non linux systems" > exit 0; > ;; > - * ) > - echo "Unrecognized system!" > - exit 1; > - ;; > esac > > # Get ARCH specifics > @@ -71,13 +68,13 @@ > > gcc -v > /dev/null 2>&1 > if [ "$?" != 0 ] ; then > - echo "No compiler found" > - exit 1 > + echo "Warning: No gcc compiler found, test passes vacuously" > + exit 0 > fi > > -JAVAC=${TEST_JAVA}${FS}bin${FS}javac > -JAVAH=${TEST_JAVA}${FS}bin${FS}javah > -JAVA=${TEST_JAVA}${FS}bin${FS}java > +JAVAC=${TESTJAVA}${FS}bin${FS}javac > +JAVAH=${TESTJAVA}${FS}bin${FS}javah > +JAVA=${TESTJAVA}${FS}bin${FS}java > > $JAVAC -d . ${TESTSRC}${FS}TestJawt.java || exit 1 > $JAVAH TestJawt || exit 1 > > > Thanks > Kumar > > > On 08/13/2012 10:39 AM, Anthony Petrov wrote: > >> The test looks great, and I like that it doesn't depend on the > >> JAWT > >> machinery, but tests the actual problematic RPATH entry only. > > I generally go for tests that verify behaviour (that jawt-linked > > programs are working) rather than implementation details (which > > changed, > > for example, when we switched from LD_LIBRARY_PATH to RPATHS). > > > >> +1 from me. > > Yes, good to have something that guards us from changing something > > unintentionally. Looks fine to me too. > > > > Cheers, > > Omair > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From ahughes at redhat.com Tue Aug 14 09:51:48 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Tue, 14 Aug 2012 05:51:48 -0400 (EDT) Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data In-Reply-To: <4FFC93CF.40105@oracle.com> Message-ID: <737597189.4451353.1344937908713.JavaMail.root@redhat.com> ----- Original Message ----- > Hello, > > Please review the JDK8 changes for JEP 127: Improve Locale Data > Packaging and Adopt Unicode CLDR Data > (http://openjdk.java.net/jeps/127). The webrev is located at: > > http://cr.openjdk.java.net/~naoto/6336885/webrev.00/ > > The main bug id for this enhancement is: > > 6336885: RFE: Locale Data Deployment Enhancements > > Along with this, the following bugs/enhancements are also implemented > in > this change: > > 4609153 Provide locale data for Indic locales > 5104387 Support for gl_ES locale (galician language) > 6337471 desktop/system locale preferences support > 7056139 (cal) SPI support for locale-dependent Calendar parameters > 7058206 Provide CalendarData SPI for week params and display field > value > names > 7073852 Support multiple scripts for digits and decimal symbols per > locale > 7079560 [Fmt-Da] Context dependent month names support in > SimpleDateFormat > 7171324 getAvailableLocales() of locale sensitive services should > return > the actual availability of locales > 7151414 (cal) Support calendar type identification > 7168528 LocaleServiceProvider needs to be aware of Locale extensions > 7171372 (cal) locale's default Calendar should be created if unknown > calendar is specified > > Please note that packaging changes that relate to Jigsaw module > system > aren't included in this changeset. > > Naoto Sato and Masayoshi Okutsu > First of all, I'd like to say congratulations on completing this week and adopting the CLDR as a source for locale data. This is something we've used for GNU Classpath's locale data for many years, and, with these changes, it should mean that the Java API itself should see changes which allow it to support some of the features present in the CLDR data. However, I am a little concerned by the inclusion of CLDR data files in this webrev with a GPL header assigning copyright to Oracle e.g. http://cr.openjdk.java.net/~naoto/6336885/webrev.00/src/share/classes/sun/util/cldr/resources/21_0_1/common/main/agq.xml.patch Is this legal? IANAL, but http://unicode.org/copyright.html#Exhibit1 seems to state that the header given there should be present on this data. The current files make it look like this data was created by Oracle this year, which is clearly inaccurate. Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From anthony.petrov at oracle.com Tue Aug 14 10:23:44 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 14 Aug 2012 14:23:44 +0400 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <50291797.7060007@redhat.com> References: <2065351848.3145321.1344601476979.JavaMail.root@redhat.com> <5024FEA9.4020401@oracle.com> <50257576.7050103@redhat.com> <50290ADE.6010308@oracle.com> <50290D95.60009@oracle.COM> <502911AE.40902@oracle.com> <50291797.7060007@redhat.com> Message-ID: <502A2730.8040001@oracle.com> I see your point. As I told you we'll be open-sourcing a JAWT-specific test under 7190587. This test already provides support for Linux, Solaris, and Windows platforms, and even does a little more than just loads the jawt library. So it looks there's still some value in Kumar's test as well. Yes, it will need to be rewritten should we replace the RPATH mechanism with something else in the future. It's up to Kumar to decide whether he wants such test to be present in the repo. Personally, I don't mind. -- best regards, Anthony On 8/13/2012 7:04 PM, Omair Majid wrote: > On 08/13/2012 10:39 AM, Anthony Petrov wrote: >> The test looks great, and I like that it doesn't depend on the JAWT >> machinery, but tests the actual problematic RPATH entry only. > > I generally go for tests that verify behaviour (that jawt-linked > programs are working) rather than implementation details (which changed, > for example, when we switched from LD_LIBRARY_PATH to RPATHS). > >> +1 from me. > > Yes, good to have something that guards us from changing something > unintentionally. Looks fine to me too. > > Cheers, > Omair From kumar.x.srinivasan at oracle.COM Tue Aug 14 11:13:28 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Tue, 14 Aug 2012 04:13:28 -0700 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <502A2730.8040001@oracle.com> References: <2065351848.3145321.1344601476979.JavaMail.root@redhat.com> <5024FEA9.4020401@oracle.com> <50257576.7050103@redhat.com> <50290ADE.6010308@oracle.com> <50290D95.60009@oracle.COM> <502911AE.40902@oracle.com> <50291797.7060007@redhat.com> <502A2730.8040001@oracle.com> Message-ID: <502A32D8.9040308@oracle.COM> > I see your point. As I told you we'll be open-sourcing a JAWT-specific > test under 7190587. This test already provides support for Linux, > Solaris, and Windows platforms, and even does a little more than just > loads the jawt library. > > So it looks there's still some value in Kumar's test as well. Yes, it > will need to be rewritten should we replace the RPATH mechanism with > something else in the future. It's up to Kumar to decide whether he > wants such test to be present in the repo. Personally, I don't mind. I think we need a test in the launcher area, as a first line of defense, so as to ensure we don't have a regression, when Program.gmk is modified, noting that test/tools/launcher is part of the testset core. As for Omair's jawt test I too don't see much value if we already have a duplicate elsewhere which will be moved to opensource. So I am ok with the Omair's changes - (jawt test) + (launchers test). :) Kumar > > -- > best regards, > Anthony > > On 8/13/2012 7:04 PM, Omair Majid wrote: >> On 08/13/2012 10:39 AM, Anthony Petrov wrote: >>> The test looks great, and I like that it doesn't depend on the JAWT >>> machinery, but tests the actual problematic RPATH entry only. >> >> I generally go for tests that verify behaviour (that jawt-linked >> programs are working) rather than implementation details (which changed, >> for example, when we switched from LD_LIBRARY_PATH to RPATHS). >> >>> +1 from me. >> >> Yes, good to have something that guards us from changing something >> unintentionally. Looks fine to me too. >> >> Cheers, >> Omair From kumar.x.srinivasan at oracle.COM Tue Aug 14 11:18:40 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Tue, 14 Aug 2012 04:18:40 -0700 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <1458136189.4421799.1344935865005.JavaMail.root@redhat.com> References: <1458136189.4421799.1344935865005.JavaMail.root@redhat.com> Message-ID: <502A3410.3090803@oracle.COM> > ----- Original Message ----- >> I have pointed out some changes below, but there is a serious >> problem. >> You are checking for the system arch using uname but the >> java architecture may not be the same. >> >> For example we run 32-bit jdk on a 64bit system, this will cause test >> failures >> since we will be using the wrong path names. >> >> You can use the following to determine the java arch. >> >> % java -XshowSettings:props -version 2>&1 | grep os.arch >> > This doesn't work (at least for me) unless the '-version' is removed. There was a bug which was fixed in 7u4/u6. > > I also note that this seems to only be present in 7 and later (i.e. not 6), not that this will matter in this case. Correct, 7 and above. Kumar > >> other diffs follow..... >> >> @@ -22,16 +22,17 @@ >> # questions. >> >> # @test runtest.sh >> -# @bug 9999999 >> +# @bug 7190813 >> # @summary Native code linked against libjawt.so should be >> sufficent >> for libjawt.so to be found >> # @run shell runtest.sh >> >> -if [ "${TESTSRC}" = "" ] >> -then TESTSRC=. >> +set -x >> + >> +if [ "${TESTSRC}" = "" ]; then >> + TESTSRC=. >> fi >> >> -if [ "${TESTJAVA}" = "" ] >> -then >> +if [ "${TESTJAVA}" = "" ]; then >> PARENT=`dirname \`which java\`` >> TESTJAVA=`dirname ${PARENT}` >> echo "TESTJAVA not set, selecting " ${TESTJAVA} >> @@ -46,14 +47,10 @@ >> PS=":" >> FS="/" >> ;; >> - SunOS | Windows_* ) >> - echo "Test passed; only valid for Linux" >> + * ) >> + echo "Warning: test passes vacuously for non linux systems" >> exit 0; >> ;; >> - * ) >> - echo "Unrecognized system!" >> - exit 1; >> - ;; >> esac >> >> # Get ARCH specifics >> @@ -71,13 +68,13 @@ >> >> gcc -v> /dev/null 2>&1 >> if [ "$?" != 0 ] ; then >> - echo "No compiler found" >> - exit 1 >> + echo "Warning: No gcc compiler found, test passes vacuously" >> + exit 0 >> fi >> >> -JAVAC=${TEST_JAVA}${FS}bin${FS}javac >> -JAVAH=${TEST_JAVA}${FS}bin${FS}javah >> -JAVA=${TEST_JAVA}${FS}bin${FS}java >> +JAVAC=${TESTJAVA}${FS}bin${FS}javac >> +JAVAH=${TESTJAVA}${FS}bin${FS}javah >> +JAVA=${TESTJAVA}${FS}bin${FS}java >> >> $JAVAC -d . ${TESTSRC}${FS}TestJawt.java || exit 1 >> $JAVAH TestJawt || exit 1 >> >> >> Thanks >> Kumar >> >>> On 08/13/2012 10:39 AM, Anthony Petrov wrote: >>>> The test looks great, and I like that it doesn't depend on the >>>> JAWT >>>> machinery, but tests the actual problematic RPATH entry only. >>> I generally go for tests that verify behaviour (that jawt-linked >>> programs are working) rather than implementation details (which >>> changed, >>> for example, when we switched from LD_LIBRARY_PATH to RPATHS). >>> >>>> +1 from me. >>> Yes, good to have something that guards us from changing something >>> unintentionally. Looks fine to me too. >>> >>> Cheers, >>> Omair >> From ahughes at redhat.com Tue Aug 14 11:55:44 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Tue, 14 Aug 2012 07:55:44 -0400 (EDT) Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <502A3410.3090803@oracle.COM> Message-ID: <36723830.4569757.1344945344796.JavaMail.root@redhat.com> ----- Original Message ----- > > > ----- Original Message ----- > >> I have pointed out some changes below, but there is a serious > >> problem. > >> You are checking for the system arch using uname but the > >> java architecture may not be the same. > >> > >> For example we run 32-bit jdk on a 64bit system, this will cause > >> test > >> failures > >> since we will be using the wrong path names. > >> > >> You can use the following to determine the java arch. > >> > >> % java -XshowSettings:props -version 2>&1 | grep os.arch > >> > > This doesn't work (at least for me) unless the '-version' is > > removed. > There was a bug which was fixed in 7u4/u6. > This is IcedTea 2.2.1 which is based on OpenJDK 7u4, so the fix must be in 7u6. Indeed, it does work with a build of tl. I see no reason to use -version, given all it does is reduce the output slightly, and it may fail on the VMs currently in most use. > > > > I also note that this seems to only be present in 7 and later (i.e. > > not 6), not that this will matter in this case. > Correct, 7 and above. > > Kumar > > > > >> other diffs follow..... > >> > >> @@ -22,16 +22,17 @@ > >> # questions. > >> > >> # @test runtest.sh > >> -# @bug 9999999 > >> +# @bug 7190813 > >> # @summary Native code linked against libjawt.so should be > >> sufficent > >> for libjawt.so to be found > >> # @run shell runtest.sh > >> > >> -if [ "${TESTSRC}" = "" ] > >> -then TESTSRC=. > >> +set -x > >> + > >> +if [ "${TESTSRC}" = "" ]; then > >> + TESTSRC=. > >> fi > >> > >> -if [ "${TESTJAVA}" = "" ] > >> -then > >> +if [ "${TESTJAVA}" = "" ]; then > >> PARENT=`dirname \`which java\`` > >> TESTJAVA=`dirname ${PARENT}` > >> echo "TESTJAVA not set, selecting " ${TESTJAVA} > >> @@ -46,14 +47,10 @@ > >> PS=":" > >> FS="/" > >> ;; > >> - SunOS | Windows_* ) > >> - echo "Test passed; only valid for Linux" > >> + * ) > >> + echo "Warning: test passes vacuously for non linux systems" > >> exit 0; > >> ;; > >> - * ) > >> - echo "Unrecognized system!" > >> - exit 1; > >> - ;; > >> esac > >> > >> # Get ARCH specifics > >> @@ -71,13 +68,13 @@ > >> > >> gcc -v> /dev/null 2>&1 > >> if [ "$?" != 0 ] ; then > >> - echo "No compiler found" > >> - exit 1 > >> + echo "Warning: No gcc compiler found, test passes vacuously" > >> + exit 0 > >> fi > >> > >> -JAVAC=${TEST_JAVA}${FS}bin${FS}javac > >> -JAVAH=${TEST_JAVA}${FS}bin${FS}javah > >> -JAVA=${TEST_JAVA}${FS}bin${FS}java > >> +JAVAC=${TESTJAVA}${FS}bin${FS}javac > >> +JAVAH=${TESTJAVA}${FS}bin${FS}javah > >> +JAVA=${TESTJAVA}${FS}bin${FS}java > >> > >> $JAVAC -d . ${TESTSRC}${FS}TestJawt.java || exit 1 > >> $JAVAH TestJawt || exit 1 > >> > >> > >> Thanks > >> Kumar > >> > >>> On 08/13/2012 10:39 AM, Anthony Petrov wrote: > >>>> The test looks great, and I like that it doesn't depend on the > >>>> JAWT > >>>> machinery, but tests the actual problematic RPATH entry only. > >>> I generally go for tests that verify behaviour (that jawt-linked > >>> programs are working) rather than implementation details (which > >>> changed, > >>> for example, when we switched from LD_LIBRARY_PATH to RPATHS). > >>> > >>>> +1 from me. > >>> Yes, good to have something that guards us from changing > >>> something > >>> unintentionally. Looks fine to me too. > >>> > >>> Cheers, > >>> Omair > >> > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From magnus.ihse.bursie at oracle.com Tue Aug 14 14:36:02 2012 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 14 Aug 2012 16:36:02 +0200 Subject: jdk8 makefile changes In-Reply-To: <4FFC3AE8.4010609@oracle.COM> References: <6E1102AE-5167-4FA8-888F-264EDA515E4C@oracle.com> <6D686E00-4ABF-4D27-B9CA-A86004DA655A@oracle.com> <4FFB6E8D.1010409@oracle.COM> <4FFB7539.5070309@oracle.com> <4FFB7E64.5010507@oracle.COM> <4FFB7FA8.9040109@oracle.com> <4FFC3AE8.4010609@oracle.COM> Message-ID: <502A6252.5040009@oracle.com> On 2012-07-10 16:23, Kumar Srinivasan wrote: > It looks like autoconf has messed up. > > > From the config.log > > HOSTCC='C:/PROGRA~1/MSVS10/VC/BIN/cl.exe' > HOSTCXX='C:/PROGRA~1/MSVS10/VC/BIN/cl.exe' > HOSTLD='C:/devtools/cygwin/bin/link.exe' > > It has picked cl.exe correctly, oopsie on link.exe. You have not only installed VS10 in a non-standard location, you have also installed Cygwin in a non-standard location. :-) (Default is C:\Cygwin). This is what fooled the configure scripts, which tries to distinguish between the link.exe from cygwin and link.exe from VS. I have just pushed a change in the build-infra repo that are intended to solve this. I'm not quite sure how it works out in your environment. I'd appreciate if you could take the time to try it out! /Magnus From martijnverburg at gmail.com Tue Aug 14 17:12:41 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 14 Aug 2012 18:12:41 +0100 Subject: webrev failure? In-Reply-To: <50282AE9.7070902@oracle.com> References: <50282AE9.7070902@oracle.com> Message-ID: Hi Chris, > Martin, > > Unless you have changes that span multiple repositories, then it can be > quite straight forward to run webrev ( without '-f ) on just the individual > repository that you are changing. It will run with simply 'hg out'. That did seem to work, thanks. > If you have changes in multiple repo's then you have other choices: > 1) run webrev on each individually, and include all the links in the > review mail > 2) create a 'file.list' ( a file containing your changed files, one > file name per line ), and pass it as the final arg to webrev > 3) Run with a really really old hg ( I use 0.9.5 ) and an installed > forest extension. Now, 'webrev -f' should work just fine ;-) We could go with 1) or 2) - I'll work that into our process. Cheers, Martijn > On 11/08/12 17:04, Martijn Verburg wrote: >> >> Hi all, >> >> Apologies if these are the wrong mailing lists, but I'm assuming that >> the webrev tool falls under this domain somewhat. >> >> In order to get patches into the OpenJDK as cleanly as possible, we're >> looking to utilise webrev (since it's the std and all). >> >> Running "ksh ./make/scripts/webrev.ksh -f" over the latest jdk8/tl >> source (no patches, but a full build was completed using build-infra) >> and I got a host of errors: >> >> -------- >> >> SCM detected: mercurial >> hg: unknown command 'foutgoing' >> abort: cannot follow file not in parent revision: "Mercurial" >> abort: cannot follow file not in parent revision: "basic" >> abort: cannot follow file not in parent revision: "add" >> abort: cannot follow file not in parent revision: "annotate" >> .. >> .. >> >> -------- >> >> A separate, yet related set of errors are at >> http://pastebin.com/q0tF1A4m for sake of brevity in this mail. >> >> I assume I'm running this tool incorrectly, I expected a result of >> something like "You've changed nothing, nothing to se here move along >> please" :-) >> >> Cheers, >> Martijn >> > From martijnverburg at gmail.com Tue Aug 14 17:20:07 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 14 Aug 2012 18:20:07 +0100 Subject: webrev failure? In-Reply-To: <20120813160521.GE2509@toonder.wildebeest.org> References: <5027939A.8060209@oracle.com> <20120813160521.GE2509@toonder.wildebeest.org> Message-ID: Hi Mark, > On Sun, Aug 12, 2012 at 12:39:57PM +0100, Martijn Verburg wrote: >> Aha! :-). Any ideas on how far I need to downgrade the version of hg? >> (I'm 2.3 at the moment). > > I am at 2.2.3. The hgforest extension as maintained at > http://icedtea.classpath.org/hg/hgforest > (which is a merge of various hgforest forks) > works with that. It is also the version that is installed on > the icedtea server itself to host forests. > > If there are patches needed for 2.3 we can incorporate those too. I gave the version hosted at http://icedtea.classpath.org/hg/hgforest a go and got the same error when using: ksh ./make/scripts/webrev.ksh -f but ksh ./make/scripts/webrev.ksh -N came up with a sensible answer for the multiple repo case. So perhaps some patching is required, but that's were my knowledge sadly ends :-(. Thanks everyone for your help with this! Cheers, Martijn From omajid at redhat.com Tue Aug 14 17:34:16 2012 From: omajid at redhat.com (Omair Majid) Date: Tue, 14 Aug 2012 13:34:16 -0400 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <502A32D8.9040308@oracle.COM> References: <2065351848.3145321.1344601476979.JavaMail.root@redhat.com> <5024FEA9.4020401@oracle.com> <50257576.7050103@redhat.com> <50290ADE.6010308@oracle.com> <50290D95.60009@oracle.COM> <502911AE.40902@oracle.com> <50291797.7060007@redhat.com> <502A2730.8040001@oracle.com> <502A32D8.9040308@oracle.COM> Message-ID: <502A8C18.6040204@redhat.com> On 08/14/2012 07:13 AM, Kumar Srinivasan wrote: > >> I see your point. As I told you we'll be open-sourcing a JAWT-specific >> test under 7190587. This test already provides support for Linux, >> Solaris, and Windows platforms, and even does a little more than just >> loads the jawt library. Awesome. A test like that will be great to have! I have no issues with leaving my jawt test out if we are going to add better tests soon. >> So it looks there's still some value in Kumar's test as well. Yes, it >> will need to be rewritten should we replace the RPATH mechanism with >> something else in the future. It's up to Kumar to decide whether he >> wants such test to be present in the repo. Personally, I don't mind. > > I think we need a test in the launcher area, as a first line of defense, > so as to ensure > we don't have a regression, when Program.gmk is modified, noting that > test/tools/launcher is part of the testset core. > > As for Omair's jawt test I too don't see much value if we already have a > duplicate elsewhere > which will be moved to opensource. As long as this corner case is accounted for, I agree. > > So I am ok with the Omair's changes - (jawt test) + (launchers test). :) Updated webrev: http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/02/ Shall I go ahead and commit? Thanks, Omair From naoto.sato at oracle.com Tue Aug 14 18:09:33 2012 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 14 Aug 2012 11:09:33 -0700 Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data In-Reply-To: <5029F6D1.1020602@oracle.com> References: <4FFC93CF.40105@oracle.com> <5020E699.3000600@oracle.com> <5022D686.9070203@oracle.com> <50297505.7050603@oracle.com> <5029F6D1.1020602@oracle.com> Message-ID: <502A945D.6030903@oracle.com> Hi David, We are planning to push the changes through T/L repos. Although I think it's unlikely that our changes and JSR 292 ones would interfere, it would be good to push them in a later promotion build. I will shoot for the next one after the "flag day." Naoto On 8/13/12 11:57 PM, David Holmes wrote: > Ni Naoto, > > Where will this be pushed to initially? > > It is a big set of changes, albeit localized (no pun intended :) ), so > it would be good to see this get some bake time before propagating up. > Further we're just about to have a "flag day" between hotspot and JDK > due to JSR292 changes, so it would be good to also add some space > between those changes and these ones - if that is feasible. > > This isn't my call, I'm just airing concerns :) > > Thanks, > David > > On 14/08/2012 7:43 AM, Naoto Sato wrote: >> Since I haven't heard any more comments from Erik/Kelly, I would like to >> push the changeset without the new build infra patch. Erik/Kelly, can >> you please give us an official "GO" in terms of the build related >> changes? >> >> Aside from build changes, I have updated the changeset based on an >> internal review: >> >> http://cr.openjdk.java.net/~naoto/6336885/webrev.01/ >> >> This includes: >> >> - a couple of fixes to the CLDR Converter >> - Added fallback for any bad SPI implementations which return null for >> requested instances. >> >> Still asking for review comments. >> >> Naoto >> >> On 8/8/12 2:13 PM, Naoto Sato wrote: >>> On 8/7/12 2:57 AM, Erik Joelsson wrote: >>>> See inline >>>> >>>> On 2012-07-13 22:20, Kelly O'Hair wrote: >>>>> Something seems strange here: >>>>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/make/java/java/localegen.sh.sdiff.html >>>>> >>>>> >>>>> >>>>> >>>>> It's like someone was avoiding overall quotes, but using them to add >>>>> spaces somehow... >>>>> I sure would like to get rid of this shell logic, seems like there are >>>>> lots repeated logic that >>>>> this script does over and over or could be done with makefile pattern >>>>> subst's instead of exec's. >>>> The new version isn't any worse than the old in my opinion. In >>>> build-infra, this file is indeed replaced with make logic. After having >>>> decoded both versions I'm confident in converting the changes. >>>>> Overall, just looking at the makefiles, the build-infra team may need >>>>> some time to fully absorb this into the >>>>> new makefiles, some of it will be trivial, not sure all of it will be. >>>>> >>>> I have applied the patch to a clone of build-infra and done the minimal >>>> changes to keep build-infra building, which was rather trivial. The >>>> resulting build has large differences since I haven't converted all of >>>> it yet. There are a couple of things that will require some more work, >>>> but not more than a day or two. >>>>> Not sure how to proceed here, the build-infra team does need an action >>>>> item to deal with this, maybe >>>>> before it gets integrated because I suspect the new makefiles will >>>>> break with all the filename or >>>>> directory changes. But I hate to hold up your integration plans. >>>> I see these as possible options: >>>> >>>> 1. Let this go in, build-infra will break in jdk8 until we do our next >>>> push and it trickles through the repos. >>>> 2. The build-infra project provides a patch with the full conversion >>>> that can go in together with these changes. >>>> 3. The build-infra project provides a simple patch which just keeps the >>>> build-infra-build from failing that can go in with these changes. >>>> >>>> The conversion needs to happen regardless of option. The changes >>>> required are pretty isolated from remaining build-infra work. What do >>>> you think? >>> >>> Either way is fine with me. If build-infra team prefers 2 or 3, please >>> give me the patch, and I will go ahead and merge them to my changeset. >>> >>> Naoto >>> >>>> >>>> Other than that, I have no objections to the review. >>>> >>>> /Erik >>>> >>>>> I'd like to get some advice from Erik on this before saying anything >>>>> further. >>>>> >>>>> -kto >>>>> >>>>> On Jul 10, 2012, at 1:42 PM, Naoto Sato wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> Please review the JDK8 changes for JEP 127: Improve Locale Data >>>>>> Packaging and Adopt Unicode CLDR Data >>>>>> (http://openjdk.java.net/jeps/127). The webrev is located at: >>>>>> >>>>>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/ >>>>>> >>>>>> The main bug id for this enhancement is: >>>>>> >>>>>> 6336885: RFE: Locale Data Deployment Enhancements >>>>>> >>>>>> Along with this, the following bugs/enhancements are also implemented >>>>>> in this change: >>>>>> >>>>>> 4609153 Provide locale data for Indic locales >>>>>> 5104387 Support for gl_ES locale (galician language) >>>>>> 6337471 desktop/system locale preferences support >>>>>> 7056139 (cal) SPI support for locale-dependent Calendar parameters >>>>>> 7058206 Provide CalendarData SPI for week params and display field >>>>>> value names >>>>>> 7073852 Support multiple scripts for digits and decimal symbols per >>>>>> locale >>>>>> 7079560 [Fmt-Da] Context dependent month names support in >>>>>> SimpleDateFormat >>>>>> 7171324 getAvailableLocales() of locale sensitive services should >>>>>> return the actual availability of locales >>>>>> 7151414 (cal) Support calendar type identification >>>>>> 7168528 LocaleServiceProvider needs to be aware of Locale extensions >>>>>> 7171372 (cal) locale's default Calendar should be created if unknown >>>>>> calendar is specified >>>>>> >>>>>> Please note that packaging changes that relate to Jigsaw module >>>>>> system aren't included in this changeset. >>>>>> >>>>>> Naoto Sato and Masayoshi Okutsu >>> >> From kumar.x.srinivasan at oracle.COM Tue Aug 14 21:04:05 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Tue, 14 Aug 2012 14:04:05 -0700 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <502A8C18.6040204@redhat.com> References: <2065351848.3145321.1344601476979.JavaMail.root@redhat.com> <5024FEA9.4020401@oracle.com> <50257576.7050103@redhat.com> <50290ADE.6010308@oracle.com> <50290D95.60009@oracle.COM> <502911AE.40902@oracle.com> <50291797.7060007@redhat.com> <502A2730.8040001@oracle.com> <502A32D8.9040308@oracle.COM> <502A8C18.6040204@redhat.com> Message-ID: <502ABD45.9040201@oracle.COM> Hi Omair, Thumbs up!. please let me know when you actually push I will set the CR, so that the integrator does not get confused, and I don't get awt push notifications. And once again thanks for doing this... Kumar > On 08/14/2012 07:13 AM, Kumar Srinivasan wrote: >>> I see your point. As I told you we'll be open-sourcing a JAWT-specific >>> test under 7190587. This test already provides support for Linux, >>> Solaris, and Windows platforms, and even does a little more than just >>> loads the jawt library. > Awesome. A test like that will be great to have! I have no issues with > leaving my jawt test out if we are going to add better tests soon. > >>> So it looks there's still some value in Kumar's test as well. Yes, it >>> will need to be rewritten should we replace the RPATH mechanism with >>> something else in the future. It's up to Kumar to decide whether he >>> wants such test to be present in the repo. Personally, I don't mind. >> I think we need a test in the launcher area, as a first line of defense, >> so as to ensure >> we don't have a regression, when Program.gmk is modified, noting that >> test/tools/launcher is part of the testset core. >> >> As for Omair's jawt test I too don't see much value if we already have a >> duplicate elsewhere >> which will be moved to opensource. > As long as this corner case is accounted for, I agree. > >> So I am ok with the Omair's changes - (jawt test) + (launchers test). :) > Updated webrev: > http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/02/ > > Shall I go ahead and commit? > > Thanks, > Omair From naoto.sato at oracle.com Tue Aug 14 21:17:42 2012 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 14 Aug 2012 14:17:42 -0700 Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data In-Reply-To: <5029F2C5.6030109@oracle.com> References: <4FFC93CF.40105@oracle.com> <5020E699.3000600@oracle.com> <5022D686.9070203@oracle.com> <50297505.7050603@oracle.com> <5029F2C5.6030109@oracle.com> Message-ID: <502AC076.3050809@oracle.com> Thanks, Erik! I incorporated your build-infra changes into the main changeset, and created a new combined webrev as follows: http://cr.openjdk.java.net/~naoto/6336885/webrev.02/ Naoto On 8/13/12 11:40 PM, Erik Joelsson wrote: > I finished making the changes yesterday, but didn't manage to get the > patch completed before I had to run. (webrev and mercurial wouldn't > cooperate). I will get it done asap today. > > /Erik > > On 2012-08-13 23:43, Naoto Sato wrote: >> Since I haven't heard any more comments from Erik/Kelly, I would like >> to push the changeset without the new build infra patch. Erik/Kelly, >> can you please give us an official "GO" in terms of the build related >> changes? >> >> Aside from build changes, I have updated the changeset based on an >> internal review: >> >> http://cr.openjdk.java.net/~naoto/6336885/webrev.01/ >> >> This includes: >> >> - a couple of fixes to the CLDR Converter >> - Added fallback for any bad SPI implementations which return null for >> requested instances. >> >> Still asking for review comments. >> >> Naoto >> >> On 8/8/12 2:13 PM, Naoto Sato wrote: >>> On 8/7/12 2:57 AM, Erik Joelsson wrote: >>>> See inline >>>> >>>> On 2012-07-13 22:20, Kelly O'Hair wrote: >>>>> Something seems strange here: >>>>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/make/java/java/localegen.sh.sdiff.html >>>>> >>>>> >>>>> >>>>> It's like someone was avoiding overall quotes, but using them to add >>>>> spaces somehow... >>>>> I sure would like to get rid of this shell logic, seems like there are >>>>> lots repeated logic that >>>>> this script does over and over or could be done with makefile pattern >>>>> subst's instead of exec's. >>>> The new version isn't any worse than the old in my opinion. In >>>> build-infra, this file is indeed replaced with make logic. After having >>>> decoded both versions I'm confident in converting the changes. >>>>> Overall, just looking at the makefiles, the build-infra team may need >>>>> some time to fully absorb this into the >>>>> new makefiles, some of it will be trivial, not sure all of it will be. >>>>> >>>> I have applied the patch to a clone of build-infra and done the minimal >>>> changes to keep build-infra building, which was rather trivial. The >>>> resulting build has large differences since I haven't converted all of >>>> it yet. There are a couple of things that will require some more work, >>>> but not more than a day or two. >>>>> Not sure how to proceed here, the build-infra team does need an action >>>>> item to deal with this, maybe >>>>> before it gets integrated because I suspect the new makefiles will >>>>> break with all the filename or >>>>> directory changes. But I hate to hold up your integration plans. >>>> I see these as possible options: >>>> >>>> 1. Let this go in, build-infra will break in jdk8 until we do our next >>>> push and it trickles through the repos. >>>> 2. The build-infra project provides a patch with the full conversion >>>> that can go in together with these changes. >>>> 3. The build-infra project provides a simple patch which just keeps the >>>> build-infra-build from failing that can go in with these changes. >>>> >>>> The conversion needs to happen regardless of option. The changes >>>> required are pretty isolated from remaining build-infra work. What do >>>> you think? >>> >>> Either way is fine with me. If build-infra team prefers 2 or 3, please >>> give me the patch, and I will go ahead and merge them to my changeset. >>> >>> Naoto >>> >>>> >>>> Other than that, I have no objections to the review. >>>> >>>> /Erik >>>> >>>>> I'd like to get some advice from Erik on this before saying anything >>>>> further. >>>>> >>>>> -kto >>>>> >>>>> On Jul 10, 2012, at 1:42 PM, Naoto Sato wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> Please review the JDK8 changes for JEP 127: Improve Locale Data >>>>>> Packaging and Adopt Unicode CLDR Data >>>>>> (http://openjdk.java.net/jeps/127). The webrev is located at: >>>>>> >>>>>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/ >>>>>> >>>>>> The main bug id for this enhancement is: >>>>>> >>>>>> 6336885: RFE: Locale Data Deployment Enhancements >>>>>> >>>>>> Along with this, the following bugs/enhancements are also implemented >>>>>> in this change: >>>>>> >>>>>> 4609153 Provide locale data for Indic locales >>>>>> 5104387 Support for gl_ES locale (galician language) >>>>>> 6337471 desktop/system locale preferences support >>>>>> 7056139 (cal) SPI support for locale-dependent Calendar parameters >>>>>> 7058206 Provide CalendarData SPI for week params and display field >>>>>> value names >>>>>> 7073852 Support multiple scripts for digits and decimal symbols per >>>>>> locale >>>>>> 7079560 [Fmt-Da] Context dependent month names support in >>>>>> SimpleDateFormat >>>>>> 7171324 getAvailableLocales() of locale sensitive services should >>>>>> return the actual availability of locales >>>>>> 7151414 (cal) Support calendar type identification >>>>>> 7168528 LocaleServiceProvider needs to be aware of Locale extensions >>>>>> 7171372 (cal) locale's default Calendar should be created if unknown >>>>>> calendar is specified >>>>>> >>>>>> Please note that packaging changes that relate to Jigsaw module >>>>>> system aren't included in this changeset. >>>>>> >>>>>> Naoto Sato and Masayoshi Okutsu >>> >> From omajid at redhat.com Tue Aug 14 21:22:33 2012 From: omajid at redhat.com (Omair Majid) Date: Tue, 14 Aug 2012 17:22:33 -0400 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <502ABD45.9040201@oracle.COM> References: <2065351848.3145321.1344601476979.JavaMail.root@redhat.com> <5024FEA9.4020401@oracle.com> <50257576.7050103@redhat.com> <50290ADE.6010308@oracle.com> <50290D95.60009@oracle.COM> <502911AE.40902@oracle.com> <50291797.7060007@redhat.com> <502A2730.8040001@oracle.com> <502A32D8.9040308@oracle.COM> <502A8C18.6040204@redhat.com> <502ABD45.9040201@oracle.COM> Message-ID: <502AC199.6000305@redhat.com> On 08/14/2012 05:04 PM, Kumar Srinivasan wrote: > Hi Omair, > > Thumbs up!. please let me know when you actually push I will set the CR, > so that > the integrator does not get confused, and I don't get awt push > notifications. Pushed: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f003387c33ad > And once again thanks for doing this... No problem. And thank you for all your suggestions and help too! Thank, Omair From Dmitry.Samersoff at oracle.com Wed Aug 15 08:38:43 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 15 Aug 2012 12:38:43 +0400 Subject: Any plan to cleanup x86 arch names? Message-ID: <502B6013.50101@oracle.com> Hi Everyone, Currently we uses i386, i486 and i586 within x86 build. Do we have a plan to cleanup it and replace to just "x86"? -Dmitry -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From magnus.ihse.bursie at oracle.com Wed Aug 15 11:52:15 2012 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 15 Aug 2012 13:52:15 +0200 Subject: Any plan to cleanup x86 arch names? In-Reply-To: <502B6013.50101@oracle.com> References: <502B6013.50101@oracle.com> Message-ID: <502B8D6F.5020707@oracle.com> On 2012-08-15 10:38, Dmitry Samersoff wrote: > Hi Everyone, > > Currently we uses i386, i486 and i586 within x86 build. Not only the 32-bit Intel architecture, but the 64-bit as well has naming confusions. Unfortunately, it is not that simple to just replace everything with x86. 1) Some things have external requirements for their name, and cannot be easily changed (or at all). For instance, Java programs expect a specific os.arch property. Library names must be named amd64 on Solaris (as far as I understand). Marketing is likely to have their own view on what to name the packages. Etc. 2) Changing names on files or directories (unfortunately) makes version control harder. If files are to be moved around all over the place anyway with Jigsaw, we might as well fix some names. It is not clear if it's worth the effort to rename files before such a major restructuring. 3) If we should change all instances that we can, we still have to agree on *what* to call it. Not everyone thinks that "x86" is the obvious choice. And even if this is the most common view (I think it is), what about the 64-bit platform? x86_64? x64? amd64? I've heard people defend all three names. I actually posted a proposal for naming cpu's in the new build infra some time ago (see http://mail.openjdk.java.net/pipermail/build-infra-dev/2012-June/001019.html). It boiled down to: 32-bit Intel: x86 64-bit Intel: x86_64 Intel arctitecture: x86 (As reference: 32-bit Sparc: sparc 64-bit Sparc: sparcv9 Sparc architecture: sparc) There was some follow-up discussion, mostly on how to identify what different kinds of names we need. /Magnus From Dmitry.Samersoff at oracle.com Wed Aug 15 12:15:40 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 15 Aug 2012 16:15:40 +0400 Subject: Any plan to cleanup x86 arch names? In-Reply-To: <502B8D6F.5020707@oracle.com> References: <502B6013.50101@oracle.com> <502B8D6F.5020707@oracle.com> Message-ID: <502B92EC.10303@oracle.com> Magnus, Thank you for the background. I understand that big architecture names cleanup contains lots of underwater stones. It's why I'm asking just for one piece of this mess - I would like to have {i386,i486,i586} changed to the single name. -Dmitry On 2012-08-15 15:52, Magnus Ihse Bursie wrote: > On 2012-08-15 10:38, Dmitry Samersoff wrote: >> Hi Everyone, >> >> Currently we uses i386, i486 and i586 within x86 build. > Not only the 32-bit Intel architecture, but the 64-bit as well has > naming confusions. > > Unfortunately, it is not that simple to just replace everything with x86. > > 1) Some things have external requirements for their name, and cannot be > easily changed (or at all). For instance, Java programs expect a > specific os.arch property. Library names must be named amd64 on Solaris > (as far as I understand). Marketing is likely to have their own view on > what to name the packages. Etc. > > 2) Changing names on files or directories (unfortunately) makes version > control harder. If files are to be moved around all over the place > anyway with Jigsaw, we might as well fix some names. It is not clear if > it's worth the effort to rename files before such a major restructuring. > > 3) If we should change all instances that we can, we still have to agree > on *what* to call it. Not everyone thinks that "x86" is the obvious > choice. And even if this is the most common view (I think it is), what > about the 64-bit platform? x86_64? x64? amd64? I've heard people defend > all three names. > > I actually posted a proposal for naming cpu's in the new build infra > some time ago (see > http://mail.openjdk.java.net/pipermail/build-infra-dev/2012-June/001019.html). > It boiled down to: > 32-bit Intel: x86 > 64-bit Intel: x86_64 > Intel arctitecture: x86 > > (As reference: > 32-bit Sparc: sparc > 64-bit Sparc: sparcv9 > Sparc architecture: sparc) > > There was some follow-up discussion, mostly on how to identify what > different kinds of names we need. > > /Magnus -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From magnus.ihse.bursie at oracle.com Wed Aug 15 13:22:39 2012 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 15 Aug 2012 15:22:39 +0200 Subject: Any plan to cleanup x86 arch names? In-Reply-To: <502B92EC.10303@oracle.com> References: <502B6013.50101@oracle.com> <502B8D6F.5020707@oracle.com> <502B92EC.10303@oracle.com> Message-ID: <502BA29F.6010708@oracle.com> On 2012-08-15 14:15, Dmitry Samersoff wrote: > Magnus, > > Thank you for the background. > > I understand that big architecture names cleanup contains lots of > underwater stones. > > It's why I'm asking just for one piece of this mess - I would like > to have {i386,i486,i586} changed to the single name. The problem is the same here, though. We can't e.g. go chaning the value of os.arch or the names of binaries and libraries. It does not really matter that you want to limit it to one platform. In fact, it would be easier if you ask "can we clean up the platform name mess of binaries?" rather than "can we clean up platform X?". /Magnus From kelly.ohair at oracle.com Wed Aug 15 14:48:46 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 15 Aug 2012 16:48:46 +0200 Subject: Any plan to cleanup x86 arch names? In-Reply-To: <502B6013.50101@oracle.com> References: <502B6013.50101@oracle.com> Message-ID: On Aug 15, 2012, at 10:38 AM, Dmitry Samersoff wrote: > Hi Everyone, > > Currently we uses i386, i486 and i586 within x86 build. Yeah, historic stuff. This is a more difficult problem than it seems, as Magnus says. > > Do we have a plan to cleanup it and replace to just "x86"? Where we can, in the build process we will try and be consistent, not sure we can fix the source file naming, or system or Java property conventions. -kto > > -Dmitry > > -- > Dmitry Samersoff > Java Hotspot development team, SPB04 > * There will come soft rains ... > From kelly.ohair at oracle.com Wed Aug 15 14:53:28 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 15 Aug 2012 16:53:28 +0200 Subject: Any plan to cleanup x86 arch names? In-Reply-To: <502B8D6F.5020707@oracle.com> References: <502B6013.50101@oracle.com> <502B8D6F.5020707@oracle.com> Message-ID: <913C3910-ED9C-4881-AA75-3891C3796956@oracle.com> amd64 was very company specific and as far as I knew, we were favoring x64, but I have no objection to x86_64. But in some places, like the jre/lib/ARCH name, we are kind of stuck with amd64, but now that I think about it, I'm not exactly sure why we would be stuck with any directory name like this. I think where we can be consistent and avoid adding new names for the same thing, we should. Just not sure this will be floating up as any high priority effort any time soon. -kto On Aug 15, 2012, at 1:52 PM, Magnus Ihse Bursie wrote: > On 2012-08-15 10:38, Dmitry Samersoff wrote: >> Hi Everyone, >> >> Currently we uses i386, i486 and i586 within x86 build. > Not only the 32-bit Intel architecture, but the 64-bit as well has naming confusions. > > Unfortunately, it is not that simple to just replace everything with x86. > > 1) Some things have external requirements for their name, and cannot be easily changed (or at all). For instance, Java programs expect a specific os.arch property. Library names must be named amd64 on Solaris (as far as I understand). Marketing is likely to have their own view on what to name the packages. Etc. > > 2) Changing names on files or directories (unfortunately) makes version control harder. If files are to be moved around all over the place anyway with Jigsaw, we might as well fix some names. It is not clear if it's worth the effort to rename files before such a major restructuring. > > 3) If we should change all instances that we can, we still have to agree on *what* to call it. Not everyone thinks that "x86" is the obvious choice. And even if this is the most common view (I think it is), what about the 64-bit platform? x86_64? x64? amd64? I've heard people defend all three names. > > I actually posted a proposal for naming cpu's in the new build infra some time ago (see http://mail.openjdk.java.net/pipermail/build-infra-dev/2012-June/001019.html). It boiled down to: > 32-bit Intel: x86 > 64-bit Intel: x86_64 > Intel arctitecture: x86 > > (As reference: > 32-bit Sparc: sparc > 64-bit Sparc: sparcv9 > Sparc architecture: sparc) > > There was some follow-up discussion, mostly on how to identify what different kinds of names we need. > > /Magnus From mark.reinhold at oracle.com Wed Aug 15 15:10:03 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 15 Aug 2012 08:10:03 -0700 Subject: Any plan to cleanup x86 arch names? In-Reply-To: magnus.ihse.bursie@oracle.com; Wed, 15 Aug 2012 13:52:15 +0200; <502B8D6F.5020707@oracle.com> Message-ID: <20120815151003.4255CE2B@eggemoggin.niobe.net> 2012/8/15 4:52 -0700, magnus.ihse.bursie at oracle.com: > Unfortunately, it is not that simple to just replace everything with x86. Sad, but true. > ... > > 2) Changing names on files or directories (unfortunately) makes version control > harder. If files are to be moved around all over the place anyway with Jigsaw, > we might as well fix some names. It is not clear if it's worth the effort to > rename files before such a major restructuring. Agreed. Not only will Jigsaw restructure the source tree, but it will change the layout of $JRE/lib and make other changes that will, no doubt, affect some existing code. If we're going to fix all our old arch names, that would be the right time to do it. - Mark From joel.franck at oracle.com Wed Aug 15 18:17:21 2012 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Wed, 15 Aug 2012 20:17:21 +0200 Subject: jdk builds on the mac In-Reply-To: <50249E97.4090409@oracle.com> References: <041963DD-5D06-4CDB-8E23-0FEC94DAAC1B@oracle.com> <501310E5.2070007@oracle.COM> <501F8F72.4060205@oracle.com> <50249E97.4090409@oracle.com> Message-ID: <4DF9482D-B0C6-48E5-84D5-C82C49C20E9E@oracle.com> I would't say I'm working on it. But from the department of "works for me (?)" here is a patch that sort of works for me. It might be breaking other stuff (like full forest builds), and it might not be what we want to do ... cheers /Joel -------------- next part -------------- On 10 aug 2012, at 07:39, Erik Joelsson wrote: > It does and I believe Joel, in the langtools team, is looking at this issue. > > /Erik > > On 2012-08-10 03:00, Kelly O'Hair wrote: >> I think we need to make sure that the only thing that gets built with the bootjdk javac is the langtools >> bootstrap javac.jar, all other javac compilations needs to be done by the bootstrap javac. >> Does that fix this issue? >> >> -kto >> >> On Aug 6, 2012, at 2:33 AM, Erik Joelsson wrote: >> >>> The classpath reference was added on my request for build-infra. The reason was to get javax.annotation.GenerateNativeHeader on the classpath. The javac used in that ant script is the bootjdk javac, which usually doesn't provide the annotation. I suppose the correct fix would be to change the ant script to use the bootstrap javac instead. >>> >>> /Erik >>> >>> On 2012-07-28 00:06, Kumar Srinivasan wrote: >>>> On 7/25/2012 2:23 PM, Kelly O'Hair wrote: >>>>> Naoto has noticed this build failure on the Mac (just the Mac) when building just the jdk repository. >>>>> >>>>> From what I can tell, the Mac build of the jdk repository now depends on the langtools repository also >>>>> being built, which means that partial builds of just the jdk repository will no longer work on the Mac? >>>>> There is an ant script at jdk/src/macosx/native/jobjc/build.xml that has a baked in classpath reference to >>>>> ../../langtools/dist/lib/classes.jar >>>>> >>>>> Has anyone seen this, or have any additional information on it? >>>> This is preventing me to test certain things I can only run from a jdk build under >>>> jprt on the macosx machine. >>>> >>>> Kumar >>>> >>>>> -kto >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> build-core: >>>>> [mkdir] Created dir: /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core >>>>> [javac] com/apple/jobjc/PrimitiveCoder.java added as com/apple/jobjc/PrimitiveCoder.class doesn't exist. >>>>> [javac] Compiling 1 source file to /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core >>>>> [javac] Using modern compiler >>>>> dropping /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/langtools/dist/lib/classes.jar from path as it doesn't exist >>>>> [javac] Compilation arguments: >>>>> [javac] '-d' >>>>> [javac] '/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core' >>>>> [javac] '-classpath' >>>>> [javac] '/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core' >>>>> [javac] '-sourcepath' >>>>> [javac] '/private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java' >>>>> [javac] '-target' >>>>> [javac] '1.5' >>>>> [javac] '-g' >>>>> [javac] '-source' >>>>> [javac] '1.5' >>>>> [javac] >>>>> [javac] The ' characters around the executable and arguments are >>>>> [javac] not part of the command. >>>>> [javac] File to be compiled: >>>>> [javac] /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/PrimitiveCoder.java >>>>> [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.5 >>>>> [javac] /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java:32: warning: Unsafe is internal proprietary API and may be removed in a future release >>>>> [javac] import sun.misc.Unsafe; >>>>> [javac] ^ >>>>> >>>>> ..... >>>>> >>>>> [javac] @GenerateNativeHeader >>>>> [javac] ^ >>>>> [javac] symbol: class GenerateNativeHeader >>>>> [javac] Note: Some input files use unchecked or unsafe operations. >>>>> [javac] Note: Recompile with -Xlint:unchecked for details. >>>>> [javac] 61 errors >>>>> [javac] 7 warnings >>>>> >>>>> BUILD FAILED >>>>> /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/build.xml:143: Compile failed; see the compiler error output for details. >>>>> at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:1079) >>>>> at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:882) >>>>> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) >>>>> at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) >>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>> at java.lang.reflect.Method.invoke(Method.java:601) >>>>> at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) >>>>> at org.apache.tools.ant.Task.perform(Task.java:348) >>>>> at org.apache.tools.ant.Target.execute(Target.java:357) >>>>> at org.apache.tools.ant.Target.performTasks(Target.java:385) >>>>> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) >>>>> at org.apache.tools.ant.Project.executeTarget(Project.java:1306) >>>>> at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) >>>>> at org.apache.tools.ant.Project.executeTargets(Project.java:1189) >>>>> at org.apache.tools.ant.Main.runBuild(Main.java:758) >>>>> at org.apache.tools.ant.Main.startAnt(Main.java:217) >>>>> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) >>>>> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) >>>>> >>>>> Total time: 1 second >>>>> make[2]: *** [../../../build/macosx-x86_64/JObjC.build/JObjC.jar] Error 1 >>>>> make[1]: *** [all] Error 1 >>>>> make: *** [all] Error 1 > From joel.franck at oracle.com Wed Aug 15 18:30:07 2012 From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=) Date: Wed, 15 Aug 2012 20:30:07 +0200 Subject: jdk builds on the mac In-Reply-To: <4DF9482D-B0C6-48E5-84D5-C82C49C20E9E@oracle.com> References: <041963DD-5D06-4CDB-8E23-0FEC94DAAC1B@oracle.com> <501310E5.2070007@oracle.COM> <501F8F72.4060205@oracle.com> <50249E97.4090409@oracle.com> <4DF9482D-B0C6-48E5-84D5-C82C49C20E9E@oracle.com> Message-ID: <23301E44-B548-4551-98B0-29298A68903C@oracle.com> Well that didn't work, patch inline: diff -r 38263aa28324 src/macosx/native/jobjc/build.xml --- a/src/macosx/native/jobjc/build.xml Mon Jul 30 22:32:59 2012 +0100 +++ b/src/macosx/native/jobjc/build.xml Wed Aug 15 20:09:08 2012 +0200 @@ -73,6 +73,10 @@ + + + + @@ -115,7 +119,7 @@ - + @@ -140,15 +144,11 @@ - - - + includeantruntime="false" + classpath="${classes}"> - - - - + On 15 aug 2012, at 20:17, Joel Borggr?n-Franck wrote: > I would't say I'm working on it. > > But from the department of "works for me (?)" here is a patch that sort of works for me. It might be breaking other stuff (like full forest builds), and it might not be what we want to do ... > > cheers > /Joel > > > > On 10 aug 2012, at 07:39, Erik Joelsson wrote: > >> It does and I believe Joel, in the langtools team, is looking at this issue. >> >> /Erik >> >> On 2012-08-10 03:00, Kelly O'Hair wrote: >>> I think we need to make sure that the only thing that gets built with the bootjdk javac is the langtools >>> bootstrap javac.jar, all other javac compilations needs to be done by the bootstrap javac. >>> Does that fix this issue? >>> >>> -kto >>> >>> On Aug 6, 2012, at 2:33 AM, Erik Joelsson wrote: >>> >>>> The classpath reference was added on my request for build-infra. The reason was to get javax.annotation.GenerateNativeHeader on the classpath. The javac used in that ant script is the bootjdk javac, which usually doesn't provide the annotation. I suppose the correct fix would be to change the ant script to use the bootstrap javac instead. >>>> >>>> /Erik >>>> >>>> On 2012-07-28 00:06, Kumar Srinivasan wrote: >>>>> On 7/25/2012 2:23 PM, Kelly O'Hair wrote: >>>>>> Naoto has noticed this build failure on the Mac (just the Mac) when building just the jdk repository. >>>>>> >>>>>> From what I can tell, the Mac build of the jdk repository now depends on the langtools repository also >>>>>> being built, which means that partial builds of just the jdk repository will no longer work on the Mac? >>>>>> There is an ant script at jdk/src/macosx/native/jobjc/build.xml that has a baked in classpath reference to >>>>>> ../../langtools/dist/lib/classes.jar >>>>>> >>>>>> Has anyone seen this, or have any additional information on it? >>>>> This is preventing me to test certain things I can only run from a jdk build under >>>>> jprt on the macosx machine. >>>>> >>>>> Kumar >>>>> >>>>>> -kto >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> build-core: >>>>>> [mkdir] Created dir: /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core >>>>>> [javac] com/apple/jobjc/PrimitiveCoder.java added as com/apple/jobjc/PrimitiveCoder.class doesn't exist. >>>>>> [javac] Compiling 1 source file to /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core >>>>>> [javac] Using modern compiler >>>>>> dropping /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/langtools/dist/lib/classes.jar from path as it doesn't exist >>>>>> [javac] Compilation arguments: >>>>>> [javac] '-d' >>>>>> [javac] '/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core' >>>>>> [javac] '-classpath' >>>>>> [javac] '/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core' >>>>>> [javac] '-sourcepath' >>>>>> [javac] '/private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java' >>>>>> [javac] '-target' >>>>>> [javac] '1.5' >>>>>> [javac] '-g' >>>>>> [javac] '-source' >>>>>> [javac] '1.5' >>>>>> [javac] >>>>>> [javac] The ' characters around the executable and arguments are >>>>>> [javac] not part of the command. >>>>>> [javac] File to be compiled: >>>>>> [javac] /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/PrimitiveCoder.java >>>>>> [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.5 >>>>>> [javac] /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java:32: warning: Unsafe is internal proprietary API and may be removed in a future release >>>>>> [javac] import sun.misc.Unsafe; >>>>>> [javac] ^ >>>>>> >>>>>> ..... >>>>>> >>>>>> [javac] @GenerateNativeHeader >>>>>> [javac] ^ >>>>>> [javac] symbol: class GenerateNativeHeader >>>>>> [javac] Note: Some input files use unchecked or unsafe operations. >>>>>> [javac] Note: Recompile with -Xlint:unchecked for details. >>>>>> [javac] 61 errors >>>>>> [javac] 7 warnings >>>>>> >>>>>> BUILD FAILED >>>>>> /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/build.xml:143: Compile failed; see the compiler error output for details. >>>>>> at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:1079) >>>>>> at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:882) >>>>>> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) >>>>>> at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) >>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>>> at java.lang.reflect.Method.invoke(Method.java:601) >>>>>> at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) >>>>>> at org.apache.tools.ant.Task.perform(Task.java:348) >>>>>> at org.apache.tools.ant.Target.execute(Target.java:357) >>>>>> at org.apache.tools.ant.Target.performTasks(Target.java:385) >>>>>> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) >>>>>> at org.apache.tools.ant.Project.executeTarget(Project.java:1306) >>>>>> at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) >>>>>> at org.apache.tools.ant.Project.executeTargets(Project.java:1189) >>>>>> at org.apache.tools.ant.Main.runBuild(Main.java:758) >>>>>> at org.apache.tools.ant.Main.startAnt(Main.java:217) >>>>>> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) >>>>>> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) >>>>>> >>>>>> Total time: 1 second >>>>>> make[2]: *** [../../../build/macosx-x86_64/JObjC.build/JObjC.jar] Error 1 >>>>>> make[1]: *** [all] Error 1 >>>>>> make: *** [all] Error 1 >> > From kumar.x.srinivasan at oracle.COM Wed Aug 15 18:42:11 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Wed, 15 Aug 2012 11:42:11 -0700 Subject: jdk builds on the mac In-Reply-To: <4DF9482D-B0C6-48E5-84D5-C82C49C20E9E@oracle.com> References: <041963DD-5D06-4CDB-8E23-0FEC94DAAC1B@oracle.com> <501310E5.2070007@oracle.COM> <501F8F72.4060205@oracle.com> <50249E97.4090409@oracle.com> <4DF9482D-B0C6-48E5-84D5-C82C49C20E9E@oracle.com> Message-ID: <502BED83.7080203@oracle.COM> Ive filed a bug: 7191703 for this. Kumar > I would't say I'm working on it. > > But from the department of "works for me (^(TM))" here is a patch that sort of works for me. It might be breaking other stuff (like full forest builds), and it might not be what we want to do ... > > cheers > /Joel > > > > > On 10 aug 2012, at 07:39, Erik Joelsson wrote: > >> It does and I believe Joel, in the langtools team, is looking at this issue. >> >> /Erik >> >> On 2012-08-10 03:00, Kelly O'Hair wrote: >>> I think we need to make sure that the only thing that gets built with the bootjdk javac is the langtools >>> bootstrap javac.jar, all other javac compilations needs to be done by the bootstrap javac. >>> Does that fix this issue? >>> >>> -kto >>> >>> On Aug 6, 2012, at 2:33 AM, Erik Joelsson wrote: >>> >>>> The classpath reference was added on my request for build-infra. The reason was to get javax.annotation.GenerateNativeHeader on the classpath. The javac used in that ant script is the bootjdk javac, which usually doesn't provide the annotation. I suppose the correct fix would be to change the ant script to use the bootstrap javac instead. >>>> >>>> /Erik >>>> >>>> On 2012-07-28 00:06, Kumar Srinivasan wrote: >>>>> On 7/25/2012 2:23 PM, Kelly O'Hair wrote: >>>>>> Naoto has noticed this build failure on the Mac (just the Mac) when building just the jdk repository. >>>>>> >>>>>> From what I can tell, the Mac build of the jdk repository now depends on the langtools repository also >>>>>> being built, which means that partial builds of just the jdk repository will no longer work on the Mac? >>>>>> There is an ant script at jdk/src/macosx/native/jobjc/build.xml that has a baked in classpath reference to >>>>>> ../../langtools/dist/lib/classes.jar >>>>>> >>>>>> Has anyone seen this, or have any additional information on it? >>>>> This is preventing me to test certain things I can only run from a jdk build under >>>>> jprt on the macosx machine. >>>>> >>>>> Kumar >>>>> >>>>>> -kto >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> build-core: >>>>>> [mkdir] Created dir: /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core >>>>>> [javac] com/apple/jobjc/PrimitiveCoder.java added as com/apple/jobjc/PrimitiveCoder.class doesn't exist. >>>>>> [javac] Compiling 1 source file to /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core >>>>>> [javac] Using modern compiler >>>>>> dropping /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/langtools/dist/lib/classes.jar from path as it doesn't exist >>>>>> [javac] Compilation arguments: >>>>>> [javac] '-d' >>>>>> [javac] '/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core' >>>>>> [javac] '-classpath' >>>>>> [javac] '/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core' >>>>>> [javac] '-sourcepath' >>>>>> [javac] '/private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java' >>>>>> [javac] '-target' >>>>>> [javac] '1.5' >>>>>> [javac] '-g' >>>>>> [javac] '-source' >>>>>> [javac] '1.5' >>>>>> [javac] >>>>>> [javac] The ' characters around the executable and arguments are >>>>>> [javac] not part of the command. >>>>>> [javac] File to be compiled: >>>>>> [javac] /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/PrimitiveCoder.java >>>>>> [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.5 >>>>>> [javac] /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java:32: warning: Unsafe is internal proprietary API and may be removed in a future release >>>>>> [javac] import sun.misc.Unsafe; >>>>>> [javac] ^ >>>>>> >>>>>> ..... >>>>>> >>>>>> [javac] @GenerateNativeHeader >>>>>> [javac] ^ >>>>>> [javac] symbol: class GenerateNativeHeader >>>>>> [javac] Note: Some input files use unchecked or unsafe operations. >>>>>> [javac] Note: Recompile with -Xlint:unchecked for details. >>>>>> [javac] 61 errors >>>>>> [javac] 7 warnings >>>>>> >>>>>> BUILD FAILED >>>>>> /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/build.xml:143: Compile failed; see the compiler error output for details. >>>>>> at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:1079) >>>>>> at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:882) >>>>>> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) >>>>>> at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) >>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>>> at java.lang.reflect.Method.invoke(Method.java:601) >>>>>> at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) >>>>>> at org.apache.tools.ant.Task.perform(Task.java:348) >>>>>> at org.apache.tools.ant.Target.execute(Target.java:357) >>>>>> at org.apache.tools.ant.Target.performTasks(Target.java:385) >>>>>> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) >>>>>> at org.apache.tools.ant.Project.executeTarget(Project.java:1306) >>>>>> at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) >>>>>> at org.apache.tools.ant.Project.executeTargets(Project.java:1189) >>>>>> at org.apache.tools.ant.Main.runBuild(Main.java:758) >>>>>> at org.apache.tools.ant.Main.startAnt(Main.java:217) >>>>>> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) >>>>>> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) >>>>>> >>>>>> Total time: 1 second >>>>>> make[2]: *** [../../../build/macosx-x86_64/JObjC.build/JObjC.jar] Error 1 >>>>>> make[1]: *** [all] Error 1 >>>>>> make: *** [all] Error 1 From jonathan.gibbons at oracle.com Wed Aug 15 19:10:52 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 15 Aug 2012 12:10:52 -0700 Subject: jdk builds on the mac In-Reply-To: <23301E44-B548-4551-98B0-29298A68903C@oracle.com> References: <041963DD-5D06-4CDB-8E23-0FEC94DAAC1B@oracle.com> <501310E5.2070007@oracle.COM> <501F8F72.4060205@oracle.com> <50249E97.4090409@oracle.com> <4DF9482D-B0C6-48E5-84D5-C82C49C20E9E@oracle.com> <23301E44-B548-4551-98B0-29298A68903C@oracle.com> Message-ID: <502BF43C.2040204@oracle.com> I would expect the necessary classes to be in build/$PLATFORM-$ARCH/classes, so you might want to try using that path instead of the proposed condition. -- Jon On 08/15/2012 11:30 AM, Joel Borggr?n-Franck wrote: > Well that didn't work, patch inline: > > diff -r 38263aa28324 src/macosx/native/jobjc/build.xml > --- a/src/macosx/native/jobjc/build.xml Mon Jul 30 22:32:59 2012 +0100 > +++ b/src/macosx/native/jobjc/build.xml Wed Aug 15 20:09:08 2012 +0200 > @@ -73,6 +73,10 @@ > > > > + > + > + > + > > > > @@ -115,7 +119,7 @@ > > > > - > + > > > > @@ -140,15 +144,11 @@ > > includes="**/PrimitiveCoder.java" > - includeantruntime="false"> > - > - > - > + includeantruntime="false" > + classpath="${classes}"> > > - > - > - > - > + + classpath="${classes}"> > > > > > On 15 aug 2012, at 20:17, Joel Borggr?n-Franck wrote: > >> I would't say I'm working on it. >> >> But from the department of "works for me (?)" here is a patch that sort of works for me. It might be breaking other stuff (like full forest builds), and it might not be what we want to do ... >> >> cheers >> /Joel >> >> >> >> On 10 aug 2012, at 07:39, Erik Joelsson wrote: >> >>> It does and I believe Joel, in the langtools team, is looking at this issue. >>> >>> /Erik >>> >>> On 2012-08-10 03:00, Kelly O'Hair wrote: >>>> I think we need to make sure that the only thing that gets built with the bootjdk javac is the langtools >>>> bootstrap javac.jar, all other javac compilations needs to be done by the bootstrap javac. >>>> Does that fix this issue? >>>> >>>> -kto >>>> >>>> On Aug 6, 2012, at 2:33 AM, Erik Joelsson wrote: >>>> >>>>> The classpath reference was added on my request for build-infra. The reason was to get javax.annotation.GenerateNativeHeader on the classpath. The javac used in that ant script is the bootjdk javac, which usually doesn't provide the annotation. I suppose the correct fix would be to change the ant script to use the bootstrap javac instead. >>>>> >>>>> /Erik >>>>> >>>>> On 2012-07-28 00:06, Kumar Srinivasan wrote: >>>>>> On 7/25/2012 2:23 PM, Kelly O'Hair wrote: >>>>>>> Naoto has noticed this build failure on the Mac (just the Mac) when building just the jdk repository. >>>>>>> >>>>>>> From what I can tell, the Mac build of the jdk repository now depends on the langtools repository also >>>>>>> being built, which means that partial builds of just the jdk repository will no longer work on the Mac? >>>>>>> There is an ant script at jdk/src/macosx/native/jobjc/build.xml that has a baked in classpath reference to >>>>>>> ../../langtools/dist/lib/classes.jar >>>>>>> >>>>>>> Has anyone seen this, or have any additional information on it? >>>>>> This is preventing me to test certain things I can only run from a jdk build under >>>>>> jprt on the macosx machine. >>>>>> >>>>>> Kumar >>>>>> >>>>>>> -kto >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> build-core: >>>>>>> [mkdir] Created dir: /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core >>>>>>> [javac] com/apple/jobjc/PrimitiveCoder.java added as com/apple/jobjc/PrimitiveCoder.class doesn't exist. >>>>>>> [javac] Compiling 1 source file to /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core >>>>>>> [javac] Using modern compiler >>>>>>> dropping /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/langtools/dist/lib/classes.jar from path as it doesn't exist >>>>>>> [javac] Compilation arguments: >>>>>>> [javac] '-d' >>>>>>> [javac] '/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core' >>>>>>> [javac] '-classpath' >>>>>>> [javac] '/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core' >>>>>>> [javac] '-sourcepath' >>>>>>> [javac] '/private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java' >>>>>>> [javac] '-target' >>>>>>> [javac] '1.5' >>>>>>> [javac] '-g' >>>>>>> [javac] '-source' >>>>>>> [javac] '1.5' >>>>>>> [javac] >>>>>>> [javac] The ' characters around the executable and arguments are >>>>>>> [javac] not part of the command. >>>>>>> [javac] File to be compiled: >>>>>>> [javac] /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/PrimitiveCoder.java >>>>>>> [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.5 >>>>>>> [javac] /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java:32: warning: Unsafe is internal proprietary API and may be removed in a future release >>>>>>> [javac] import sun.misc.Unsafe; >>>>>>> [javac] ^ >>>>>>> >>>>>>> ..... >>>>>>> >>>>>>> [javac] @GenerateNativeHeader >>>>>>> [javac] ^ >>>>>>> [javac] symbol: class GenerateNativeHeader >>>>>>> [javac] Note: Some input files use unchecked or unsafe operations. >>>>>>> [javac] Note: Recompile with -Xlint:unchecked for details. >>>>>>> [javac] 61 errors >>>>>>> [javac] 7 warnings >>>>>>> >>>>>>> BUILD FAILED >>>>>>> /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/build.xml:143: Compile failed; see the compiler error output for details. >>>>>>> at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:1079) >>>>>>> at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:882) >>>>>>> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) >>>>>>> at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) >>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>>>> at java.lang.reflect.Method.invoke(Method.java:601) >>>>>>> at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) >>>>>>> at org.apache.tools.ant.Task.perform(Task.java:348) >>>>>>> at org.apache.tools.ant.Target.execute(Target.java:357) >>>>>>> at org.apache.tools.ant.Target.performTasks(Target.java:385) >>>>>>> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) >>>>>>> at org.apache.tools.ant.Project.executeTarget(Project.java:1306) >>>>>>> at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) >>>>>>> at org.apache.tools.ant.Project.executeTargets(Project.java:1189) >>>>>>> at org.apache.tools.ant.Main.runBuild(Main.java:758) >>>>>>> at org.apache.tools.ant.Main.startAnt(Main.java:217) >>>>>>> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) >>>>>>> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) >>>>>>> >>>>>>> Total time: 1 second >>>>>>> make[2]: *** [../../../build/macosx-x86_64/JObjC.build/JObjC.jar] Error 1 >>>>>>> make[1]: *** [all] Error 1 >>>>>>> make: *** [all] Error 1 From david.katleman at oracle.com Thu Aug 16 01:09:32 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Thu, 16 Aug 2012 01:09:32 +0000 Subject: hg: jdk8/build: Added tag jdk8-b51 for changeset 57c0aee73090 Message-ID: <20120816010932.E009947540@hg.openjdk.java.net> Changeset: 8d24def5ceb3 Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/8d24def5ceb3 Added tag jdk8-b51 for changeset 57c0aee73090 ! .hgtags From david.katleman at oracle.com Thu Aug 16 01:09:36 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Thu, 16 Aug 2012 01:09:36 +0000 Subject: hg: jdk8/build/corba: Added tag jdk8-b51 for changeset 9b0f841ca9f7 Message-ID: <20120816010937.E694047541@hg.openjdk.java.net> Changeset: 80689ff9cb49 Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/80689ff9cb49 Added tag jdk8-b51 for changeset 9b0f841ca9f7 ! .hgtags From david.katleman at oracle.com Thu Aug 16 01:11:10 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Thu, 16 Aug 2012 01:11:10 +0000 Subject: hg: jdk8/build/hotspot: 11 new changesets Message-ID: <20120816011135.19F9F47542@hg.openjdk.java.net> Changeset: abc951e44e1b Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/abc951e44e1b Added tag jdk8-b51 for changeset 663fc23da8d5 ! .hgtags Changeset: ef437ea56651 Author: amurillo Date: 2012-08-03 13:24 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ef437ea56651 7189086: new hotspot build - hs24-b20 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1d7922586cf6 Author: twisti Date: 2012-07-24 10:51 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1d7922586cf6 7023639: JSR 292 method handle invocation needs a fast path for compiled code 6984705: JSR 292 method handle creation should not go through JNI Summary: remove assembly code for JDK 7 chained method handles Reviewed-by: jrose, twisti, kvn, mhaupt Contributed-by: John Rose , Christian Thalinger , Michael Haupt ! agent/src/share/classes/sun/jvm/hotspot/code/CodeBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java - agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Frame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCFrame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.hpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interpreterGenerator_x86.hpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.hpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_64.hpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/interpreterGenerator_zero.hpp ! src/cpu/zero/vm/interpreter_zero.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/register.hpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/c1/c1_ValueStack.cpp ! src/share/vm/c1/c1_ValueStack.hpp ! src/share/vm/c1/c1_ValueType.cpp ! src/share/vm/c1/c1_ValueType.hpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciEnv.cpp + src/share/vm/ci/ciMemberName.cpp + src/share/vm/ci/ciMemberName.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/vtableStubs.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateTable.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/prims/jvmtiTagMap.cpp - src/share/vm/prims/methodHandleWalk.cpp - src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/utilities/accessFlags.hpp ! src/share/vm/utilities/exceptions.hpp Changeset: 977007096840 Author: twisti Date: 2012-07-27 16:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/977007096840 7187290: nightly failures after JSR 292 lazy method handle update Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/opto/doCall.cpp Changeset: 6c5b7a6becc8 Author: kvn Date: 2012-07-30 09:49 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6c5b7a6becc8 7187454: stack overflow in C2 compiler thread on Solaris x86 Summary: Added new FormatBufferResource class to use thread's resource area for error message buffer. Reviewed-by: twisti ! make/solaris/makefiles/fastdebug.make ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp Changeset: 8cb110fd7627 Author: kvn Date: 2012-08-01 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8cb110fd7627 7188227: VM should recognize M-series SPARC Summary: Check kstat data for SPARC-M. Reviewed-by: roland ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp Changeset: b72784e722ff Author: twisti Date: 2012-08-01 14:44 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b72784e722ff 7188276: JSR 292: assert(ct == T_OBJECT) failed: rt=T_OBJECT, ct=13 Reviewed-by: kvn, jrose ! src/share/vm/opto/doCall.cpp Changeset: 93c71eb28866 Author: twisti Date: 2012-08-07 14:32 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/93c71eb28866 7188911: nightly failures after JSR 292 lazy method handle update (round 2) Reviewed-by: kvn, jrose ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp Changeset: ee7edf31f688 Author: twisti Date: 2012-08-10 15:50 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ee7edf31f688 Merge - agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java - agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java ! make/solaris/makefiles/fastdebug.make ! src/share/vm/opto/phaseX.hpp - src/share/vm/prims/methodHandleWalk.cpp - src/share/vm/prims/methodHandleWalk.hpp Changeset: 4c8f2a12e757 Author: twisti Date: 2012-08-10 17:50 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4c8f2a12e757 Merge Changeset: 6d0436885201 Author: amurillo Date: 2012-08-10 23:07 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6d0436885201 Added tag hs24-b20 for changeset 4c8f2a12e757 ! .hgtags From david.katleman at oracle.com Thu Aug 16 01:13:12 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Thu, 16 Aug 2012 01:13:12 +0000 Subject: hg: jdk8/build/jaxp: Added tag jdk8-b51 for changeset dc1ea77ed9d9 Message-ID: <20120816011316.B37EF47543@hg.openjdk.java.net> Changeset: bd3c00d57614 Author: katleman Date: 2012-08-09 18:01 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/bd3c00d57614 Added tag jdk8-b51 for changeset dc1ea77ed9d9 ! .hgtags From david.katleman at oracle.com Thu Aug 16 01:13:21 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Thu, 16 Aug 2012 01:13:21 +0000 Subject: hg: jdk8/build/jaxws: Added tag jdk8-b51 for changeset 1a70b6333ebe Message-ID: <20120816011325.7C92347544@hg.openjdk.java.net> Changeset: f62bc618122e Author: katleman Date: 2012-08-09 18:01 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/f62bc618122e Added tag jdk8-b51 for changeset 1a70b6333ebe ! .hgtags From david.katleman at oracle.com Thu Aug 16 01:14:19 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Thu, 16 Aug 2012 01:14:19 +0000 Subject: hg: jdk8/build/jdk: 27 new changesets Message-ID: <20120816011943.AB33E47545@hg.openjdk.java.net> Changeset: b3b0d75cb117 Author: katleman Date: 2012-08-09 18:02 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b3b0d75cb117 Added tag jdk8-b51 for changeset e865efbc7105 ! .hgtags Changeset: 21c590fdc8cb Author: mullan Date: 2012-08-01 11:06 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/21c590fdc8cb 7179715: OCSP revocation checking fails if the signer certificate is identified using the key ID Reviewed-by: vinnie ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java Changeset: 9a5a3741bac9 Author: mullan Date: 2012-08-01 11:08 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/9a5a3741bac9 Merge - makefiles/LegacyMakefiles.gmk - makefiles/OldImages.gmk - makefiles/com/sun/crypto/provider/Makefile - makefiles/common/Classes.gmk - makefiles/common/Cscope.gmk - makefiles/common/Defs-embedded.gmk - makefiles/common/Defs-linux.gmk - makefiles/common/Defs-macosx.gmk - makefiles/common/Defs-solaris.gmk - makefiles/common/Defs-windows.gmk - makefiles/common/Defs.gmk - makefiles/common/Demo.gmk - makefiles/common/Library.gmk - makefiles/common/Mapfile-vers.gmk - makefiles/common/Modules.gmk - makefiles/common/Program.gmk - makefiles/common/Release-embedded.gmk - makefiles/common/Release-macosx.gmk - makefiles/common/Release.gmk - makefiles/common/Rules.gmk - makefiles/common/Subdirs.gmk - makefiles/common/internal/Defs-corba.gmk - makefiles/common/internal/Defs-jaxp.gmk - makefiles/common/internal/Defs-jaxws.gmk - makefiles/common/internal/Defs-langtools.gmk - makefiles/common/internal/ImportComponents.gmk - makefiles/common/internal/NativeCompileRules.gmk - makefiles/common/internal/Resources.gmk - makefiles/common/shared/Compiler-gcc.gmk - makefiles/common/shared/Compiler-llvm.gmk - makefiles/common/shared/Compiler-msvc.gmk - makefiles/common/shared/Compiler-sun.gmk - makefiles/common/shared/Defs-control.gmk - makefiles/common/shared/Defs-java.gmk - makefiles/common/shared/Defs-javadoc.gmk - makefiles/common/shared/Defs-linux.gmk - makefiles/common/shared/Defs-macosx.gmk - makefiles/common/shared/Defs-solaris.gmk - makefiles/common/shared/Defs-versions.gmk - makefiles/common/shared/Defs-windows.gmk - makefiles/common/shared/Defs.gmk - makefiles/common/shared/Platform.gmk - makefiles/common/shared/PrivateDefs.gmk-example - makefiles/common/shared/Sanity-Settings.gmk - makefiles/java/Makefile - makefiles/java/invoke/Makefile - makefiles/java/redist/Makefile - makefiles/java/redist/sajdi/Makefile - makefiles/javax/crypto/Defs-jce.gmk - makefiles/javax/crypto/Makefile - makefiles/javax/crypto/policy/limited/LIMITED - makefiles/javax/crypto/policy/limited/default_local.policy - makefiles/javax/crypto/policy/limited/exempt_local.policy - makefiles/javax/crypto/policy/unlimited/UNLIMITED - makefiles/javax/crypto/policy/unlimited/default_US_export.policy - makefiles/javax/crypto/policy/unlimited/default_local.policy - makefiles/mkdemo/Makefile - makefiles/mkdemo/jni/Makefile - makefiles/mkdemo/jni/Poller/Makefile - makefiles/mkdemo/jvmti/Makefile - makefiles/mkdemo/jvmti/README.txt - makefiles/mkdemo/jvmti/hprof/Makefile - makefiles/mkdemo/jvmti/mapfile-vers - makefiles/mkdemo/management/README.txt - makefiles/sun/jkernel/Makefile - makefiles/sun/security/ec/Makefile - makefiles/sun/security/pkcs11/FILES_c.gmk - makefiles/sun/security/pkcs11/Makefile - makefiles/sun/security/pkcs11/mapfile-vers - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java - src/share/classes/sun/security/krb5/ServiceName.java - test/sun/security/krb5/ServiceNameClone.java - test/sun/security/mscapi/ShortRSAKey512.sh - test/sun/security/mscapi/ShortRSAKey768.sh Changeset: 184da100cf45 Author: jgish Date: 2012-07-27 16:17 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/184da100cf45 6914123: (str) Missing synchronization in java.lang.String#contentEquals(CharSequence) Summary: Change contentEquals( CharSequence cs ) to do synchronization if cs is a StringBuffer Reviewed-by: mduigou Contributed-by: Jim Gish ! src/share/classes/java/lang/String.java Changeset: 75bda37d0337 Author: omajid Date: 2012-08-01 22:13 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/75bda37d0337 6844255: Potential stack corruption in GetJavaProperties Summary: Use dynamically allocated buffers for temp and encoding. Reviewed-by: alanb, andrew ! src/solaris/native/java/lang/java_props_md.c Changeset: b0bfa441d70f Author: mullan Date: 2012-08-02 10:40 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b0bfa441d70f 7026347: Certificate and X509CRL should have verify(PublicKey key, Provider sigProvider) Reviewed-by: mullan, xuelei, weijun Contributed-by: jason.uh at oracle.com ! src/share/classes/java/security/cert/Certificate.java ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509Certificate.java ! src/share/classes/sun/security/x509/X509CRLImpl.java ! src/share/classes/sun/security/x509/X509CertImpl.java + test/sun/security/x509/X509CRLImpl/Verify.java + test/sun/security/x509/X509CertImpl/Verify.java Changeset: 4e8bafdcefda Author: mullan Date: 2012-08-02 10:42 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/4e8bafdcefda Merge Changeset: 8a82e5f9c47f Author: dmocek Date: 2012-08-02 18:12 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/8a82e5f9c47f 7187876: ClassCastException in TCPTransport.executeAcceptLoop Reviewed-by: dholmes, smarks ! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java Changeset: 1468b0af0d06 Author: sherman Date: 2012-08-03 13:40 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1468b0af0d06 7188852: Move implementation of De/Inflater.getBytesRead/Writtten() to java from native Summary: re-implemented getBytesRead/Writtten() at java level Reviewed-by: andrew, alanb ! make/java/zip/mapfile-vers ! src/share/classes/java/util/zip/Deflater.java ! src/share/classes/java/util/zip/Inflater.java ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c ! src/share/native/java/util/zip/zlib-1.2.5/compress.c ! src/share/native/java/util/zip/zlib-1.2.5/inflate.c ! src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java ! src/share/native/java/util/zip/zlib-1.2.5/zlib.h + test/java/util/zip/TotalInOut.java Changeset: 3521fcad4b5f Author: ksrini Date: 2012-07-31 06:10 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3521fcad4b5f 7188114: (launcher) need an alternate command line parser for Windows Reviewed-by: darcy, dholmes, jjh Contributed-by: akhil.arora at oracle.com + src/windows/bin/cmdtoargs.c Changeset: 2dd41a2dfe54 Author: ksrini Date: 2012-07-31 06:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/2dd41a2dfe54 7146424: Wildcard expansion for single entry classpath Reviewed-by: dholmes, darcy, jjh, sherman ! make/common/Program.gmk ! make/java/jli/Makefile ! make/java/jli/mapfile-vers ! src/share/bin/java.c ! src/share/bin/java.h ! src/share/bin/jli_util.c ! src/share/bin/jli_util.h ! src/share/bin/main.c ! src/share/bin/wildcard.c ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties - src/solaris/bin/java_md.c ! src/solaris/bin/java_md_common.c ! src/windows/bin/java_md.c ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java ! test/tools/launcher/ToolsOpts.java Changeset: e0ef14d89741 Author: alanb Date: 2012-08-07 12:47 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e0ef14d89741 7076644: TEST_BUG: test/java/io/File/Basic.java fails with cygwin Reviewed-by: alanb Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/io/File/basic.sh Changeset: b0d6552ba301 Author: lana Date: 2012-08-07 20:23 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b0d6552ba301 Merge - make/sunw/Makefile - src/share/classes/sunw/io/Serializable.java - src/share/classes/sunw/util/EventListener.java - src/share/classes/sunw/util/EventObject.java ! src/solaris/native/java/lang/java_props_md.c Changeset: d87e86aaf2b3 Author: andrew Date: 2012-08-08 12:37 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/d87e86aaf2b3 7189533: GetJavaProperties should free temporary file if subsequent allocations fails Summary: Add missing calls to free Reviewed-by: alanb, dholmes, sherman ! src/solaris/native/java/lang/java_props_md.c Changeset: a50e92a980a5 Author: alanb Date: 2012-08-08 15:31 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a50e92a980a5 7189886: (aio) Add test coverage for AsynchronousChannelGroup.withThreadPool Reviewed-by: alanb Contributed-by: amy.lu at oracle.com ! test/java/nio/channels/AsynchronousChannelGroup/AsExecutor.java ! test/java/nio/channels/AsynchronousChannelGroup/Basic.java ! test/java/nio/channels/AsynchronousChannelGroup/Restart.java Changeset: a44671e0b6d7 Author: ksrini Date: 2012-08-08 09:29 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a44671e0b6d7 7189944: (launcher) test/tools/launcher/Arrrrghs.java needs a couple of minor fixes Reviewed-by: darcy, jgish ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java Changeset: bf85c3ab2637 Author: dsamersoff Date: 2012-08-09 14:52 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/bf85c3ab2637 7183753: [TEST] Some colon in the diff for this test Summary: Reference output file contains extra colon Reviewed-by: sspitsyn, mgronlun ! test/sun/tools/jcmd/help_help.out Changeset: da8649489aff Author: lana Date: 2012-08-10 10:15 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/da8649489aff Merge Changeset: 05e5ce861a58 Author: jrose Date: 2012-07-12 00:10 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/05e5ce861a58 7153157: ClassValue.get does not return if computeValue calls remove Summary: Track intermediate states more precisely, according to spec. Reviewed-by: twisti, forax ! src/share/classes/java/lang/ClassValue.java Changeset: beeb1d5ecd9e Author: jrose Date: 2012-07-12 00:11 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/beeb1d5ecd9e 7129034: VM crash with a field setter method with a filterArguments Summary: add null checks before unsafe calls that take a variable base reference; update unit tests Reviewed-by: kvn, twisti ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! test/java/lang/invoke/MethodHandlesTest.java Changeset: 556141c6326c Author: jrose Date: 2012-07-12 00:12 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/556141c6326c 7087658: MethodHandles.Lookup.findVirtual is confused by interface methods that are multiply inherited Reviewed-by: twisti ! src/share/classes/java/lang/invoke/MemberName.java Changeset: 78f1f4e4e9c7 Author: jrose Date: 2012-07-12 00:12 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/78f1f4e4e9c7 7127687: MethodType leaks memory due to interning Summary: Replace internTable with a weak-reference version. Reviewed-by: sundar, forax, brutisso Contributed-by: james.laskey at oracle.com ! src/share/classes/java/lang/invoke/MethodType.java Changeset: 050116960e99 Author: twisti Date: 2012-07-24 10:47 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/050116960e99 7023639: JSR 292 method handle invocation needs a fast path for compiled code 6984705: JSR 292 method handle creation should not go through JNI Summary: remove assembly code for JDK 7 chained method handles Reviewed-by: jrose, twisti, mhaupt, forax Contributed-by: John Rose , Christian Thalinger , Michael Haupt - src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java - src/share/classes/java/lang/invoke/CountingMethodHandle.java ! src/share/classes/java/lang/invoke/DirectMethodHandle.java + src/share/classes/java/lang/invoke/DontInline.java + src/share/classes/java/lang/invoke/ForceInline.java + src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/Invokers.java + src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java + src/share/classes/java/lang/invoke/MethodHandleInfo.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java + src/share/classes/java/lang/invoke/SimpleMethodHandle.java ! src/share/classes/java/lang/invoke/package-info.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/invoke/util/VerifyAccess.java ! src/share/classes/sun/invoke/util/VerifyType.java ! src/share/classes/sun/invoke/util/Wrapper.java ! src/share/classes/sun/misc/Unsafe.java + test/java/lang/invoke/7157574/Test7157574.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java + test/java/lang/invoke/MaxTest.java ! test/java/lang/invoke/MethodHandlesTest.java + test/java/lang/invoke/PrivateInvokeTest.java ! test/java/lang/invoke/ThrowExceptionsTest.java + test/java/lang/invoke/remote/RemoteExample.java ! test/sun/invoke/util/ValueConversionsTest.java Changeset: 64e24cc8e009 Author: twisti Date: 2012-08-07 14:31 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/64e24cc8e009 7188911: nightly failures after JSR 292 lazy method handle update (round 2) Reviewed-by: kvn, jrose ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/MemberName.java Changeset: e1d063685dc8 Author: twisti Date: 2012-08-09 15:03 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e1d063685dc8 7190416: JSR 292: typo in InvokerBytecodeGenerator.getConstantPoolSize Reviewed-by: jrose ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Changeset: 865c411ebcae Author: twisti Date: 2012-08-10 16:03 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/865c411ebcae Merge - src/share/classes/java/lang/invoke/AdapterMethodHandle.java - src/share/classes/java/lang/invoke/CountingMethodHandle.java Changeset: e8569a473cee Author: katleman Date: 2012-08-15 18:04 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e8569a473cee Merge From david.katleman at oracle.com Thu Aug 16 01:21:24 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Thu, 16 Aug 2012 01:21:24 +0000 Subject: hg: jdk8/build/langtools: 7 new changesets Message-ID: <20120816012140.89E7C47546@hg.openjdk.java.net> Changeset: 23032c78b2d1 Author: katleman Date: 2012-08-09 18:02 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/23032c78b2d1 Added tag jdk8-b51 for changeset c4cd4cab2220 ! .hgtags Changeset: cddc2c894cc6 Author: mcimadamore Date: 2012-08-02 18:22 +0100 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/cddc2c894cc6 7175911: Simplify error reporting API in Check.CheckContext interface Summary: Make error messages generated during Check.checkType more uniform and more scalable Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/6840059/T6840059.out ! test/tools/javac/6979683/TestCast6979683_BAD34.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD35.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD36.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD37.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD38.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD39.java.errlog ! test/tools/javac/7132880/T7132880.out ! test/tools/javac/Diagnostics/6722234/T6722234a_1.out ! test/tools/javac/Diagnostics/6722234/T6722234a_2.out ! test/tools/javac/Diagnostics/6722234/T6722234c.out ! test/tools/javac/Diagnostics/6722234/T6722234d_1.out ! test/tools/javac/Diagnostics/6722234/T6722234d_2.out ! test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/Diagnostics/6862608/T6862608a.out ! test/tools/javac/Diagnostics/6862608/T6862608b.out ! test/tools/javac/OverrideChecks/6400189/T6400189a.out ! test/tools/javac/OverrideChecks/6400189/T6400189b.out ! test/tools/javac/StringsInSwitch/BadlyTypedLabel1.out ! test/tools/javac/StringsInSwitch/BadlyTypedLabel2.out ! test/tools/javac/T6326754.out ! test/tools/javac/TryWithResources/TwrOnNonResource.out ! test/tools/javac/cast/6270087/T6270087neg.out ! test/tools/javac/cast/6557182/T6557182.out ! test/tools/javac/cast/6665356/T6665356.out ! test/tools/javac/cast/6795580/T6795580.out ! test/tools/javac/cast/6932571/T6932571neg.out ! test/tools/javac/cast/7005095/T7005095neg.out ! test/tools/javac/cast/7005671/T7005671.out ! test/tools/javac/diags/examples/CantApplyDiamond1.java ! test/tools/javac/diags/examples/IncompatibleTypes1.java ! test/tools/javac/diags/examples/InconvertibleTypes.java ! test/tools/javac/diags/examples/InferNoConformingAssignment.java ! test/tools/javac/diags/examples/InferVarargsArgumentMismatch.java ! test/tools/javac/diags/examples/InferredDoNotConformToLower.java ! test/tools/javac/diags/examples/KindnameConstructor.java ! test/tools/javac/diags/examples/NoUniqueMaximalInstance.java ! test/tools/javac/diags/examples/NotApplicableMethodFound.java ! test/tools/javac/diags/examples/PossibleLossPrecision.java ! test/tools/javac/diags/examples/ResourceNotApplicableToType.java ! test/tools/javac/diags/examples/VarargsArgumentMismatch.java ! test/tools/javac/diags/examples/VerboseResolveMulti1.java ! test/tools/javac/diags/examples/WhereFreshTvar.java ! test/tools/javac/diags/examples/WhereIntersection.java ! test/tools/javac/diags/examples/WhereTypeVar.java ! test/tools/javac/generics/6207386/T6207386.out ! test/tools/javac/generics/diamond/neg/Neg05.out ! test/tools/javac/generics/diamond/neg/Neg06.out ! test/tools/javac/generics/diamond/neg/Neg10.out ! test/tools/javac/generics/inference/6315770/T6315770.out ! test/tools/javac/generics/inference/6611449/T6611449.out ! test/tools/javac/generics/inference/6638712/T6638712a.out ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6638712/T6638712c.out ! test/tools/javac/generics/inference/6638712/T6638712e.out ! test/tools/javac/generics/inference/6650759/T6650759m.out ! test/tools/javac/generics/inference/6838943/T6838943.out ! test/tools/javac/generics/inference/7086586/T7086586.out ! test/tools/javac/generics/inference/7154127/T7154127.out ! test/tools/javac/generics/rawOverride/7062745/T7062745neg.out ! test/tools/javac/generics/wildcards/6886247/T6886247_2.out ! test/tools/javac/multicatch/Neg06.out ! test/tools/javac/multicatch/Neg07.out ! test/tools/javac/types/CastObjectToPrimitiveTest.out ! test/tools/javac/varargs/6313164/T6313164.out ! test/tools/javac/varargs/7097436/T7097436.out Changeset: e5cf1569d3a4 Author: mcimadamore Date: 2012-08-02 18:23 +0100 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/e5cf1569d3a4 7175538: Integrate efectively final check with DA/DU analysis Summary: Allow generalized effectively-final analysis for all local variables Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/CantRefNonEffectivelyFinalVar.java + test/tools/javac/lambda/EffectivelyFinalTest.java + test/tools/javac/lambda/EffectivelyFinalTest01.out + test/tools/javac/lambda/EffectivelyFinalTest02.out Changeset: 2d75e7c952b8 Author: mcimadamore Date: 2012-08-02 18:24 +0100 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/2d75e7c952b8 7187104: Inference cleanup: remove redundant exception classes in Infer.java Summary: Remove unused exception classes in Infer.java Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java Changeset: cfa70d7ac944 Author: lana Date: 2012-08-07 20:24 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/cfa70d7ac944 Merge Changeset: f071cd32d297 Author: sundar Date: 2012-08-08 22:17 +0530 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/f071cd32d297 7178324: Crash when compiling for(i : x) try(AutoCloseable x = ...) {} Reviewed-by: darcy, jjg ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/javac/TryWithResources/T7178324.java Changeset: 1d2db0e5eabc Author: lana Date: 2012-08-10 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/1d2db0e5eabc Merge From chris.hegarty at oracle.com Thu Aug 16 09:39:54 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 16 Aug 2012 10:39:54 +0100 Subject: RFR : 7185965 Build error in javadoc make stage for bundles not containing crypto package In-Reply-To: <502926D2.8040402@oracle.com> References: <502926D2.8040402@oracle.com> Message-ID: <502CBFEA.8050208@oracle.com> This change looks ok to me. -Chris. On 13/08/2012 17:09, Se?n Coffey wrote: > Similar to 7163470, the JDK has historically allowed builds without the > javax.crypto package src. > > In such cases a jce.jar bootstrap should be used where necessary. One > remaining use case is during javadoc building process. Simple fix and > I've verified with a test build of docs. > > bug report : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7185965 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.7185965.jdk8/ > > > Regards, > Sean. > > From neugens.limasoftware at gmail.com Sun Aug 12 11:21:12 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sun, 12 Aug 2012 13:21:12 +0200 Subject: webrev failure? In-Reply-To: References: Message-ID: Il giorno 11/ago/2012, alle ore 18:04, Martijn Verburg ha scritto: > Hi all, > > Apologies if these are the wrong mailing lists, but I'm assuming that > the webrev tool falls under this domain somewhat. > > In order to get patches into the OpenJDK as cleanly as possible, we're > looking to utilise webrev (since it's the std and all). > > Running "ksh ./make/scripts/webrev.ksh -f" over the latest jdk8/tl > source (no patches, but a full build was completed using build-infra) > and I got a host of errors: Hi Matijn, I can't try right now to check the specific problem, but one possible thing to take into account is that you probably want to only execute webrev on specific repository tree, not the whole forest. Cheers, Mario --- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.ladybug-studio.com IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From naoto.sato at oracle.com Mon Aug 20 17:14:18 2012 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 20 Aug 2012 10:14:18 -0700 Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data In-Reply-To: <84F7A368-1206-4D3C-A79F-9F2C6F8EC719@oracle.com> References: <737597189.4451353.1344937908713.JavaMail.root@redhat.com> <84F7A368-1206-4D3C-A79F-9F2C6F8EC719@oracle.com> Message-ID: <5032706A.8060007@oracle.com> I have updated the changeset by removing the copyright headers from all of the CLDR files, and added a LICENSE file at the top of CLDR source directory (src/share/classes/sun/util/cldr/resources/21_0_1). No other changes have been made this time. http://cr.openjdk.java.net/~naoto/6336885/webrev.03/ Naoto On H.24/08/14 9:16, Jeff Dinkins wrote: > > Andrew - good catch. We're reviewing. > > On Aug 14, 2012, at 2:51 AM, Andrew Hughes wrote: >> ----- Original Message ----- >>> Hello, >>> >>> Please review the JDK8 changes for JEP 127: Improve Locale Data >>> Packaging and Adopt Unicode CLDR Data >>> (http://openjdk.java.net/jeps/127). The webrev is located at: >>> >>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/ >>> >>> The main bug id for this enhancement is: >>> >>> 6336885: RFE: Locale Data Deployment Enhancements >>> >>> Along with this, the following bugs/enhancements are also implemented >>> in >>> this change: >>> >>> 4609153 Provide locale data for Indic locales >>> 5104387 Support for gl_ES locale (galician language) >>> 6337471 desktop/system locale preferences support >>> 7056139 (cal) SPI support for locale-dependent Calendar parameters >>> 7058206 Provide CalendarData SPI for week params and display field >>> value >>> names >>> 7073852 Support multiple scripts for digits and decimal symbols per >>> locale >>> 7079560 [Fmt-Da] Context dependent month names support in >>> SimpleDateFormat >>> 7171324 getAvailableLocales() of locale sensitive services should >>> return >>> the actual availability of locales >>> 7151414 (cal) Support calendar type identification >>> 7168528 LocaleServiceProvider needs to be aware of Locale extensions >>> 7171372 (cal) locale's default Calendar should be created if unknown >>> calendar is specified >>> >>> Please note that packaging changes that relate to Jigsaw module >>> system >>> aren't included in this changeset. >>> >>> Naoto Sato and Masayoshi Okutsu >>> >> >> First of all, I'd like to say congratulations on completing this week and >> adopting the CLDR as a source for locale data. This is something we've used >> for GNU Classpath's locale data for many years, and, with these changes, it >> should mean that the Java API itself should see changes which allow it to >> support some of the features present in the CLDR data. >> >> However, I am a little concerned by the inclusion of CLDR data files in this >> webrev with a GPL header assigning copyright to Oracle e.g. >> >> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/src/share/classes/sun/util/cldr/resources/21_0_1/common/main/agq.xml.patch >> >> Is this legal? IANAL, but http://unicode.org/copyright.html#Exhibit1 seems to >> state that the header given there should be present on this data. The current >> files make it look like this data was created by Oracle this year, which is clearly >> inaccurate. >> >> Thanks, >> -- >> Andrew :) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> PGP Key: 248BDC07 (https://keys.indymedia.org/) >> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >> > From ahughes at redhat.com Mon Aug 20 17:57:50 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Mon, 20 Aug 2012 13:57:50 -0400 (EDT) Subject: [7u6] Request for approval for CR 7157855: jvisualvm.1 not included in binaries In-Reply-To: <4FB2A216.5050805@oracle.com> Message-ID: <760741665.7893220.1345485470301.JavaMail.root@redhat.com> ----- Original Message ----- > This fix is also addressed in jdk8 at the same time. > > Bug: http://bugs.sun.com/view_bug.do?bug_id=7157855 > Webrev: http://cr.openjdk.java.net/~mfang/7157855/ > Reviewers: katleman, thurka > > thanks, > > -michael > Do you have a link to where this was reviewed? I don't see it in my inbox. There is a flaw in this patch. jvisualvm is not part of OpenJDK so the man page should not be installed if building OpenJDK. The same bug had to be rectified for javaws in 7021314: Build should not install javaws man page. I'll post a webrev but basically it needs to be surrounded by an #ifndef OPENJDK. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From sean.coffey at oracle.com Mon Aug 20 22:24:26 2012 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Mon, 20 Aug 2012 23:24:26 +0100 Subject: [7u6] Request for approval for CR 7157855: jvisualvm.1 not included in binaries In-Reply-To: <760741665.7893220.1345485470301.JavaMail.root@redhat.com> References: <760741665.7893220.1345485470301.JavaMail.root@redhat.com> Message-ID: <5032B91A.7090506@oracle.com> I can't find the original jdk8 review thread either. Good catch Andrew. I've created a bug ID for you : (should be live in next 1-2 days) 7192804 : Build should not install jvisualvm man page for OpenJDK Needs addressing in JDK8 and 7u. JDK8 will need addressing in the old and new makefile systems. regards, Sean. On 20/08/2012 18:57, Andrew Hughes wrote: > ----- Original Message ----- >> This fix is also addressed in jdk8 at the same time. >> >> Bug: http://bugs.sun.com/view_bug.do?bug_id=7157855 >> Webrev: http://cr.openjdk.java.net/~mfang/7157855/ >> Reviewers: katleman, thurka >> >> thanks, >> >> -michael >> > Do you have a link to where this was reviewed? I don't see it in my inbox. > > There is a flaw in this patch. jvisualvm is not part of OpenJDK so the man > page should not be installed if building OpenJDK. > > The same bug had to be rectified for javaws in 7021314: Build should not install javaws man page. > > I'll post a webrev but basically it needs to be surrounded by an #ifndef OPENJDK. From michael.fang at oracle.com Tue Aug 21 02:39:18 2012 From: michael.fang at oracle.com (Michael Fang) Date: Mon, 20 Aug 2012 19:39:18 -0700 Subject: [7u6] Request for approval for CR 7157855: jvisualvm.1 not included in binaries In-Reply-To: <5032B91A.7090506@oracle.com> References: <760741665.7893220.1345485470301.JavaMail.root@redhat.com> <5032B91A.7090506@oracle.com> Message-ID: <5032F4D6.6030801@oracle.com> Hi Andrew/Sean, The review was posted on internal ReviewBoard and was reviewed by Dave (build) and Tomas (VisualVM). Next time I will remember to post to project alias. thanks, -michael On 12?08?20? 03:24 ??, Se?n Coffey wrote: > I can't find the original jdk8 review thread either. > > Good catch Andrew. I've created a bug ID for you : (should be live in > next 1-2 days) > 7192804 : Build should not install jvisualvm man page for OpenJDK > > Needs addressing in JDK8 and 7u. JDK8 will need addressing in the old > and new makefile systems. > > regards, > Sean. > > On 20/08/2012 18:57, Andrew Hughes wrote: >> ----- Original Message ----- >>> This fix is also addressed in jdk8 at the same time. >>> >>> Bug: http://bugs.sun.com/view_bug.do?bug_id=7157855 >>> Webrev: http://cr.openjdk.java.net/~mfang/7157855/ >>> Reviewers: katleman, thurka >>> >>> thanks, >>> >>> -michael >>> >> Do you have a link to where this was reviewed? I don't see it in my >> inbox. >> >> There is a flaw in this patch. jvisualvm is not part of OpenJDK so >> the man >> page should not be installed if building OpenJDK. >> >> The same bug had to be rectified for javaws in 7021314: Build should >> not install javaws man page. >> >> I'll post a webrev but basically it needs to be surrounded by an >> #ifndef OPENJDK. From erik.joelsson at oracle.com Tue Aug 21 07:33:32 2012 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 21 Aug 2012 09:33:32 +0200 Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data In-Reply-To: <5032706A.8060007@oracle.com> References: <737597189.4451353.1344937908713.JavaMail.root@redhat.com> <84F7A368-1206-4D3C-A79F-9F2C6F8EC719@oracle.com> <5032706A.8060007@oracle.com> Message-ID: <503339CC.4020205@oracle.com> Looks good to me. I'm ok with this. /Erik On 2012-08-20 19:14, Naoto Sato wrote: > I have updated the changeset by removing the copyright headers from > all of the CLDR files, and added a LICENSE file at the top of CLDR > source directory (src/share/classes/sun/util/cldr/resources/21_0_1). > No other changes have been made this time. > > http://cr.openjdk.java.net/~naoto/6336885/webrev.03/ > > Naoto > > On H.24/08/14 9:16, Jeff Dinkins wrote: >> >> Andrew - good catch. We're reviewing. >> >> On Aug 14, 2012, at 2:51 AM, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> Hello, >>>> >>>> Please review the JDK8 changes for JEP 127: Improve Locale Data >>>> Packaging and Adopt Unicode CLDR Data >>>> (http://openjdk.java.net/jeps/127). The webrev is located at: >>>> >>>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/ >>>> >>>> The main bug id for this enhancement is: >>>> >>>> 6336885: RFE: Locale Data Deployment Enhancements >>>> >>>> Along with this, the following bugs/enhancements are also implemented >>>> in >>>> this change: >>>> >>>> 4609153 Provide locale data for Indic locales >>>> 5104387 Support for gl_ES locale (galician language) >>>> 6337471 desktop/system locale preferences support >>>> 7056139 (cal) SPI support for locale-dependent Calendar parameters >>>> 7058206 Provide CalendarData SPI for week params and display field >>>> value >>>> names >>>> 7073852 Support multiple scripts for digits and decimal symbols per >>>> locale >>>> 7079560 [Fmt-Da] Context dependent month names support in >>>> SimpleDateFormat >>>> 7171324 getAvailableLocales() of locale sensitive services should >>>> return >>>> the actual availability of locales >>>> 7151414 (cal) Support calendar type identification >>>> 7168528 LocaleServiceProvider needs to be aware of Locale extensions >>>> 7171372 (cal) locale's default Calendar should be created if unknown >>>> calendar is specified >>>> >>>> Please note that packaging changes that relate to Jigsaw module >>>> system >>>> aren't included in this changeset. >>>> >>>> Naoto Sato and Masayoshi Okutsu >>>> >>> >>> First of all, I'd like to say congratulations on completing this >>> week and >>> adopting the CLDR as a source for locale data. This is something >>> we've used >>> for GNU Classpath's locale data for many years, and, with these >>> changes, it >>> should mean that the Java API itself should see changes which allow >>> it to >>> support some of the features present in the CLDR data. >>> >>> However, I am a little concerned by the inclusion of CLDR data files >>> in this >>> webrev with a GPL header assigning copyright to Oracle e.g. >>> >>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/src/share/classes/sun/util/cldr/resources/21_0_1/common/main/agq.xml.patch >>> >>> >>> Is this legal? IANAL, but >>> http://unicode.org/copyright.html#Exhibit1 seems to >>> state that the header given there should be present on this data. >>> The current >>> files make it look like this data was created by Oracle this year, >>> which is clearly >>> inaccurate. >>> >>> Thanks, >>> -- >>> Andrew :) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> PGP Key: 248BDC07 (https://keys.indymedia.org/) >>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >>> >> > From ahughes at redhat.com Tue Aug 21 11:13:03 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Tue, 21 Aug 2012 07:13:03 -0400 (EDT) Subject: [7u6] Request for approval for CR 7157855: jvisualvm.1 not included in binaries In-Reply-To: <5032B91A.7090506@oracle.com> Message-ID: <1860727184.8293176.1345547583143.JavaMail.root@redhat.com> ----- Original Message ----- > I can't find the original jdk8 review thread either. > > Good catch Andrew. I've created a bug ID for you : (should be live in > next 1-2 days) > 7192804 : Build should not install jvisualvm man page for OpenJDK > Thanks :-) > Needs addressing in JDK8 and 7u. JDK8 will need addressing in the old > and new makefile systems. > Ah good catch. I didn't realise this was duplicated in the new build system. http://cr.openjdk.java.net/~andrew/jvisualvm/webrev.02/ should deal with both cases. If this is ok, is there a preferred forest to push to? I've been testing against build, but can easily push it somewhere else. > regards, > Sean. > > On 20/08/2012 18:57, Andrew Hughes wrote: > > ----- Original Message ----- > >> This fix is also addressed in jdk8 at the same time. > >> > >> Bug: http://bugs.sun.com/view_bug.do?bug_id=7157855 > >> Webrev: http://cr.openjdk.java.net/~mfang/7157855/ > >> Reviewers: katleman, thurka > >> > >> thanks, > >> > >> -michael > >> > > Do you have a link to where this was reviewed? I don't see it in > > my inbox. > > > > There is a flaw in this patch. jvisualvm is not part of OpenJDK so > > the man > > page should not be installed if building OpenJDK. > > > > The same bug had to be rectified for javaws in 7021314: Build > > should not install javaws man page. > > > > I'll post a webrev but basically it needs to be surrounded by an > > #ifndef OPENJDK. > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From sean.coffey at oracle.com Tue Aug 21 11:37:46 2012 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Tue, 21 Aug 2012 12:37:46 +0100 Subject: [7u6] Request for approval for CR 7157855: jvisualvm.1 not included in binaries In-Reply-To: <1860727184.8293176.1345547583143.JavaMail.root@redhat.com> References: <1860727184.8293176.1345547583143.JavaMail.root@redhat.com> Message-ID: <5033730A.7060700@oracle.com> Looks fine to me but best to get an official jdk8 reviewer. I presume the filter-out option on macosx becomes a no-op (on OpenJDK builds) some lines later : (Images.gmk) 264 JDK_MAN_PAGES := $(filter-out jvisualvm.1, $(JDK_MAN_PAGES)) On the subject of dual Makefile maintenance, are there plans to eventually remove the older/legacy makefile structure on 8? I haven't been monitoring that topic too closely. regards, Sean. On 21/08/2012 12:13, Andrew Hughes wrote: > Ah good catch. I didn't realise this was duplicated in the new build system. > > http://cr.openjdk.java.net/~andrew/jvisualvm/webrev.02/ > > should deal with both cases. > > If this is ok, is there a preferred forest to push to? I've been testing against > build, but can easily push it somewhere else. From yuka.kamiya at oracle.com Tue Aug 21 13:21:09 2012 From: yuka.kamiya at oracle.com (Yuka Kamiya) Date: Tue, 21 Aug 2012 22:21:09 +0900 Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data In-Reply-To: <5032706A.8060007@oracle.com> References: <737597189.4451353.1344937908713.JavaMail.root@redhat.com> <84F7A368-1206-4D3C-A79F-9F2C6F8EC719@oracle.com> <5032706A.8060007@oracle.com> Message-ID: <50338B45.4050906@oracle.com> Hi, It looks good to me. Thanks, -- Yuka (12/08/21 2:14), Naoto Sato wrote: > I have updated the changeset by removing the copyright headers from all of the CLDR files, and added a LICENSE file at the top of CLDR source directory (src/share/classes/sun/util/cldr/resources/21_0_1). No other changes have been made this time. > > http://cr.openjdk.java.net/~naoto/6336885/webrev.03/ > > Naoto > > On H.24/08/14 9:16, Jeff Dinkins wrote: >> >> Andrew - good catch. We're reviewing. >> >> On Aug 14, 2012, at 2:51 AM, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> Hello, >>>> >>>> Please review the JDK8 changes for JEP 127: Improve Locale Data >>>> Packaging and Adopt Unicode CLDR Data >>>> (http://openjdk.java.net/jeps/127). The webrev is located at: >>>> >>>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/ >>>> >>>> The main bug id for this enhancement is: >>>> >>>> 6336885: RFE: Locale Data Deployment Enhancements >>>> >>>> Along with this, the following bugs/enhancements are also implemented >>>> in >>>> this change: >>>> >>>> 4609153 Provide locale data for Indic locales >>>> 5104387 Support for gl_ES locale (galician language) >>>> 6337471 desktop/system locale preferences support >>>> 7056139 (cal) SPI support for locale-dependent Calendar parameters >>>> 7058206 Provide CalendarData SPI for week params and display field >>>> value >>>> names >>>> 7073852 Support multiple scripts for digits and decimal symbols per >>>> locale >>>> 7079560 [Fmt-Da] Context dependent month names support in >>>> SimpleDateFormat >>>> 7171324 getAvailableLocales() of locale sensitive services should >>>> return >>>> the actual availability of locales >>>> 7151414 (cal) Support calendar type identification >>>> 7168528 LocaleServiceProvider needs to be aware of Locale extensions >>>> 7171372 (cal) locale's default Calendar should be created if unknown >>>> calendar is specified >>>> >>>> Please note that packaging changes that relate to Jigsaw module >>>> system >>>> aren't included in this changeset. >>>> >>>> Naoto Sato and Masayoshi Okutsu >>>> >>> >>> First of all, I'd like to say congratulations on completing this week and >>> adopting the CLDR as a source for locale data. This is something we've used >>> for GNU Classpath's locale data for many years, and, with these changes, it >>> should mean that the Java API itself should see changes which allow it to >>> support some of the features present in the CLDR data. >>> >>> However, I am a little concerned by the inclusion of CLDR data files in this >>> webrev with a GPL header assigning copyright to Oracle e.g. >>> >>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/src/share/classes/sun/util/cldr/resources/21_0_1/common/main/agq.xml.patch >>> >>> Is this legal? IANAL, but http://unicode.org/copyright.html#Exhibit1 seems to >>> state that the header given there should be present on this data. The current >>> files make it look like this data was created by Oracle this year, which is clearly >>> inaccurate. >>> >>> Thanks, >>> -- >>> Andrew :) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> PGP Key: 248BDC07 (https://keys.indymedia.org/) >>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >>> >> > From staffan.larsen at oracle.com Tue Aug 21 13:45:35 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 21 Aug 2012 15:45:35 +0200 Subject: webrev failure? In-Reply-To: <20120813160521.GE2509@toonder.wildebeest.org> References: <5027939A.8060209@oracle.com> <20120813160521.GE2509@toonder.wildebeest.org> Message-ID: <5FC8F64F-77BB-4537-B286-B0533AA97D3F@oracle.com> On 13 aug 2012, at 18:05, Mark Wielaard wrote: > On Sun, Aug 12, 2012 at 12:39:57PM +0100, Martijn Verburg wrote: >> Aha! :-). Any ideas on how far I need to downgrade the version of hg? >> (I'm 2.3 at the moment). > > I am at 2.2.3. The hgforest extension as maintained at > http://icedtea.classpath.org/hg/hgforest > (which is a merge of various hgforest forks) > works with that. It is also the version that is installed on > the icedtea server itself to host forests. > > If there are patches needed for 2.3 we can incorporate those too. Mercurial 2.3 seems to have changed quite a bit on the inside. I spent an hour or so (without knowing anything about the mercurial insides) trying to patch forest to work with 2.3 but failed. Perhaps someone with better mercurial knowledge can take a look. I ended up downgrading to 2.2. /Staffan From anthony.petrov at oracle.com Tue Aug 21 14:41:49 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 21 Aug 2012 18:41:49 +0400 Subject: jdk builds on the mac In-Reply-To: <23301E44-B548-4551-98B0-29298A68903C@oracle.com> References: <041963DD-5D06-4CDB-8E23-0FEC94DAAC1B@oracle.com> <501310E5.2070007@oracle.COM> <501F8F72.4060205@oracle.com> <50249E97.4090409@oracle.com> <4DF9482D-B0C6-48E5-84D5-C82C49C20E9E@oracle.com> <23301E44-B548-4551-98B0-29298A68903C@oracle.com> Message-ID: <50339E2D.4040309@oracle.com> This patch won't work for me. I use the following "workaround" patch instead: diff -r 8a2bc6e82d81 make/java/Makefile --- a/make/java/Makefile +++ b/make/java/Makefile @@ -58,7 +58,7 @@ endif # PLATFORM ifeq ($(PLATFORM), macosx) - SUBDIRS += jobjc +# SUBDIRS += jobjc endif # PLATFORM include $(BUILDDIR)/common/Subdirs.gmk which is way far from ideal... Is anyone working on 7191703 to resolve this issue? -- best regards, Anthony On 8/15/2012 10:30 PM, Joel Borggr?n-Franck wrote: > Well that didn't work, patch inline: > > diff -r 38263aa28324 src/macosx/native/jobjc/build.xml > --- a/src/macosx/native/jobjc/build.xml Mon Jul 30 22:32:59 2012 +0100 > +++ b/src/macosx/native/jobjc/build.xml Wed Aug 15 20:09:08 2012 +0200 > @@ -73,6 +73,10 @@ > > > > + > + > + > + > > > > @@ -115,7 +119,7 @@ > > > > - > + > > > > @@ -140,15 +144,11 @@ > > includes="**/PrimitiveCoder.java" > - includeantruntime="false"> > - > - > - > + includeantruntime="false" > + classpath="${classes}"> > > - > - > - > - > + + classpath="${classes}"> > > > > > On 15 aug 2012, at 20:17, Joel Borggr?n-Franck wrote: > >> I would't say I'm working on it. >> >> But from the department of "works for me (?)" here is a patch that sort of works for me. It might be breaking other stuff (like full forest builds), and it might not be what we want to do ... >> >> cheers >> /Joel >> >> >> >> On 10 aug 2012, at 07:39, Erik Joelsson wrote: >> >>> It does and I believe Joel, in the langtools team, is looking at this issue. >>> >>> /Erik >>> >>> On 2012-08-10 03:00, Kelly O'Hair wrote: >>>> I think we need to make sure that the only thing that gets built with the bootjdk javac is the langtools >>>> bootstrap javac.jar, all other javac compilations needs to be done by the bootstrap javac. >>>> Does that fix this issue? >>>> >>>> -kto >>>> >>>> On Aug 6, 2012, at 2:33 AM, Erik Joelsson wrote: >>>> >>>>> The classpath reference was added on my request for build-infra. The reason was to get javax.annotation.GenerateNativeHeader on the classpath. The javac used in that ant script is the bootjdk javac, which usually doesn't provide the annotation. I suppose the correct fix would be to change the ant script to use the bootstrap javac instead. >>>>> >>>>> /Erik >>>>> >>>>> On 2012-07-28 00:06, Kumar Srinivasan wrote: >>>>>> On 7/25/2012 2:23 PM, Kelly O'Hair wrote: >>>>>>> Naoto has noticed this build failure on the Mac (just the Mac) when building just the jdk repository. >>>>>>> >>>>>>> From what I can tell, the Mac build of the jdk repository now depends on the langtools repository also >>>>>>> being built, which means that partial builds of just the jdk repository will no longer work on the Mac? >>>>>>> There is an ant script at jdk/src/macosx/native/jobjc/build.xml that has a baked in classpath reference to >>>>>>> ../../langtools/dist/lib/classes.jar >>>>>>> >>>>>>> Has anyone seen this, or have any additional information on it? >>>>>> This is preventing me to test certain things I can only run from a jdk build under >>>>>> jprt on the macosx machine. >>>>>> >>>>>> Kumar >>>>>> >>>>>>> -kto >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> build-core: >>>>>>> [mkdir] Created dir: /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core >>>>>>> [javac] com/apple/jobjc/PrimitiveCoder.java added as com/apple/jobjc/PrimitiveCoder.class doesn't exist. >>>>>>> [javac] Compiling 1 source file to /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core >>>>>>> [javac] Using modern compiler >>>>>>> dropping /private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/langtools/dist/lib/classes.jar from path as it doesn't exist >>>>>>> [javac] Compilation arguments: >>>>>>> [javac] '-d' >>>>>>> [javac] '/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core' >>>>>>> [javac] '-classpath' >>>>>>> [javac] '/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core' >>>>>>> [javac] '-sourcepath' >>>>>>> [javac] '/private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java' >>>>>>> [javac] '-target' >>>>>>> [javac] '1.5' >>>>>>> [javac] '-g' >>>>>>> [javac] '-source' >>>>>>> [javac] '1.5' >>>>>>> [javac] >>>>>>> [javac] The ' characters around the executable and arguments are >>>>>>> [javac] not part of the command. >>>>>>> [javac] File to be compiled: >>>>>>> [javac] /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/PrimitiveCoder.java >>>>>>> [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.5 >>>>>>> [javac] /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java:32: warning: Unsafe is internal proprietary API and may be removed in a future release >>>>>>> [javac] import sun.misc.Unsafe; >>>>>>> [javac] ^ >>>>>>> >>>>>>> ..... >>>>>>> >>>>>>> [javac] @GenerateNativeHeader >>>>>>> [javac] ^ >>>>>>> [javac] symbol: class GenerateNativeHeader >>>>>>> [javac] Note: Some input files use unchecked or unsafe operations. >>>>>>> [javac] Note: Recompile with -Xlint:unchecked for details. >>>>>>> [javac] 61 errors >>>>>>> [javac] 7 warnings >>>>>>> >>>>>>> BUILD FAILED >>>>>>> /private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/build.xml:143: Compile failed; see the compiler error output for details. >>>>>>> at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:1079) >>>>>>> at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:882) >>>>>>> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) >>>>>>> at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) >>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>>>> at java.lang.reflect.Method.invoke(Method.java:601) >>>>>>> at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) >>>>>>> at org.apache.tools.ant.Task.perform(Task.java:348) >>>>>>> at org.apache.tools.ant.Target.execute(Target.java:357) >>>>>>> at org.apache.tools.ant.Target.performTasks(Target.java:385) >>>>>>> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) >>>>>>> at org.apache.tools.ant.Project.executeTarget(Project.java:1306) >>>>>>> at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) >>>>>>> at org.apache.tools.ant.Project.executeTargets(Project.java:1189) >>>>>>> at org.apache.tools.ant.Main.runBuild(Main.java:758) >>>>>>> at org.apache.tools.ant.Main.startAnt(Main.java:217) >>>>>>> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) >>>>>>> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) >>>>>>> >>>>>>> Total time: 1 second >>>>>>> make[2]: *** [../../../build/macosx-x86_64/JObjC.build/JObjC.jar] Error 1 >>>>>>> make[1]: *** [all] Error 1 >>>>>>> make: *** [all] Error 1 > From david.holmes at oracle.com Wed Aug 22 01:02:47 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Aug 2012 11:02:47 +1000 Subject: [7u6] Request for approval for CR 7157855: jvisualvm.1 not included in binaries In-Reply-To: <5033730A.7060700@oracle.com> References: <1860727184.8293176.1345547583143.JavaMail.root@redhat.com> <5033730A.7060700@oracle.com> Message-ID: <50342FB7.8090409@oracle.com> On 21/08/2012 9:37 PM, Se?n Coffey wrote: > Looks fine to me but best to get an official jdk8 reviewer. Looks fine to me too. > I presume the filter-out option on macosx becomes a no-op (on OpenJDK > builds) some lines later : (Images.gmk) > > 264 JDK_MAN_PAGES := $(filter-out jvisualvm.1, $(JDK_MAN_PAGES)) Yes. > On the subject of dual Makefile maintenance, are there plans to > eventually remove > the older/legacy makefile structure on 8? I haven't been monitoring that > topic too closely. Yes. At some point "real soon now" we should make the switch to using the new build system for our official builds. Some of the work for 8 is only being done in the context of the new build system. David ---- > regards, > Sean. > > On 21/08/2012 12:13, Andrew Hughes wrote: >> Ah good catch. I didn't realise this was duplicated in the new build >> system. >> >> http://cr.openjdk.java.net/~andrew/jvisualvm/webrev.02/ >> >> should deal with both cases. >> >> If this is ok, is there a preferred forest to push to? I've been >> testing against >> build, but can easily push it somewhere else. > From ahughes at redhat.com Wed Aug 22 08:30:52 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Wed, 22 Aug 2012 04:30:52 -0400 (EDT) Subject: [7u6] Request for approval for CR 7157855: jvisualvm.1 not included in binaries In-Reply-To: <50342FB7.8090409@oracle.com> Message-ID: <530167019.8872520.1345624252466.JavaMail.root@redhat.com> ----- Original Message ----- > On 21/08/2012 9:37 PM, Se?n Coffey wrote: > > Looks fine to me but best to get an official jdk8 reviewer. > > Looks fine to me too. > Thanks David. Is there a preferred tree for me to push this to? > > I presume the filter-out option on macosx becomes a no-op (on > > OpenJDK > > builds) some lines later : (Images.gmk) > > > > 264 JDK_MAN_PAGES := $(filter-out jvisualvm.1, $(JDK_MAN_PAGES)) > > Yes. > > > On the subject of dual Makefile maintenance, are there plans to > > eventually remove > > the older/legacy makefile structure on 8? I haven't been monitoring > > that > > topic too closely. > > Yes. At some point "real soon now" we should make the switch to using > the new build system for our official builds. Some of the work for 8 > is > only being done in the context of the new build system. > I need to look at moving our builds to using the new system. > David > ---- > > > regards, > > Sean. > > > > On 21/08/2012 12:13, Andrew Hughes wrote: > >> Ah good catch. I didn't realise this was duplicated in the new > >> build > >> system. > >> > >> http://cr.openjdk.java.net/~andrew/jvisualvm/webrev.02/ > >> > >> should deal with both cases. > >> > >> If this is ok, is there a preferred forest to push to? I've been > >> testing against > >> build, but can easily push it somewhere else. > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From david.holmes at oracle.com Wed Aug 22 09:29:49 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Aug 2012 19:29:49 +1000 Subject: [7u6] Request for approval for CR 7157855: jvisualvm.1 not included in binaries In-Reply-To: <530167019.8872520.1345624252466.JavaMail.root@redhat.com> References: <530167019.8872520.1345624252466.JavaMail.root@redhat.com> Message-ID: <5034A68D.7060103@oracle.com> On 22/08/2012 6:30 PM, Andrew Hughes wrote: > ----- Original Message ----- >> On 21/08/2012 9:37 PM, Se?n Coffey wrote: >>> Looks fine to me but best to get an official jdk8 reviewer. >> >> Looks fine to me too. >> > > Thanks David. Is there a preferred tree for me to push this to? Not from me. David ----- > >>> I presume the filter-out option on macosx becomes a no-op (on >>> OpenJDK >>> builds) some lines later : (Images.gmk) >>> >>> 264 JDK_MAN_PAGES := $(filter-out jvisualvm.1, $(JDK_MAN_PAGES)) >> >> Yes. >> >>> On the subject of dual Makefile maintenance, are there plans to >>> eventually remove >>> the older/legacy makefile structure on 8? I haven't been monitoring >>> that >>> topic too closely. >> >> Yes. At some point "real soon now" we should make the switch to using >> the new build system for our official builds. Some of the work for 8 >> is >> only being done in the context of the new build system. >> > > I need to look at moving our builds to using the new system. > >> David >> ---- >> >>> regards, >>> Sean. >>> >>> On 21/08/2012 12:13, Andrew Hughes wrote: >>>> Ah good catch. I didn't realise this was duplicated in the new >>>> build >>>> system. >>>> >>>> http://cr.openjdk.java.net/~andrew/jvisualvm/webrev.02/ >>>> >>>> should deal with both cases. >>>> >>>> If this is ok, is there a preferred forest to push to? I've been >>>> testing against >>>> build, but can easily push it somewhere else. >>> >> > From david.katleman at oracle.com Thu Aug 23 00:50:04 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Thu, 23 Aug 2012 00:50:04 +0000 Subject: hg: jdk8/build: Added tag jdk8-b52 for changeset 8d24def5ceb3 Message-ID: <20120823005004.734D247699@hg.openjdk.java.net> Changeset: febd7ff52800 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/febd7ff52800 Added tag jdk8-b52 for changeset 8d24def5ceb3 ! .hgtags From david.katleman at oracle.com Thu Aug 23 00:50:08 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Thu, 23 Aug 2012 00:50:08 +0000 Subject: hg: jdk8/build/corba: Added tag jdk8-b52 for changeset 80689ff9cb49 Message-ID: <20120823005009.32ECF4769A@hg.openjdk.java.net> Changeset: 63aeb7a2472f Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/63aeb7a2472f Added tag jdk8-b52 for changeset 80689ff9cb49 ! .hgtags From david.katleman at oracle.com Thu Aug 23 00:51:49 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Thu, 23 Aug 2012 00:51:49 +0000 Subject: hg: jdk8/build/hotspot: Added tag jdk8-b52 for changeset 6d0436885201 Message-ID: <20120823005152.EB9524769B@hg.openjdk.java.net> Changeset: 54240c1b8e87 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/54240c1b8e87 Added tag jdk8-b52 for changeset 6d0436885201 ! .hgtags From david.katleman at oracle.com Thu Aug 23 00:52:48 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Thu, 23 Aug 2012 00:52:48 +0000 Subject: hg: jdk8/build/jaxp: Added tag jdk8-b52 for changeset bd3c00d57614 Message-ID: <20120823005252.906794769C@hg.openjdk.java.net> Changeset: 2c566f25c39f Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/2c566f25c39f Added tag jdk8-b52 for changeset bd3c00d57614 ! .hgtags From david.katleman at oracle.com Thu Aug 23 00:52:57 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Thu, 23 Aug 2012 00:52:57 +0000 Subject: hg: jdk8/build/jaxws: Added tag jdk8-b52 for changeset f62bc618122e Message-ID: <20120823005259.AE9944769D@hg.openjdk.java.net> Changeset: 8a35fd644d3c Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/8a35fd644d3c Added tag jdk8-b52 for changeset f62bc618122e ! .hgtags From david.katleman at oracle.com Thu Aug 23 00:53:07 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Thu, 23 Aug 2012 00:53:07 +0000 Subject: hg: jdk8/build/jdk: Added tag jdk8-b52 for changeset e8569a473cee Message-ID: <20120823005318.2F5854769E@hg.openjdk.java.net> Changeset: 2c6933c5106b Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/2c6933c5106b Added tag jdk8-b52 for changeset e8569a473cee ! .hgtags From david.katleman at oracle.com Thu Aug 23 00:54:19 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Thu, 23 Aug 2012 00:54:19 +0000 Subject: hg: jdk8/build/langtools: Added tag jdk8-b52 for changeset 1d2db0e5eabc Message-ID: <20120823005421.318294769F@hg.openjdk.java.net> Changeset: d3d0b9cd76e0 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/d3d0b9cd76e0 Added tag jdk8-b52 for changeset 1d2db0e5eabc ! .hgtags From sean.coffey at oracle.com Thu Aug 23 11:24:53 2012 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Thu, 23 Aug 2012 12:24:53 +0100 Subject: [7u6] Request for approval for CR 7157855: jvisualvm.1 not included in binaries In-Reply-To: <5034A68D.7060103@oracle.com> References: <530167019.8872520.1345624252466.JavaMail.root@redhat.com> <5034A68D.7060103@oracle.com> Message-ID: <50361305.5010401@oracle.com> I haven't seen any complaints from build-dev members so I would also assume that http://hg.openjdk.java.net/jdk8/build/jdk/ is a suitable repo. I'll update bug status once I see your push. regards, Sean. On 22/08/2012 10:29, David Holmes wrote: > On 22/08/2012 6:30 PM, Andrew Hughes wrote: >> ----- Original Message ----- >>> On 21/08/2012 9:37 PM, Se?n Coffey wrote: >>>> Looks fine to me but best to get an official jdk8 reviewer. >>> >>> Looks fine to me too. >>> >> >> Thanks David. Is there a preferred tree for me to push this to? > > Not from me. > > David > ----- > >> >>>> I presume the filter-out option on macosx becomes a no-op (on >>>> OpenJDK >>>> builds) some lines later : (Images.gmk) >>>> >>>> 264 JDK_MAN_PAGES := $(filter-out jvisualvm.1, $(JDK_MAN_PAGES)) >>> >>> Yes. >>> >>>> On the subject of dual Makefile maintenance, are there plans to >>>> eventually remove >>>> the older/legacy makefile structure on 8? I haven't been monitoring >>>> that >>>> topic too closely. >>> >>> Yes. At some point "real soon now" we should make the switch to using >>> the new build system for our official builds. Some of the work for 8 >>> is >>> only being done in the context of the new build system. >>> >> >> I need to look at moving our builds to using the new system. >> >>> David >>> ---- >>> >>>> regards, >>>> Sean. >>>> >>>> On 21/08/2012 12:13, Andrew Hughes wrote: >>>>> Ah good catch. I didn't realise this was duplicated in the new >>>>> build >>>>> system. >>>>> >>>>> http://cr.openjdk.java.net/~andrew/jvisualvm/webrev.02/ >>>>> >>>>> should deal with both cases. >>>>> >>>>> If this is ok, is there a preferred forest to push to? I've been >>>>> testing against >>>>> build, but can easily push it somewhere else. >>>> >>> >> From ahughes at redhat.com Thu Aug 23 14:42:42 2012 From: ahughes at redhat.com (ahughes at redhat.com) Date: Thu, 23 Aug 2012 14:42:42 +0000 Subject: hg: jdk8/build/jdk: 7192804: Build should not install jvisualvm man page for OpenJDK Message-ID: <20120823144307.BD79B476AF@hg.openjdk.java.net> Changeset: baf30df50ce3 Author: andrew Date: 2012-08-23 15:42 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/baf30df50ce3 7192804: Build should not install jvisualvm man page for OpenJDK Summary: OpenJDK builds don't ship VisualVM so shouldn't ship its man page either. Reviewed-by: dholmes ! make/common/Release.gmk ! makefiles/Images.gmk From ahughes at redhat.com Thu Aug 23 14:45:34 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Thu, 23 Aug 2012 10:45:34 -0400 (EDT) Subject: [7u6] Request for approval for CR 7157855: jvisualvm.1 not included in binaries In-Reply-To: <50361305.5010401@oracle.com> Message-ID: <1394799206.9763021.1345733134731.JavaMail.root@redhat.com> ----- Original Message ----- > I haven't seen any complaints from build-dev members so I would also > assume > that http://hg.openjdk.java.net/jdk8/build/jdk/ is a suitable repo. > I was thinking the same. > I'll update bug status once I see your push. > There you go: http://hg.openjdk.java.net/jdk8/build/jdk/rev/baf30df50ce3 > regards, > Sean. > > On 22/08/2012 10:29, David Holmes wrote: > > On 22/08/2012 6:30 PM, Andrew Hughes wrote: > >> ----- Original Message ----- > >>> On 21/08/2012 9:37 PM, Se?n Coffey wrote: > >>>> Looks fine to me but best to get an official jdk8 reviewer. > >>> > >>> Looks fine to me too. > >>> > >> > >> Thanks David. Is there a preferred tree for me to push this to? > > > > Not from me. > > > > David > > ----- > > > >> > >>>> I presume the filter-out option on macosx becomes a no-op (on > >>>> OpenJDK > >>>> builds) some lines later : (Images.gmk) > >>>> > >>>> 264 JDK_MAN_PAGES := $(filter-out jvisualvm.1, $(JDK_MAN_PAGES)) > >>> > >>> Yes. > >>> > >>>> On the subject of dual Makefile maintenance, are there plans to > >>>> eventually remove > >>>> the older/legacy makefile structure on 8? I haven't been > >>>> monitoring > >>>> that > >>>> topic too closely. > >>> > >>> Yes. At some point "real soon now" we should make the switch to > >>> using > >>> the new build system for our official builds. Some of the work > >>> for 8 > >>> is > >>> only being done in the context of the new build system. > >>> > >> > >> I need to look at moving our builds to using the new system. > >> > >>> David > >>> ---- > >>> > >>>> regards, > >>>> Sean. > >>>> > >>>> On 21/08/2012 12:13, Andrew Hughes wrote: > >>>>> Ah good catch. I didn't realise this was duplicated in the new > >>>>> build > >>>>> system. > >>>>> > >>>>> http://cr.openjdk.java.net/~andrew/jvisualvm/webrev.02/ > >>>>> > >>>>> should deal with both cases. > >>>>> > >>>>> If this is ok, is there a preferred forest to push to? I've > >>>>> been > >>>>> testing against > >>>>> build, but can easily push it somewhere else. > >>>> > >>> > >> > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From pubuntup at gmail.com Fri Aug 24 19:30:39 2012 From: pubuntup at gmail.com (Developer Ubuntu) Date: Sat, 25 Aug 2012 01:00:39 +0530 Subject: Error building jdk7 on ubuntu 12.04 64 bit inside VirtualBox Message-ID: Hi, I am getting following error building JDK7 source. Details are added after error information. I have made both following changes one by one to overcome "OS not supported message" inside .....hotspot/make/linux/Makefile DISABLE_HOTSPOT_OS_VERSION_CHECK=ok SUPPORTED_OS_VERSION = 2.4% 2.5% 2.6% 2.7% 3.% g++ -DLINUX -D_GNU_SOURCE -DAMD64 -DPRODUCT -I. -I/Softwares/mercurialrepo/jdk7/mytl/hotspot/src/share/vm/prims -I/Softwares/mercurialrepo/jdk7/mytl/hotspot/src/share/vm -I/Softwares/mercurialrepo/jdk7/mytl/hotspot/src/cpu/x86/vm -I/Softwares/mercurialrepo/jdk7/mytl/hotspot/src/os_cpu/linux_x86/vm -I/Softwares/mercurialrepo/jdk7/mytl/hotspot/src/os/linux/vm -I/Softwares/mercurialrepo/jdk7/mytl/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"21.0-b16\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"jdkbuilder\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DJRE_RELEASE_VERSION="\"1.7.0-internal-jdkbuilder_2012_08_25_00_09-b00\"" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -O3 -fno-strict-aliasing -DVM_LITTLE_ENDIAN -D_LP64=1 -fno-omit-frame-pointer -Werror -Wpointer-arith -Wsign-compare -c -MMD -MP -MF ../generated/dependencies/precompiled.hpp.gch.d -x c++-header /Softwares/mercurialrepo/jdk7/mytl/hotspot/src/share/vm/precompiled.hpp -o precompiled.hpp.gch In file included from /Softwares/mercurialrepo/jdk7/mytl/hotspot/src/share/vm/prims/methodHandles.hpp:32:0, from /Softwares/mercurialrepo/jdk7/mytl/hotspot/src/share/vm/ci/ciMethod.hpp:33, from /Softwares/mercurialrepo/jdk7/mytl/hotspot/src/share/vm/code/debugInfoRec.hpp:30, from /Softwares/mercurialrepo/jdk7/mytl/hotspot/src/share/vm/ci/ciEnv.hpp:31, from /Softwares/mercurialrepo/jdk7/mytl/hotspot/src/share/vm/ci/ciUtilities.hpp:28, from /Softwares/mercurialrepo/jdk7/mytl/hotspot/src/share/vm/ci/ciNullObject.hpp:30, from /Softwares/mercurialrepo/jdk7/mytl/hotspot/src/share/vm/ci/ciConstant.hpp:29, from /Softwares/mercurialrepo/jdk7/mytl/hotspot/src/share/vm/precompiled.hpp:36: /Softwares/mercurialrepo/jdk7/mytl/hotspot/src/share/vm/runtime/interfaceSupport.hpp:430:0: error: "__LEAF" redefined [-Werror] /usr/include/x86_64-linux-gnu/sys/cdefs.h:44:0: note: this is the location of the previous definition cc1plus: all warnings being treated as errors make[6]: *** [precompiled.hpp.gch] Error 1 make[6]: Leaving directory `/Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/hotspot/outputdir/linux_amd64_compiler2/product' make[5]: *** [the_vm] Error 2 make[5]: Leaving directory `/Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/hotspot/outputdir/linux_amd64_compiler2/product' make[4]: *** [product] Error 2 make[4]: Leaving directory `/Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/hotspot/outputdir' make[3]: *** [generic_build2] Error 2 make[3]: Leaving directory `/Softwares/mercurialrepo/jdk7/mytl/hotspot/make' make[2]: *** [product] Error 2 make[2]: Leaving directory `/Softwares/mercurialrepo/jdk7/mytl/hotspot/make' make[1]: *** [hotspot-build] Error 2 make[1]: Leaving directory `/Softwares/mercurialrepo/jdk7/mytl' make: *** [build_product_image] Error 2 Machine info Linux jdkbuilder-VirtualBox 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux make env info ( cd ./jdk/make && \ make sanity HOTSPOT_IMPORT_CHECK=false JDK_TOPDIR=/Softwares/mercurialrepo/jdk7/mytl/jdk JDK_MAKE_SHARED_DIR=/Softwares/mercurialrepo/jdk7/mytl/jdk/make/common/shared EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-internal-root_2012_08_25_00_53-b00 PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 ALT_OUTPUTDIR=/Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64 ALT_LANGTOOLS_DIST=/Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/langtools/dist ALT_CORBA_DIST=/Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/corba/dist ALT_JAXP_DIST=/Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/jaxp/dist ALT_JAXWS_DIST=/Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/jaxws/dist ALT_HOTSPOT_IMPORT_PATH=/Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/hotspot/import BUILD_HOTSPOT=true ; ) /bin/sh: 1: [: Illegal number: /bin/sh: /bin/sh: 1: [: Illegal number: /bin/sh: /bin/sh: 1: [: Illegal number: 1: /bin/sh: 1: [: Illegal number: 1: /bin/sh: 1: [: Illegal number: /NO_BOOTDIR/bin/java: /bin/sh: 1: [: Illegal number: /NO_BOOTDIR/bin/java: /bin/sh: 1: [: Illegal number: Error: /bin/sh: 1: [: Illegal number: Error: /bin/sh: 1: [: Illegal number: JAVA_HOME /bin/sh: 1: [: Illegal number: JAVA_HOME /bin/sh: 1: [: Illegal number: is /bin/sh: 1: [: Illegal number: is make[1]: Entering directory `/Softwares/mercurialrepo/jdk7/mytl/jdk/make' make[1]: Leaving directory `/Softwares/mercurialrepo/jdk7/mytl/jdk/make' Build Machine Information: build machine = jdkbuilder-VirtualBox Build Directory Structure: CWD = /Softwares/mercurialrepo/jdk7/mytl TOPDIR = . LANGTOOLS_TOPDIR = ./langtools JAXP_TOPDIR = ./jaxp JAXWS_TOPDIR = ./jaxws CORBA_TOPDIR = ./corba HOTSPOT_TOPDIR = ./hotspot JDK_TOPDIR = ./jdk Build Directives: BUILD_LANGTOOLS = true BUILD_JAXP = true BUILD_JAXWS = true BUILD_CORBA = true BUILD_HOTSPOT = true BUILD_JDK = true DEBUG_CLASSFILES = DEBUG_BINARIES = Hotspot Settings: HOTSPOT_BUILD_JOBS = HOTSPOT_OUTPUTDIR = /Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/hotspot/outputdir HOTSPOT_EXPORT_PATH = /Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/hotspot/import Bootstrap Settings: BOOTDIR = /NO_BOOTDIR ALT_BOOTDIR = BOOT_VER = /bin/sh: 1: /NO_BOOTDIR/bin/java: not found [requires at least 1.6] OUTPUTDIR = /Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64 ALT_OUTPUTDIR = /Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64 ABS_OUTPUTDIR = /Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64 Build Tool Settings: SLASH_JAVA = /NOT-SET ALT_SLASH_JAVA = VARIANT = OPT JDK_DEVTOOLS_DIR = /NOT-SET/devtools ALT_JDK_DEVTOOLS_DIR = ANT_HOME = UNIXCOMMAND_PATH = /bin/ ALT_UNIXCOMMAND_PATH = COMPILER_PATH = /usr/bin/ ALT_COMPILER_PATH = DEVTOOLS_PATH = /usr/bin/ ALT_DEVTOOLS_PATH = UNIXCCS_PATH = /usr/ccs/bin/ ALT_UNIXCCS_PATH = USRBIN_PATH = /usr/bin/ ALT_USRBIN_PATH = COMPILER_NAME = GCC4 COMPILER_VERSION = GCC4 CC_VER = 4.6 [requires at least 4.3.0] ZIP_VER = 3.0 [requires at least 2.2] UNZIP_VER = 6.00 [requires at least 5.12] ANT_VER = Error: JAVA_HOME is not defined correctly. We cannot execute /NO_BOOTDIR/bin/java [requires at least 1.7.1] TEMPDIR = /Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/tmp Build Directives: OPENJDK = true USE_HOTSPOT_INTERPRETER_MODE = PEDANTIC = DEV_ONLY = NO_DOCS = NO_IMAGES = TOOLS_ONLY = INSANE = COMPILE_APPROACH = parallel PARALLEL_COMPILE_JOBS = 2 ALT_PARALLEL_COMPILE_JOBS = FASTDEBUG = COMPILER_WARNINGS_FATAL = false COMPILER_WARNING_LEVEL = SHOW_ALL_WARNINGS = INCREMENTAL_BUILD = false CC_HIGHEST_OPT = CC_HIGHER_OPT = CC_LOWER_OPT = CXXFLAGS = -O2 -fPIC -DCC_NOEX -W -Wall -Wno-unused -Wno-parentheses -fno-omit-frame-pointer -D_LITTLE_ENDIAN CFLAGS = -O2 -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses -pipe -fno-omit-frame-pointer -D_LITTLE_ENDIAN BOOT_JAVA_CMD = /NO_BOOTDIR/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m BOOT_JAVAC_CMD = /NO_BOOTDIR/bin/javac -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6 -XDignore.symbol.file=true BOOT_JAR_CMD = /NO_BOOTDIR/bin/jar BOOT_JARSIGNER_CMD = /NO_BOOTDIR/bin/jarsigner JAVAC_CMD = /NO_BOOTDIR/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m -Xbootclasspath/p:/Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/langtools/dist/bootstrap/lib/javac.jar -jar /Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/langtools/dist/bootstrap/lib/javac.jar -source 7 -target 7 -encoding ascii -Xbootclasspath:/Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/classes JAVAH_CMD = /NO_BOOTDIR/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m -Xbootclasspath/p:/Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/langtools/dist/bootstrap/lib/javah.jar:/Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/langtools/dist/bootstrap/lib/javac.jar -jar /Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/langtools/dist/bootstrap/lib/javah.jar -bootclasspath /Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/classes JAVADOC_CMD = /NO_BOOTDIR/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m -Xbootclasspath/p:/Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/langtools/dist/bootstrap/lib/javadoc.jar:/Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/langtools/dist/bootstrap/lib/javac.jar:/Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/langtools/dist/bootstrap/lib/doclets.jar -jar /Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/langtools/dist/bootstrap/lib/javadoc.jar -bootclasspath /Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/classes Build Platform Settings: USER = root PLATFORM = linux ARCH = amd64 LIBARCH = amd64 ARCH_FAMILY = amd64 ARCH_DATA_MODEL = 64 ARCHPROP = amd64 ALSA_VERSION = 1.0.25 OS_VERSION = 3.2.0-29-generic [requires at least 2.6] OS_VARIANT_NAME = Ubuntu OS_VARIANT_VERSION = 12.04 MB_OF_MEMORY = 2003 GNU Make Settings: MAKE = make MAKE_VER = 3.81 [requires at least 3.81] MAKECMDGOALS = sanity MAKEFLAGS = w SHELL = /bin/sh Target Build Versions: JDK_VERSION = 1.7.0 MILESTONE = internal RELEASE = 1.7.0-internal FULL_VERSION = 1.7.0-internal-root_2012_08_25_00_53-b00 BUILD_NUMBER = b00 External File/Binary Locations: USRJDKINSTANCES_PATH = /opt/java BUILD_JDK_IMPORT_PATH = /NOT-SET/re/jdk/1.7.0/promoted/latest/binaries ALT_BUILD_JDK_IMPORT_PATH = JDK_IMPORT_PATH = /NOT-SET/re/jdk/1.7.0/promoted/latest/binaries/linux-amd64 ALT_JDK_IMPORT_PATH = LANGTOOLS_DIST = /Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/langtools/dist ALT_LANGTOOLS_DIST = /Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/langtools/dist CORBA_DIST = /Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/corba/dist ALT_CORBA_DIST = /Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/corba/dist JAXP_DIST = /Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/jaxp/dist ALT_JAXP_DIST = /Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/jaxp/dist JAXWS_DIST = /Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/jaxws/dist ALT_JAXWS_DIST = /Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/jaxws/dist HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR ALT_HOTSPOT_DOCS_IMPORT_PATH = HOTSPOT_IMPORT_PATH = /Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/hotspot/import ALT_HOTSPOT_IMPORT_PATH = /Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/hotspot/import HOTSPOT_SERVER_PATH = /Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/hotspot/import/jre/lib/amd64/server ALT_HOTSPOT_SERVER_PATH = CACERTS_FILE = ./../src/share/lib/security/cacerts ALT_CACERTS_FILE = CUPS_HEADERS_PATH = /usr/include ALT_CUPS_HEADERS_PATH = OpenJDK-specific settings: FREETYPE_HEADERS_PATH = /usr/include ALT_FREETYPE_HEADERS_PATH = FREETYPE_LIB_PATH = /usr/lib ALT_FREETYPE_LIB_PATH = Previous JDK Settings: PREVIOUS_RELEASE_PATH = ALT_PREVIOUS_RELEASE_PATH = PREVIOUS_JDK_VERSION = 1.6.0 ALT_PREVIOUS_JDK_VERSION = PREVIOUS_JDK_FILE = ALT_PREVIOUS_JDK_FILE = PREVIOUS_JRE_FILE = ALT_PREVIOUS_JRE_FILE = PREVIOUS_RELEASE_IMAGE = ALT_PREVIOUS_RELEASE_IMAGE = Sanity check passed From omajid at redhat.com Fri Aug 24 21:59:04 2012 From: omajid at redhat.com (Omair Majid) Date: Fri, 24 Aug 2012 17:59:04 -0400 Subject: Error building jdk7 on ubuntu 12.04 64 bit inside VirtualBox In-Reply-To: References: Message-ID: <5037F928.7080404@redhat.com> Hi, On 08/24/2012 03:30 PM, Developer Ubuntu wrote: > Hi, > I am getting following error building JDK7 source. It looks like you are trying to build hg.openjdk.java.net/jdk7/tl/. That's very out-of-date. Most of the problems you have mentioned here are fixed in the jdk7u (the u is for updates) forest. Try http://hg.openjdk.java.net/jdk7u/jdk7u6 instead. > Details are added after > error information. I have made both following changes one by one to > overcome "OS not supported message" inside .....hotspot/make/linux/Makefile > DISABLE_HOTSPOT_OS_VERSION_CHECK=ok > SUPPORTED_OS_VERSION = 2.4% 2.5% 2.6% 2.7% 3.% This was fixed with: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ca1f1753c866 > g++ -DLINUX -D_GNU_SOURCE -DAMD64 -DPRODUCT -I. > -I/Softwares/mercurialrepo/jdk7/mytl/hotspot/src/share/vm/prims > -I/Softwares/mercurialrepo/jdk7/mytl/hotspot/src/share/vm > -I/Softwares/mercurialrepo/jdk7/mytl/hotspot/src/cpu/x86/vm > -I/Softwares/mercurialrepo/jdk7/mytl/hotspot/src/os_cpu/linux_x86/vm > -I/Softwares/mercurialrepo/jdk7/mytl/hotspot/src/os/linux/vm > -I/Softwares/mercurialrepo/jdk7/mytl/hotspot/src/os/posix/vm -I../generated > -DHOTSPOT_RELEASE_VERSION="\"21.0-b16\"" > -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"jdkbuilder\"" > -DHOTSPOT_LIB_ARCH=\"amd64\" > -DJRE_RELEASE_VERSION="\"1.7.0-internal-jdkbuilder_2012_08_25_00_09-b00\"" > -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux > -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_linux_x86 > -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 > -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new > -fvisibility=hidden -m64 -pipe -O3 -fno-strict-aliasing -DVM_LITTLE_ENDIAN > -D_LP64=1 -fno-omit-frame-pointer -Werror -Wpointer-arith -Wsign-compare > -c -MMD -MP -MF ../generated/dependencies/precompiled.hpp.gch.d -x > c++-header > /Softwares/mercurialrepo/jdk7/mytl/hotspot/src/share/vm/precompiled.hpp -o > precompiled.hpp.gch > In file included from > /Softwares/mercurialrepo/jdk7/mytl/hotspot/src/share/vm/prims/methodHandles.hpp:32:0, > from > /Softwares/mercurialrepo/jdk7/mytl/hotspot/src/share/vm/ci/ciMethod.hpp:33, > from > /Softwares/mercurialrepo/jdk7/mytl/hotspot/src/share/vm/code/debugInfoRec.hpp:30, > from > /Softwares/mercurialrepo/jdk7/mytl/hotspot/src/share/vm/ci/ciEnv.hpp:31, > from > /Softwares/mercurialrepo/jdk7/mytl/hotspot/src/share/vm/ci/ciUtilities.hpp:28, > from > /Softwares/mercurialrepo/jdk7/mytl/hotspot/src/share/vm/ci/ciNullObject.hpp:30, > from > /Softwares/mercurialrepo/jdk7/mytl/hotspot/src/share/vm/ci/ciConstant.hpp:29, > from > /Softwares/mercurialrepo/jdk7/mytl/hotspot/src/share/vm/precompiled.hpp:36: > /Softwares/mercurialrepo/jdk7/mytl/hotspot/src/share/vm/runtime/interfaceSupport.hpp:430:0: > error: "__LEAF" redefined [-Werror] > /usr/include/x86_64-linux-gnu/sys/cdefs.h:44:0: note: this is the location > of the previous definition > cc1plus: all warnings being treated as errors > make[6]: *** [precompiled.hpp.gch] Error 1 > make[6]: Leaving directory > `/Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/hotspot/outputdir/linux_amd64_compiler2/product' > make[5]: *** [the_vm] Error 2 > make[5]: Leaving directory > `/Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/hotspot/outputdir/linux_amd64_compiler2/product' > make[4]: *** [product] Error 2 > make[4]: Leaving directory > `/Softwares/mercurialrepo/jdk7/mytl/build/linux-amd64/hotspot/outputdir' > make[3]: *** [generic_build2] Error 2 > make[3]: Leaving directory `/Softwares/mercurialrepo/jdk7/mytl/hotspot/make' > make[2]: *** [product] Error 2 > make[2]: Leaving directory `/Softwares/mercurialrepo/jdk7/mytl/hotspot/make' > make[1]: *** [hotspot-build] Error 2 > make[1]: Leaving directory `/Softwares/mercurialrepo/jdk7/mytl' > make: *** [build_product_image] Error 2 > Fixed with: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a6eef545f1a2 Cheers, Omair From david.holmes at oracle.com Wed Aug 29 06:21:31 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Aug 2012 16:21:31 +1000 Subject: debuginfo/diz files Message-ID: <503DB4EB.1060106@oracle.com> As far as I can see the .debuginfo/.diz files don't get kept together with their native library counterpart. For example only the JDK contains libsaproc.so and libattach.so but the JRE image contains libsaproc.diz and libattach.diz. Is this a known issue? I see it in my build-infra builds but I suspect build-infra just mirrors what happens in the old build. I don't have an old build available to check and promoted builds have the diz files tripped from them. AFAICS diz files get copied by accident as part of the generic copying routines, but if a .so is excluded there is no corresponding rule to exclude the .diz. David From ahughes at redhat.com Wed Aug 29 13:12:20 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Wed, 29 Aug 2012 09:12:20 -0400 (EDT) Subject: OpenJDK 7u and Fedora 17 In-Reply-To: <503E0E54.209@oracle.com> Message-ID: <584007461.12526719.1346245940339.JavaMail.root@redhat.com> ----- Original Message ----- > On 8/29/12 1:56 PM, Henri Gomez wrote: > > Shouldn't it be general case for OpenJDK on Linux to use dynamic > > linking with stdc++ like all others libs ? > > For 7 updates? Probably not. > > See http://markmail.org/message/yqexkr4ty7s4gelz for details. As > Kelly > said then "It is quite possible that we don't need to static link > anything > anymore, but that would need to be verified." > > Not worth the bother from my POV, as it's > > a) not a bug - it's the intended behavior, > b) those who desire not to statically link with libsdtc++ can do so > easily, > c) it would have to be done and verified on 8 first, and > d) 8 is getting a new build system anyway > > So, in short, there is not much of a point in changing it here now. > The OpenJDK packages in most distributions have been turning off static linking for years. What more verification is needed? To respond to your points, a) I presume you mean Oracle's intended behaviour. Most developers on GNU/Linux would not expect static linking to be taking place, as it's not the norm. b) This assumes they are a) aware it is happening in the first place and b) know how to turn it off. Neither are that obvious, IMHO. I believe we turned it off initially but then spotted it had regressed again, because Fedora moved the static library into its own package. It's easier for Oracle to turn ON static linking for their packages, than it is to for users new to OpenJDK to know to install a non-standard package. c) This I agree with. I hadn't realised it was being discussed on 7u and not build-dev (now CCed). d) I believe the new build system is copying verbatim from the old one at present, and comparing resulting images, so I don't see it changing as a result of that. I think the general issue here is we need to consider whether the build defaults should remain suited to producing proprietary binaries for Oracle, as they have previously, or whether they should instead fit the expected "norm" on the appropriate platform (i.e. how the majority of other packages do it). One of the hurdles in attracting new developers to OpenJDK is the ease of initial builds. I think a good aim would be to have it buildable by a simple "configure; make" on a standard install, without having to install a mass of non-standard packages or set lots of options. > cheers, > dalibor topic > -- > Oracle > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > Oracle Java Platform Group > > ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > Gesch?ftsf?hrer: J?rgen Kunz > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > Green Oracle Oracle is committed > to developing practices and products that help protect the > environment > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From henri.gomez at gmail.com Wed Aug 29 13:28:32 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 29 Aug 2012 15:28:32 +0200 Subject: OpenJDK 7u and Fedora 17 In-Reply-To: <584007461.12526719.1346245940339.JavaMail.root@redhat.com> References: <503E0E54.209@oracle.com> <584007461.12526719.1346245940339.JavaMail.root@redhat.com> Message-ID: I understand you both :-) Andrew, as distro packager, is rebuilding OpenJDK and package it for distros he maintain. So he's sure that stdlibc++ used at runtime will be same as one at build time and he could even mandate it in its RPM spec file so it will be installed by yum if not available. For Oracle, where a binary should match cross distros, there is no such way to ensure it, hence the static linking, if stdlibc++ is a piece of "moving" code. Not a big deal but it should be mentioned somewhere in build documentation so packagers could do their own choices. >> For 7 updates? Probably not. >> >> See http://markmail.org/message/yqexkr4ty7s4gelz for details. As >> Kelly >> said then "It is quite possible that we don't need to static link >> anything >> anymore, but that would need to be verified." >> >> Not worth the bother from my POV, as it's >> >> a) not a bug - it's the intended behavior, >> b) those who desire not to statically link with libsdtc++ can do so >> easily, >> c) it would have to be done and verified on 8 first, and >> d) 8 is getting a new build system anyway >> >> So, in short, there is not much of a point in changing it here now. >> > > The OpenJDK packages in most distributions have been turning off static > linking for years. What more verification is needed? > > To respond to your points, > > a) I presume you mean Oracle's intended behaviour. Most developers on GNU/Linux would > not expect static linking to be taking place, as it's not the norm. > b) This assumes they are a) aware it is happening in the first place and b) > know how to turn it off. Neither are that obvious, IMHO. I believe we > turned it off initially but then spotted it had regressed again, because > Fedora moved the static library into its own package. It's easier > for Oracle to turn ON static linking for their packages, than it is to > for users new to OpenJDK to know to install a non-standard package. > c) This I agree with. I hadn't realised it was being discussed on 7u and > not build-dev (now CCed). > d) I believe the new build system is copying verbatim from the old one > at present, and comparing resulting images, so I don't see it changing > as a result of that. > > I think the general issue here is we need to consider whether the build defaults > should remain suited to producing proprietary binaries for Oracle, as they have previously, > or whether they should instead fit the expected "norm" on the appropriate platform (i.e. how > the majority of other packages do it). One of the hurdles in attracting > new developers to OpenJDK is the ease of initial builds. I think a good aim > would be to have it buildable by a simple "configure; make" on a standard install, > without having to install a mass of non-standard packages or set lots of options. From ahughes at redhat.com Wed Aug 29 14:29:47 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Wed, 29 Aug 2012 10:29:47 -0400 (EDT) Subject: OpenJDK 7u and Fedora 17 In-Reply-To: Message-ID: <1893471737.12596884.1346250587662.JavaMail.root@redhat.com> ----- Original Message ----- > I understand you both :-) > > Andrew, as distro packager, is rebuilding OpenJDK and package it for > distros he maintain. > > So he's sure that stdlibc++ used at runtime will be same as one at > build time and he could even mandate it in its RPM spec file so it > will be installed by yum if not available. > I'm not just a distro packager, but maintainer of IcedTea and an OpenJDK reviewer. Most distros (Debian & Ubuntu AFAIK, Gentoo, Fedora & RHEL for 6 only) use this and thus the build settings it uses. STATIC_CXX=false has been set since at least March 2011. I believe it was disabled by a patch before that but upstream changes meant the patch didn't work any more. Your general point is correct, but I think the issue is wider than just distro packages. Pretty much everything one would build on a GNU/Linux system links dynamically, so, in linking statically, OpenJDK is unusual. Unless the user knows that static linking is taking place, they wouldn't expect it. This is demonstrated by the Fedora issue you experienced; static libstdc++ linking is so uncommon, the library is in a package on its own so it's not pulled in unless explicitly requested. > For Oracle, where a binary should match cross distros, there is no > such way to ensure it, hence the static linking, if stdlibc++ is a > piece of "moving" code. > Indeed. This is also why in-tree versions of zlib, lcms, libpng, giflib and libjpeg are used, whereas we use system versions. > Not a big deal but it should be mentioned somewhere in build > documentation so packagers could do their own choices. It's a pretty big deal if it means someone can't build. That could effectively dissuade them from getting involved in OpenJDK. > > >> For 7 updates? Probably not. > >> > >> See http://markmail.org/message/yqexkr4ty7s4gelz for details. As > >> Kelly > >> said then "It is quite possible that we don't need to static link > >> anything > >> anymore, but that would need to be verified." > >> > >> Not worth the bother from my POV, as it's > >> > >> a) not a bug - it's the intended behavior, > >> b) those who desire not to statically link with libsdtc++ can do > >> so > >> easily, > >> c) it would have to be done and verified on 8 first, and > >> d) 8 is getting a new build system anyway > >> > >> So, in short, there is not much of a point in changing it here > >> now. > >> > > > > The OpenJDK packages in most distributions have been turning off > > static > > linking for years. What more verification is needed? > > > > To respond to your points, > > > > a) I presume you mean Oracle's intended behaviour. Most developers > > on GNU/Linux would > > not expect static linking to be taking place, as it's not the norm. > > b) This assumes they are a) aware it is happening in the first > > place and b) > > know how to turn it off. Neither are that obvious, IMHO. I > > believe we > > turned it off initially but then spotted it had regressed again, > > because > > Fedora moved the static library into its own package. It's easier > > for Oracle to turn ON static linking for their packages, than it is > > to > > for users new to OpenJDK to know to install a non-standard package. > > c) This I agree with. I hadn't realised it was being discussed on > > 7u and > > not build-dev (now CCed). > > d) I believe the new build system is copying verbatim from the old > > one > > at present, and comparing resulting images, so I don't see it > > changing > > as a result of that. > > > > I think the general issue here is we need to consider whether the > > build defaults > > should remain suited to producing proprietary binaries for Oracle, > > as they have previously, > > or whether they should instead fit the expected "norm" on the > > appropriate platform (i.e. how > > the majority of other packages do it). One of the hurdles in > > attracting > > new developers to OpenJDK is the ease of initial builds. I think > > a good aim > > would be to have it buildable by a simple "configure; make" on a > > standard install, > > without having to install a mass of non-standard packages or set > > lots of options. > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From david.katleman at oracle.com Wed Aug 29 22:54:59 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 29 Aug 2012 22:54:59 +0000 Subject: hg: jdk8/build: Added tag jdk8-b53 for changeset febd7ff52800 Message-ID: <20120829225459.77D6F477D4@hg.openjdk.java.net> Changeset: c1a277c6022a Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/c1a277c6022a Added tag jdk8-b53 for changeset febd7ff52800 ! .hgtags From david.katleman at oracle.com Wed Aug 29 22:55:03 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 29 Aug 2012 22:55:03 +0000 Subject: hg: jdk8/build/corba: Added tag jdk8-b53 for changeset 63aeb7a2472f Message-ID: <20120829225505.A29AC477D5@hg.openjdk.java.net> Changeset: 16c82fc74695 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/16c82fc74695 Added tag jdk8-b53 for changeset 63aeb7a2472f ! .hgtags From david.katleman at oracle.com Wed Aug 29 22:56:27 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 29 Aug 2012 22:56:27 +0000 Subject: hg: jdk8/build/hotspot: 32 new changesets Message-ID: <20120829225736.470CB477D6@hg.openjdk.java.net> Changeset: de2aa86e037d Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/de2aa86e037d Added tag jdk8-b53 for changeset 54240c1b8e87 ! .hgtags Changeset: 6898d85cf0bb Author: amurillo Date: 2012-08-10 23:19 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6898d85cf0bb 7190772: new hotspot build - hs24-b21 Reviewed-by: jcoomes ! make/hotspot_version Changeset: d5ec46c7da5c Author: amurillo Date: 2012-08-15 16:49 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d5ec46c7da5c 7191765: make jdk8 the default jprt release for hs24 Reviewed-by: jcoomes ! make/jprt.properties Changeset: aaf61e68b255 Author: johnc Date: 2012-08-06 12:20 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/aaf61e68b255 6818524: G1: use ergonomic resizing of PLABs Summary: Employ PLABStats instances to record information about survivor and old PLABs, and use the recorded stats to adjust the sizes of survivor and old PLABS. Reviewed-by: johnc, ysr Contributed-by: Brandon Mitchell ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp + src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp + src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/precompiled/precompiled.hpp Changeset: eff5d59db7e1 Author: amurillo Date: 2012-08-07 09:53 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/eff5d59db7e1 7189729: jprt.properties should include release jdk7u8 Reviewed-by: jcoomes ! make/jprt.properties Changeset: 3958f0acde31 Author: amurillo Date: 2012-08-17 15:41 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3958f0acde31 Merge ! make/jprt.properties - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp Changeset: 6acee021f5ac Author: coleenp Date: 2012-08-01 16:52 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6acee021f5ac 7129723: MAC: Some regression tests need to recognize Mac OS X platform Summary: Add Darwin like Linux to shell scripts Reviewed-by: kvn, kamg, dholmes ! test/compiler/6894807/Test6894807.sh ! test/gc/6941923/test6941923.sh ! test/runtime/6626217/Test6626217.sh ! test/runtime/6878713/Test6878713.sh ! test/runtime/6929067/Test6929067.sh ! test/runtime/7051189/Xchecksig.sh ! test/runtime/7110720/Test7110720.sh ! test/runtime/7158800/Test7158800.sh ! test/runtime/7158988/TestFieldMonitor.sh Changeset: 4acebbe310e1 Author: zgu Date: 2012-08-01 17:19 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4acebbe310e1 7185614: NMT ON: "check by caller" assertion failed on nsk ThreadMXBean test 7187429: NMT ON: Merge failure should cause NMT to shutdown Summary: Fixed NMT assertion failures Reviewed-by: acorn, kvn ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTracker.hpp Changeset: b27675afea11 Author: zgu Date: 2012-08-01 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b27675afea11 Merge Changeset: 8e69438de9c6 Author: zgu Date: 2012-08-01 16:16 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8e69438de9c6 Merge Changeset: 282abd0fd878 Author: dcubed Date: 2012-08-02 14:54 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/282abd0fd878 7188168: 7071904 broke the DEBUG_BINARIES option on Linux Summary: Change DEBUG_BINARIES option logic to be more clear. Reviewed-by: fparain, andrew ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make Changeset: 0d8e265ba727 Author: dcubed Date: 2012-08-03 18:34 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/0d8e265ba727 7181175: Enable builds on Windows with MinGW/MSYS Summary: This fix is the minimum number of Makefile changes to enable building HotSpot with MinGW/MSYS Reviewed-by: jcoomes, dcubed, tbell, ohair Contributed-by: volker.simonis at gmail.com ! make/windows/makefiles/defs.make ! make/windows/makefiles/rules.make ! make/windows/makefiles/sa.make ! make/windows/makefiles/shared.make Changeset: c3c2141203e7 Author: dcubed Date: 2012-08-06 09:34 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c3c2141203e7 Merge Changeset: 4ee06e614636 Author: kamg Date: 2012-08-06 15:54 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4ee06e614636 7116786: RFE: Detailed information on VerifyErrors Summary: Provide additional detail in VerifyError messages Reviewed-by: sspitsyn, acorn ! src/os/solaris/vm/dtraceJSDT_solaris.cpp ! src/share/vm/classfile/stackMapFrame.cpp ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/classfile/stackMapTable.cpp ! src/share/vm/classfile/stackMapTable.hpp ! src/share/vm/classfile/stackMapTableFormat.hpp ! src/share/vm/classfile/verificationType.cpp ! src/share/vm/classfile/verificationType.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/relocator.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp + test/runtime/7116786/Test7116786.java + test/runtime/7116786/testcases.jar Changeset: 98625323d3a3 Author: tbell Date: 2012-08-10 23:16 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/98625323d3a3 7190512: Fix for 7181175 broke hotspot/make/windows/create.bat builds Summary: Add some quotes around the classpath in the project file rule. Reviewed-by: dcubed ! make/windows/projectfiles/common/Makefile Changeset: e5bf1c79ed5b Author: zgu Date: 2012-08-14 13:56 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e5bf1c79ed5b 7191124: Optimized build is broken due to inconsistent use of DEBUG_ONLY and NOT_PRODUCT macros in NMT Summary: Updated all related variables and methods to use NOT_PRODUCT macros Reviewed-by: coleenp, acorn, kvn ! src/share/vm/services/memPtr.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memPtrArray.hpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memTracker.cpp Changeset: fce6d7280776 Author: dcubed Date: 2012-08-17 11:57 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/fce6d7280776 Merge ! src/share/vm/classfile/verifier.cpp ! src/share/vm/runtime/globals.hpp Changeset: b63c0564035a Author: dcubed Date: 2012-08-21 19:25 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b63c0564035a Merge Changeset: f99a36499b8c Author: johnc Date: 2012-08-21 10:05 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f99a36499b8c 7192128: G1: Extend fix for 6948537 to G1's BOT Summary: G1 does not appear to be immune to the issue described in CR 6948537 and increasing the size of old-generation PLABs appears to increase the liklihood of seeing the issue. Extend the fix for 6948537 to G1's BlockOffsetTable. Reviewed-by: brutisso, jmasa ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 7383557659bd Author: johnc Date: 2012-08-21 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7383557659bd 7185699: G1: Prediction model discrepancies Summary: Correct the result value of G1CollectedHeap::pending_card_num(). Change the code that calculates the GC efficiency of a non-young heap region to use historical data from mixed GCs and the actual number of live bytes when predicting how long it would take to collect the region. Changes were also reviewed by Thomas Schatzl. Reviewed-by: azeemj, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 3650da95d2ee Author: brutisso Date: 2012-08-23 05:25 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3650da95d2ee 7193157: G1: Make some develpflags available in product builds Summary: Also reviewed by: vitalyd at gmail.com. Make G1DefaultMinNewGenPercent, G1DefaultMaxNewGenPercent, G1OldCSetRegionLiveThresholdPercent and G1OldCSetRegionThresholdPercent experimental flags Reviewed-by: ysr, johnc, jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: ce0254b13eb8 Author: brutisso Date: 2012-08-24 09:45 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ce0254b13eb8 Merge Changeset: 006050192a5a Author: kvn Date: 2012-08-20 09:07 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/006050192a5a 6340864: Implement vectorization optimizations in hotspot-server Summary: Added asm encoding and mach nodes for vector arithmetic instructions on x86. Reviewed-by: roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp + test/compiler/6340864/TestByteVect.java + test/compiler/6340864/TestDoubleVect.java + test/compiler/6340864/TestFloatVect.java + test/compiler/6340864/TestIntVect.java + test/compiler/6340864/TestLongVect.java + test/compiler/6340864/TestShortVect.java Changeset: 09aad8452938 Author: kvn Date: 2012-08-20 09:58 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/09aad8452938 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops Summary: In C2 add software membar after load from Reference.referent field to prevent commoning of loads across safepoint since GC can change its value. In C1 always generate Reference.get() intrinsic. Reviewed-by: roland, twisti, dholmes, johnc ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/library_call.cpp + test/compiler/7190310/Test7190310.java + test/compiler/7190310/Test7190310_unsafe.java Changeset: 7a302948f5a4 Author: twisti Date: 2012-08-21 10:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7a302948f5a4 7192167: JSR 292: C1 has old broken code which needs to be removed Reviewed-by: kvn, roland, jrose ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/opto/callGenerator.cpp Changeset: 4b0d6fd74911 Author: kvn Date: 2012-08-21 14:50 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4b0d6fd74911 7192964: assert(false) failed: bad AD file Summary: Shifts with loop variant counts "a[i]=1<= 1) failed: illegal call to offset() Summary: C1 value numbering hits unloaded klass. Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_ValueMap.cpp ! src/share/vm/c1/c1_ValueMap.hpp Changeset: 5af51c882207 Author: kvn Date: 2012-08-22 11:55 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5af51c882207 7192963: assert(_in[req-1] == this) failed: Must pass arg count to 'new' Summary: Fixed Pack node generation. Not vectorize shift instructions if count is not the same for all shifts and if count is vector. Reviewed-by: twisti ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp + test/compiler/7192963/TestByteVect.java + test/compiler/7192963/TestDoubleVect.java + test/compiler/7192963/TestFloatVect.java + test/compiler/7192963/TestIntVect.java + test/compiler/7192963/TestLongVect.java + test/compiler/7192963/TestShortVect.java Changeset: f7cd53cedd78 Author: kvn Date: 2012-08-23 09:13 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f7cd53cedd78 7192965: assert(is_aligned_sets(size)) failed: mask is not aligned, adjacent sets Summary: Change pair check to vector check in RA bias coloring code. Reviewed-by: jrose, twisti ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/output.cpp Changeset: c32dee9b8023 Author: twisti Date: 2012-08-24 11:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c32dee9b8023 Merge Changeset: 9e3ae661284d Author: amurillo Date: 2012-08-24 15:51 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9e3ae661284d Merge - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp Changeset: e8fb566b9466 Author: amurillo Date: 2012-08-24 15:51 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e8fb566b9466 Added tag hs24-b21 for changeset 9e3ae661284d ! .hgtags From david.katleman at oracle.com Wed Aug 29 22:58:40 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 29 Aug 2012 22:58:40 +0000 Subject: hg: jdk8/build/jaxp: Added tag jdk8-b53 for changeset 2c566f25c39f Message-ID: <20120829225845.8F029477D7@hg.openjdk.java.net> Changeset: 7dd81ccb7c11 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/7dd81ccb7c11 Added tag jdk8-b53 for changeset 2c566f25c39f ! .hgtags From david.katleman at oracle.com Wed Aug 29 22:58:51 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 29 Aug 2012 22:58:51 +0000 Subject: hg: jdk8/build/jaxws: Added tag jdk8-b53 for changeset 8a35fd644d3c Message-ID: <20120829225855.D9270477D8@hg.openjdk.java.net> Changeset: 91970935926a Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/91970935926a Added tag jdk8-b53 for changeset 8a35fd644d3c ! .hgtags From david.katleman at oracle.com Wed Aug 29 22:59:04 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 29 Aug 2012 22:59:04 +0000 Subject: hg: jdk8/build/jdk: 2 new changesets Message-ID: <20120829225937.C90D2477D9@hg.openjdk.java.net> Changeset: 156ab3c38556 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/156ab3c38556 Added tag jdk8-b53 for changeset 2c6933c5106b ! .hgtags Changeset: 70ad0ed1d6ce Author: katleman Date: 2012-08-29 15:28 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/70ad0ed1d6ce Merge From david.katleman at oracle.com Wed Aug 29 23:00:56 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 29 Aug 2012 23:00:56 +0000 Subject: hg: jdk8/build/langtools: Added tag jdk8-b53 for changeset d3d0b9cd76e0 Message-ID: <20120829230102.BEE1A477DA@hg.openjdk.java.net> Changeset: 9cf72631baf5 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/9cf72631baf5 Added tag jdk8-b53 for changeset d3d0b9cd76e0 ! .hgtags