From erik.joelsson at oracle.com  Thu Nov  1 01:49:49 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 01 Nov 2012 09:49:49 +0100
Subject: Solaris compiler setup ?
In-Reply-To: <5091F932.3060806@oracle.com>
References: <1956549788.2474283.1344512172984.JavaMail.root@redhat.com>	<502433EC.5010400@oracle.com>
	<505278E5.1050108@oracle.com>	<8348E4DE-157B-4A68-96AA-22B865688807@oracle.com>	<508603EF.105@oracle.com>
	<508A6233.7070207@oracle.com>	<508A7153.7090503@oracle.com>
	<508AA008.1080905@oracle.com>	<508EDB7B.40905@oracle.com>
	<5091F932.3060806@oracle.com>
Message-ID: <509237AD.1010907@oracle.com>

Yes, I've noticed this too since this is how I always configure, but was 
already busy with too many parallel threads of development to fix it 
right away. Workaround is to touch spec.gmk and then run configure. I 
will go fix it now.

/Erik

On 2012-11-01 05:23, David Holmes wrote:
> On 30/10/2012 5:39 AM, Magnus Ihse Bursie wrote:
>> On 2012-10-26 16:36, Magnus Ihse Bursie wrote:
>>>> Pretty sure I don't need objective-C on Solaris :-)
>>> I have a fix for that already. :-) But I'll want to double check that
>>> on our test systems before I push it, so I don't put the current
>>> integration in jeopardy.
>>
>> I forgot to push that fix. Done now.
>>
>> How far do you get this time? :-)
>
> Not too far :(
>
> checking for mozilla headers in /java... /java/devtools/share/plugin
> checking for devtools path in /java... /java/devtools/i386/bin
> checking for GCC compiler path in /java... /java/devtools/i386/gnucc/bin
> configure: Current directory is 
> /java/embedded/users/dh198349/build-infra/builds/b01/se-solaris-i586-ea.
> configure: Since this is not the source root, configure will output 
> the configuration here
> configure: (as opposed to creating a configuration in 
> <src_root>/build/<conf-name>).
> configure: However, this directory is not empty. This is not allowed, 
> since it could
> configure: seriously mess up just about everything.
> configure: Try 'cd /java/embedded/users/dh198349/build-infra' and 
> restart configure
> configure: (or create a new empty directory and cd to it).
> configure: error: Will not continue creating configuration in 
> /java/embedded/users/dh198349/build-infra/builds/b01/se-solaris-i586-ea
> configure exiting with result code 1
>
> ---
>
> > ls -l b01/se-solaris-i586-ea
> total 40
> -rw-r--r--   1 daholme  staff      19688 Nov  1 00:18 config.log
>
>
> Is it tripping over its own output file ??? My script creates the 
> output directory then cd's to it and invokes configure.
>
> David
> -----
>
>>
>> /Magnus


From erik.joelsson at oracle.com  Thu Nov  1 04:28:03 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 01 Nov 2012 11:28:03 +0000
Subject: hg: build-infra/jdk8: Improved executable finding of bat files in
	cygwin.
Message-ID: <20121101112803.9A76C476EB@hg.openjdk.java.net>

Changeset: 2514aa7f9142
Author:    erikj
Date:      2012-11-01 12:26 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/2514aa7f9142

Improved executable finding of bat files in cygwin.

! common/autoconf/basics_windows.m4
! common/autoconf/generated-configure.sh



From erik.joelsson at oracle.com  Thu Nov  1 04:39:02 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 01 Nov 2012 11:39:02 +0000
Subject: hg: build-infra/jdk8: Fixed check for empty configuration dir to
	ignore files created by configure.
Message-ID: <20121101113903.1EA7A476EC@hg.openjdk.java.net>

Changeset: a09a85bb1e8f
Author:    erikj
Date:      2012-11-01 12:38 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/a09a85bb1e8f

Fixed check for empty configuration dir to ignore files created by configure.

! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh



From kelly.ohair at oracle.com  Thu Nov  1 11:38:07 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Thu, 1 Nov 2012 11:38:07 -0700
Subject: New builds from the build-infra team
Message-ID: <DCA50F95-9C8E-45BB-86BE-6BE322E1E916@oracle.com>


Pardon the wide email, but this impacts everyone building the OpenJDK jdk8/jdk8 derived forests.

Please only reply to the build-infra-dev mailing list, or just me.

With some recent integrations from the build-infra project into jdk8/jdk8 repositories, the build-infra team
would like to get more exposure of the new builds. These jdk8/jdk8 changes will start showing up in various
jdk8 and team forests over the next few weeks. The default is still the old builds, but both builds work in most
cases for OpenJDK as far as we know.

At a very high level, the intent is that once you get a forest:
  hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
  cd j8
  sh ./get_source.sh

You should be able to simply configure&&make (the ultimate goal is this simple anyway), e.g.
   sh ./configure
   make NEWBUILD=true     # The NEWBUILD=true will become the default when we formally switch.

Where "make" is GNU make 3.81, and your system has all the requires packages and PATH contains the
needed tools. Note that on Windows, MKS unix utilities cannot be used with the new builds, just CYGWIN
is recommended at this time.

Of course, we know, it's never as easy as a simple configure&&make, and often you will need to pass in
configure options.

What we would like to know is where a simple configure&&make does not work, and anything people had
to do to make it work.

I know many of you are quite used to the old builds, so I have a temporary  "bridgeBuild" target
people can try that will attempt to map the ALT_* environment variables to an appropriate configure command
and then run that configure command and do the build, e.g.

  make NEWBUILD=true bridgeBuild

People willing to do comparisons between the old and new builds could:
  rm -f -r build
  time make NEWBUILD=true bridgeBuild
  rm -f -r build
  time make NO_DOCS=true     # Old builds do not generate javadocs by default

Any observations about speed of the builds would be appreciated, as will any impressions on what you see.

At this time, we think this is working pretty well with a few caveats:
  * GNU make with the new builds is doing much more parallel processing and this can stress out a system
    - Use "make JOBS=1" if you suspect a problem, then try adjusting it up slowly.
  * Partial builds are limited, right now full builds of the entire OpenJDK is the target
    - Hotspot can still be built on it's own, but everyone else needs to build hotspot at least once
  * Paths with multiple names can cause problems, e.g. being on system svc6, and access an exported share
    area as /net/svc6/export/foobar  instead of /export/foobar  will cause problems. Use local paths.

We know there are still issues and we will be focusing heavily on the critical ones in the next few weeks, but
we do need the community to tell us what the critical issues really are.

Our number one priority at this time is that everyone that was able to build the old way, should be able to build
with the new build-infra makefiles. Please help us verify that.

-kto



From fredrik.ohrstrom at oracle.com  Fri Nov  2 03:42:35 2012
From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com)
Date: Fri, 02 Nov 2012 10:42:35 +0000
Subject: hg: build-infra/jdk8/langtools: Improve heuristics and debug messages
	and fix deadlock bug.
Message-ID: <20121102104241.2CD7D4772B@hg.openjdk.java.net>

Changeset: e6618e3498f9
Author:    ohrstrom
Date:      2012-11-02 11:41 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/langtools/rev/e6618e3498f9

Improve heuristics and debug messages and fix deadlock bug.

! src/share/classes/com/sun/tools/sjavac/CompileJavaPackages.java
! src/share/classes/com/sun/tools/sjavac/JavacState.java
! src/share/classes/com/sun/tools/sjavac/comp/SmartFileObject.java
! src/share/classes/com/sun/tools/sjavac/server/CompilerPool.java
! src/share/classes/com/sun/tools/sjavac/server/JavacServer.java
! src/share/classes/com/sun/tools/sjavac/server/PortFile.java



From erik.joelsson at oracle.com  Fri Nov  2 05:05:13 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 02 Nov 2012 12:05:13 +0000
Subject: hg: build-infra/jdk8/corba: 7 new changesets
Message-ID: <20121102120519.E3EA14772F@hg.openjdk.java.net>

Changeset: bbaef650c3d2
Author:    katleman
Date:      2012-10-25 09:53 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/corba/rev/bbaef650c3d2

Added tag jdk8-b62 for changeset 08afb9c6f44f

! .hgtags

Changeset: 679e8ad9874f
Author:    coffeys
Date:      2012-10-09 20:14 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/corba/rev/679e8ad9874f

7196086: update copyright years for files in corba repository (JDK 8)
Reviewed-by: lancea

! make/common/Defs-bsd.gmk
! make/common/internal/Resources.gmk
! make/common/shared/Defs-bsd.gmk
! make/common/shared/Defs-utils.gmk
! make/tools/src/build/tools/stripproperties/StripPropertiesCorba.java
! make/tools/strip_properties/Makefile

Changeset: 706684c5a058
Author:    lana
Date:      2012-10-12 14:46 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/corba/rev/706684c5a058

Merge


Changeset: 23e0226a31ac
Author:    lana
Date:      2012-10-23 09:40 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/corba/rev/23e0226a31ac

Merge


Changeset: 9094cd4a614f
Author:    lana
Date:      2012-10-25 20:05 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/corba/rev/9094cd4a614f

Merge

! make/common/shared/Defs-utils.gmk

Changeset: 6ccbf67b68bf
Author:    katleman
Date:      2012-10-31 18:30 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/corba/rev/6ccbf67b68bf

Merge


Changeset: c081de1f7eba
Author:    erikj
Date:      2012-11-02 12:07 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/corba/rev/c081de1f7eba

Merge

! make/tools/src/build/tools/stripproperties/StripPropertiesCorba.java



From erik.joelsson at oracle.com  Fri Nov  2 05:05:13 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 02 Nov 2012 12:05:13 +0000
Subject: hg: build-infra/jdk8: 9 new changesets
Message-ID: <20121102120514.255914772E@hg.openjdk.java.net>

Changeset: e3182741ade2
Author:    ihse
Date:      2012-10-29 14:06 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/e3182741ade2

8001897: build-infra: misc adjustments to configure script
Reviewed-by: ohair

! common/autoconf/Makefile.in
! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh
! common/autoconf/jdk-options.m4
! common/autoconf/spec.gmk.in
! common/autoconf/toolchain.m4

Changeset: 4e984be114bd
Author:    katleman
Date:      2012-10-25 09:52 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/4e984be114bd

Added tag jdk8-b62 for changeset 8a3fe0ae06a8

! .hgtags

Changeset: 4bde5640fb36
Author:    alanb
Date:      2012-10-09 13:25 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/4bde5640fb36

7173494: some jdk tests are not run in test/Makefile
Reviewed-by: chegar, mchung, mduigou, iris

! make/jprt.properties
! test/Makefile

Changeset: ce2b111ee869
Author:    lana
Date:      2012-10-12 14:46 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/ce2b111ee869

Merge


Changeset: 744e165aaf33
Author:    lana
Date:      2012-10-23 09:40 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/744e165aaf33

Merge


Changeset: ce212cd7ea69
Author:    lana
Date:      2012-10-25 20:04 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/ce212cd7ea69

Merge


Changeset: 3229597524ca
Author:    katleman
Date:      2012-10-31 18:30 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/3229597524ca

Merge

- common/bin/compareimage.sh
- common/bin/diffexec.sh
- common/bin/diffjarzip.sh
- common/bin/difflib.sh
- common/bin/difftext.sh
- common/bin/exception_list_linux
- common/bin/extractvcvars.sh
- common/bin/unicode2x.sed
- common/makefiles/compress.post
- common/makefiles/compress.pre
- common/makefiles/uncompress.sed
- common/src/uncygdrive.c

Changeset: 5489c81370e4
Author:    erikj
Date:      2012-11-02 12:07 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/5489c81370e4

Merge

! common/autoconf/Makefile.in
! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh
! common/autoconf/jdk-options.m4
! common/autoconf/spec.gmk.in
! common/autoconf/toolchain.m4

Changeset: 3ddef0df93bc
Author:    erikj
Date:      2012-11-02 13:04 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/3ddef0df93bc

8002183: Increased max number of paths to list in ListPathsSafely to 16000.

! common/makefiles/MakeBase.gmk



From erik.joelsson at oracle.com  Fri Nov  2 05:05:17 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 02 Nov 2012 12:05:17 +0000
Subject: hg: build-infra/jdk8/jaxws: 3 new changesets
Message-ID: <20121102120527.504FF47730@hg.openjdk.java.net>

Changeset: c27ea8d489e8
Author:    katleman
Date:      2012-10-25 09:53 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jaxws/rev/c27ea8d489e8

Added tag jdk8-b62 for changeset d265b9b4c0f5

! .hgtags

Changeset: 86989f702267
Author:    katleman
Date:      2012-10-31 18:30 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jaxws/rev/86989f702267

Merge


Changeset: 7d00293f2cb6
Author:    erikj
Date:      2012-11-02 12:07 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jaxws/rev/7d00293f2cb6

Merge




From erik.joelsson at oracle.com  Fri Nov  2 05:05:17 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 02 Nov 2012 12:05:17 +0000
Subject: hg: build-infra/jdk8/jaxp: 7 new changesets
Message-ID: <20121102120539.4621B47731@hg.openjdk.java.net>

Changeset: a96e34e038f5
Author:    katleman
Date:      2012-10-25 09:53 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jaxp/rev/a96e34e038f5

Added tag jdk8-b62 for changeset 5d0fa0108d02

! .hgtags

Changeset: 53a2a4893c8f
Author:    joehw
Date:      2012-10-09 14:19 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jaxp/rev/53a2a4893c8f

8000172: 2 SAX features does not work properly
Summary: When external dtd is not loaded, skippedEntity event should be reported for entity references.
Reviewed-by: lancea

! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java

Changeset: b545c99e4f5e
Author:    lana
Date:      2012-10-12 14:50 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jaxp/rev/b545c99e4f5e

Merge


Changeset: 23e1d537224b
Author:    lana
Date:      2012-10-23 09:41 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jaxp/rev/23e1d537224b

Merge


Changeset: fc589819b335
Author:    lana
Date:      2012-10-25 20:07 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jaxp/rev/fc589819b335

Merge


Changeset: 192d8a244bc3
Author:    katleman
Date:      2012-10-31 18:30 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jaxp/rev/192d8a244bc3

Merge


Changeset: ddaad175be5c
Author:    erikj
Date:      2012-11-02 12:07 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jaxp/rev/ddaad175be5c

Merge




From erik.joelsson at oracle.com  Fri Nov  2 05:05:20 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 02 Nov 2012 12:05:20 +0000
Subject: hg: build-infra/jdk8/hotspot: 39 new changesets
Message-ID: <20121102120646.36A3C47732@hg.openjdk.java.net>

Changeset: 556dd9e475c6
Author:    katleman
Date:      2012-10-25 09:53 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/556dd9e475c6

Added tag jdk8-b62 for changeset dccd40de8db1

! .hgtags

Changeset: d0e7716b179e
Author:    amurillo
Date:      2012-10-19 11:26 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/d0e7716b179e

8001176: new hotspot build - hs25-b07
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 85916677fc22
Author:    coleenp
Date:      2012-10-18 13:08 -0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/85916677fc22

7188233: UseVMInterruptibleIO flag deprecate for JDK8
Summary: The -XX:+UseVMInterruptibleIO flag is deprecated for JDK8.  The flag will still enable Interruptible IO on Solaris, but users will get a warning.
Reviewed-by: dholmes, acorn, alanb
Contributed-by: harold.seigel at oracle.com

! src/share/vm/runtime/arguments.cpp

Changeset: 8ebcedb7604d
Author:    coleenp
Date:      2012-10-18 13:09 -0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/8ebcedb7604d

7053130: hs_err file does not record specified CLASSPATH
Summary: Added code to write the value of the java.class.path property to the hs_err file.
Reviewed-by: kmo, dholmes, kvn
Contributed-by: harold.seigel at oracle.com

! src/share/vm/runtime/arguments.cpp

Changeset: c7957b458bf8
Author:    minqi
Date:      2012-10-19 08:56 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/c7957b458bf8

8000818: SA constant pool need to reference to reference map after permgen removal
Summary: After permgen removal, constant pool changed to put _ldc and _ldc_w (fast_ldc and fast_ldcw) index to reference map, no longer calculated via constant pool cache.
Reviewed-by: coleenp, sspitsyn, dholmes
Contributed-by: yumin.qi at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecodes.java
! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java

Changeset: 8eeffbc22f10
Author:    minqi
Date:      2012-10-19 08:58 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/8eeffbc22f10

8001055: Bytes.swap should follow big endian
Summary: This is a mistake change in 6879063 about Bytes.swap. Java byte code order always follows big endian, but in that change, assume they follow native platform order that is not right.
Reviewed-by: coleenp, sspitsyn, dholmes
Contributed-by: yumin.qi at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/runtime/Bytes.java

Changeset: 716c64bda5ba
Author:    zgu
Date:      2012-10-19 21:40 -0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/716c64bda5ba

7199092: NMT: NMT needs to deal overlapped virtual memory ranges
Summary: Enhanced virtual memory tracking to track committed regions as well as reserved regions, so NMT now can generate virtual memory map.
Reviewed-by: acorn, coleenp

! src/os/bsd/vm/perfMemory_bsd.cpp
! src/os/linux/vm/perfMemory_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/solaris/vm/perfMemory_solaris.cpp
! src/os/windows/vm/perfMemory_windows.cpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/filemap.cpp
! src/share/vm/memory/filemap.hpp
! src/share/vm/memory/metaspaceShared.cpp
! src/share/vm/memory/resourceArea.hpp
! src/share/vm/runtime/handles.cpp
! src/share/vm/runtime/handles.hpp
! src/share/vm/runtime/handles.inline.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/services/attachListener.cpp
! src/share/vm/services/memBaseline.cpp
! src/share/vm/services/memBaseline.hpp
! src/share/vm/services/memPtr.cpp
! src/share/vm/services/memPtr.hpp
! src/share/vm/services/memRecorder.cpp
! src/share/vm/services/memRecorder.hpp
! src/share/vm/services/memReporter.cpp
! src/share/vm/services/memReporter.hpp
! src/share/vm/services/memSnapshot.cpp
! src/share/vm/services/memSnapshot.hpp
! src/share/vm/services/memTracker.cpp
! src/share/vm/services/memTracker.hpp

Changeset: b988bff99b38
Author:    zgu
Date:      2012-10-19 18:55 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/b988bff99b38

Merge


Changeset: 80f44792c0c9
Author:    coleenp
Date:      2012-10-22 12:01 -0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/80f44792c0c9

Merge


Changeset: 685df3c6f84b
Author:    jmasa
Date:      2012-09-18 23:35 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/685df3c6f84b

7045397: NPG: Add freelists to class loader arenas.
Reviewed-by: coleenp, stefank, jprovino, ohair

! make/excludeSrc.make
+ src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp
+ src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp
! src/share/vm/gc_implementation/shared/vmGCOperations.hpp
! src/share/vm/memory/binaryTreeDictionary.cpp
! src/share/vm/memory/binaryTreeDictionary.hpp
! src/share/vm/memory/freeBlockDictionary.cpp
! src/share/vm/memory/freeBlockDictionary.hpp
! src/share/vm/memory/freeList.cpp
! src/share/vm/memory/freeList.hpp
+ src/share/vm/memory/metablock.hpp
+ src/share/vm/memory/metachunk.hpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 476718ea6759
Author:    jmasa
Date:      2012-10-25 12:59 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/476718ea6759

8001584: NPG: Incorrect assertion in BinaryTreeDictionary::get_chunk()
Reviewed-by: johnc, tamao

! src/share/vm/memory/binaryTreeDictionary.hpp

Changeset: b58313cf9afd
Author:    jcoomes
Date:      2012-10-26 08:38 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/b58313cf9afd

Merge


Changeset: cfe522e6461c
Author:    kvn
Date:      2012-10-17 12:09 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/cfe522e6461c

8000623: tools/javac/Diagnostics/6769027/T6769027.java crashes in PSPromotionManager::copy_to_survivor_space
Summary: Fix type of method pointer load from vtable.
Reviewed-by: twisti, johnc, roland

! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/library_call.cpp

Changeset: e81a8af10cd9
Author:    kvn
Date:      2012-10-18 07:06 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/e81a8af10cd9

8001071: Add simple range check into VM implemenation of Unsafe access methods
Summary: Add simple check in debug version of VM.
Reviewed-by: twisti, johnc

! src/share/vm/prims/unsafe.cpp

Changeset: aaeb9add1ab3
Author:    dlong
Date:      2012-10-19 14:21 -0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/aaeb9add1ab3

8001101: C2: more general vector rule subsetting
Summary: Allow which vector rules are supported to be decided at runtime. Also a small change to allow vector types in Type::_type_info[] to apply to more platforms.
Reviewed-by: kvn, twisti
Contributed-by: dean.long at oracle.com

! src/share/vm/opto/type.cpp
! src/share/vm/opto/vectornode.cpp

Changeset: 67f4c477c9ab
Author:    vlivanov
Date:      2012-10-22 11:44 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/67f4c477c9ab

8000805: JMM issue: short loads are non-atomic
Summary: perform transforms during IGVN phase when Load has a single user.
Reviewed-by: jrose, kvn, twisti

! src/share/vm/opto/mulnode.cpp
+ test/compiler/8000805/Test8000805.java

Changeset: fd1d564dd460
Author:    twisti
Date:      2012-10-22 16:56 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/fd1d564dd460

8000821: JSR 292: C1 fails to call virtual method (JRUBY-6920)
Reviewed-by: kvn

! src/share/vm/c1/c1_GraphBuilder.cpp

Changeset: b2c669fd8114
Author:    kvn
Date:      2012-10-23 13:06 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/b2c669fd8114

8001183: incorrect results of char vectors right shift operaiton
Summary: do vector right shift operation for small int types only after loads
Reviewed-by: jrose, dlong

! src/cpu/x86/vm/x86.ad
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/vectornode.cpp
! test/compiler/6340864/TestByteVect.java
! test/compiler/6340864/TestIntVect.java
! test/compiler/6340864/TestLongVect.java
! test/compiler/6340864/TestShortVect.java
+ test/compiler/8001183/TestCharVect.java

Changeset: a3ecd773a7b9
Author:    kvn
Date:      2012-10-24 14:33 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/a3ecd773a7b9

7184394: add intrinsics to use AES instructions
Summary: Use new x86 AES instructions for AESCrypt.
Reviewed-by: twisti, kvn, roland
Contributed-by: tom.deneau at amd.com

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/stubRoutines_x86_32.cpp
! src/cpu/x86/vm/stubRoutines_x86_32.hpp
! src/cpu/x86/vm/stubRoutines_x86_64.cpp
! src/cpu/x86/vm/stubRoutines_x86_64.hpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/vm_version_x86.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/callGenerator.hpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/opto/runtime.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/stubRoutines.hpp
+ test/compiler/7184394/TestAESBase.java
+ test/compiler/7184394/TestAESDecode.java
+ test/compiler/7184394/TestAESEncode.java
+ test/compiler/7184394/TestAESMain.java

Changeset: 006174cfe979
Author:    kvn
Date:      2012-10-25 17:32 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/006174cfe979

7163534: VM could crashes assert(false) failed: infinite EA connection graph build
Summary: In case of time or iterations limit reached C2 stops EA and continue compilation without EA as it does in product VM already.
Reviewed-by: twisti

! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/escape.cpp

Changeset: 410afdc6a07c
Author:    kvn
Date:      2012-10-26 11:48 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/410afdc6a07c

8001635: assert(in_bb(n)) failed: must be
Summary: Added missed check that Load node is in processed loop block.
Reviewed-by: twisti

! src/share/vm/opto/superword.cpp

Changeset: 588f08ed16cf
Author:    kvn
Date:      2012-10-26 12:06 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/588f08ed16cf

Merge

! src/share/vm/runtime/globals.hpp

Changeset: dc16fe422c53
Author:    amurillo
Date:      2012-10-26 14:09 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/dc16fe422c53

Merge


Changeset: 57c61f87a1fd
Author:    amurillo
Date:      2012-10-26 14:09 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/57c61f87a1fd

Added tag hs25-b07 for changeset dc16fe422c53

! .hgtags

Changeset: bf14ed159fb0
Author:    kvn
Date:      2012-05-23 12:11 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/bf14ed159fb0

7158801: Improve VM CompileOnly option
Summary: Fixed buffer overflow during parsing flags -XX:CompileCommand=, -XX:CompileOnly= and command lines in .hotspot_compiler file.
Reviewed-by: never

! src/share/vm/compiler/compilerOracle.cpp

Changeset: fe4a4ea5bed9
Author:    kamg
Date:      2012-06-08 12:49 -0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/fe4a4ea5bed9

7158804: Improve config file parsing
Summary: Check buffer length when reading
Reviewed-by: dholmes, dcubed

! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/runtime/arguments.cpp
+ test/runtime/7158804/Test7158804.sh

Changeset: 6b5a3d18fe0e
Author:    asaha
Date:      2012-08-02 14:29 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/6b5a3d18fe0e

Merge

! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: 000352e00389
Author:    asaha
Date:      2012-08-02 22:23 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/000352e00389

Merge


Changeset: defeb6dad7d5
Author:    asaha
Date:      2012-08-10 10:41 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/defeb6dad7d5

Merge


Changeset: e4d10261499c
Author:    asaha
Date:      2012-09-07 18:18 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/e4d10261499c

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
- src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp
- src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp
- src/share/vm/prims/methodHandleWalk.cpp
- src/share/vm/prims/methodHandleWalk.hpp
! src/share/vm/runtime/arguments.cpp

Changeset: 521c82b9cbf8
Author:    kvn
Date:      2012-09-19 13:58 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/521c82b9cbf8

7198606: Improve VM optimization
Summary: Remove incorrect code in OptimizeFill optimization.
Reviewed-by: roland, twisti

! src/share/vm/opto/loopTransform.cpp

Changeset: 849cf0480cb9
Author:    asaha
Date:      2012-09-25 11:47 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/849cf0480cb9

Merge


Changeset: 5a3a6dac85e2
Author:    asaha
Date:      2012-09-26 09:54 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/5a3a6dac85e2

7199488: [TEST] runtime/7158800/InternTest.java failed due to false-positive on PID match.
Reviewed-by: coleenp

- test/runtime/7158800/BadUtf8.java
- test/runtime/7158800/InternTest.java
- test/runtime/7158800/Test7158800.sh
- test/runtime/7158800/badstrings.txt

Changeset: 218a94758fe7
Author:    asaha
Date:      2012-10-10 14:28 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/218a94758fe7

Merge

- agent/make/ClosureFinder.java
- agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java
- agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Address.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java
- agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/gc_implementation/parallelScavenge/PSPermGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGenGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGenGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/ContigPermSpace.java
- agent/src/share/classes/sun/jvm/hotspot/memory/PermGen.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/CompiledICHolderKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethodKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/KlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/MethodDataKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/MethodKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java
- agent/src/share/classes/sun/jvm/hotspot/ui/tree/BadOopTreeNodeAdapter.java
- make/solaris/makefiles/reorder_COMPILER1_amd64
- make/solaris/makefiles/reorder_COMPILER1_i486
- make/solaris/makefiles/reorder_COMPILER1_sparc
- make/solaris/makefiles/reorder_COMPILER1_sparcv9
- make/solaris/makefiles/reorder_COMPILER2_amd64
- make/solaris/makefiles/reorder_COMPILER2_i486
- make/solaris/makefiles/reorder_COMPILER2_sparc
- make/solaris/makefiles/reorder_COMPILER2_sparcv9
- make/solaris/makefiles/reorder_CORE_i486
- make/solaris/makefiles/reorder_CORE_sparc
- make/solaris/makefiles/reorder_CORE_sparcv9
- make/solaris/makefiles/reorder_TIERED_amd64
- make/solaris/makefiles/reorder_TIERED_i486
- make/solaris/makefiles/reorder_TIERED_sparc
- make/solaris/makefiles/reorder_TIERED_sparcv9
- make/solaris/reorder.sh
- src/cpu/sparc/vm/dump_sparc.cpp
- src/cpu/x86/vm/dump_x86_32.cpp
- src/cpu/x86/vm/dump_x86_64.cpp
- src/cpu/zero/vm/dump_zero.cpp
- src/share/tools/ProjectCreator/DirectoryTree.java
- src/share/tools/ProjectCreator/DirectoryTreeNode.java
- src/share/tools/ProjectCreator/FileFormatException.java
- src/share/tools/ProjectCreator/WinGammaPlatformVC6.java
- src/share/vm/ci/ciArrayKlassKlass.hpp
- src/share/vm/ci/ciCPCache.cpp
- src/share/vm/ci/ciCPCache.hpp
- src/share/vm/ci/ciInstanceKlassKlass.cpp
- src/share/vm/ci/ciInstanceKlassKlass.hpp
- src/share/vm/ci/ciKlassKlass.cpp
- src/share/vm/ci/ciKlassKlass.hpp
- src/share/vm/ci/ciMethodKlass.cpp
- src/share/vm/ci/ciMethodKlass.hpp
- src/share/vm/ci/ciObjArrayKlassKlass.cpp
- src/share/vm/ci/ciObjArrayKlassKlass.hpp
- src/share/vm/ci/ciTypeArrayKlassKlass.cpp
- src/share/vm/ci/ciTypeArrayKlassKlass.hpp
! src/share/vm/compiler/compilerOracle.cpp
- src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp
- src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp
- src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp
- src/share/vm/gc_implementation/parallelScavenge/psPermGen.hpp
- src/share/vm/memory/classify.cpp
- src/share/vm/memory/classify.hpp
- src/share/vm/memory/compactPermGen.hpp
- src/share/vm/memory/compactingPermGenGen.cpp
- src/share/vm/memory/compactingPermGenGen.hpp
- src/share/vm/memory/dump.cpp
- src/share/vm/memory/permGen.cpp
- src/share/vm/memory/permGen.hpp
- src/share/vm/memory/restore.cpp
- src/share/vm/memory/serialize.cpp
- src/share/vm/oops/arrayKlassKlass.cpp
- src/share/vm/oops/arrayKlassKlass.hpp
- src/share/vm/oops/compiledICHolderKlass.cpp
- src/share/vm/oops/compiledICHolderKlass.hpp
- src/share/vm/oops/compiledICHolderOop.cpp
- src/share/vm/oops/compiledICHolderOop.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/constantPoolKlass.cpp
- src/share/vm/oops/constantPoolKlass.hpp
- src/share/vm/oops/constantPoolOop.cpp
- src/share/vm/oops/constantPoolOop.hpp
- src/share/vm/oops/cpCacheKlass.cpp
- src/share/vm/oops/cpCacheKlass.hpp
- src/share/vm/oops/cpCacheOop.cpp
- src/share/vm/oops/cpCacheOop.hpp
- src/share/vm/oops/instanceKlassKlass.cpp
- src/share/vm/oops/instanceKlassKlass.hpp
- src/share/vm/oops/klassKlass.cpp
- src/share/vm/oops/klassKlass.hpp
- src/share/vm/oops/klassOop.cpp
- src/share/vm/oops/klassOop.hpp
- src/share/vm/oops/methodDataKlass.cpp
- src/share/vm/oops/methodDataKlass.hpp
- src/share/vm/oops/methodDataOop.cpp
- src/share/vm/oops/methodDataOop.hpp
- src/share/vm/oops/methodKlass.cpp
- src/share/vm/oops/methodKlass.hpp
- src/share/vm/oops/methodOop.cpp
- src/share/vm/oops/methodOop.hpp
- src/share/vm/oops/objArrayKlassKlass.cpp
- src/share/vm/oops/objArrayKlassKlass.hpp
- src/share/vm/oops/typeArrayKlassKlass.cpp
- src/share/vm/oops/typeArrayKlassKlass.hpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: 6ba00f89fbe1
Author:    asaha
Date:      2012-10-11 15:29 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/6ba00f89fbe1

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: d2582a08fa5d
Author:    asaha
Date:      2012-10-18 21:58 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/d2582a08fa5d

Merge

! src/share/vm/opto/loopTransform.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: cb829aa4c98e
Author:    lana
Date:      2012-10-25 20:07 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/cb829aa4c98e

Merge

- test/runtime/7158800/BadUtf8.java
- test/runtime/7158800/InternTest.java
- test/runtime/7158800/Test7158800.sh
- test/runtime/7158800/badstrings.txt

Changeset: acabb5c282f5
Author:    lana
Date:      2012-10-30 13:56 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/acabb5c282f5

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: 797f7023bad2
Author:    erikj
Date:      2012-11-02 12:07 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/797f7023bad2

Merge

- test/runtime/7158800/BadUtf8.java
- test/runtime/7158800/InternTest.java
- test/runtime/7158800/Test7158800.sh
- test/runtime/7158800/badstrings.txt



From erik.joelsson at oracle.com  Fri Nov  2 05:05:38 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 02 Nov 2012 12:05:38 +0000
Subject: hg: build-infra/jdk8/jdk: 84 new changesets
Message-ID: <20121102123116.D841F47734@hg.openjdk.java.net>

Changeset: 5b29d6157504
Author:    erikj
Date:      2012-10-29 13:04 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/5b29d6157504

8001887: build-infra: Correct mapfiles in build-infra area
Reviewed-by: ohair

! makefiles/mapfiles/libnio/mapfile-linux
! makefiles/mapfiles/libnio/mapfile-macosx
! makefiles/mapfiles/libnio/mapfile-solaris

Changeset: dcee387cde81
Author:    ohrstrom
Date:      2012-10-29 13:41 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/dcee387cde81

8001891: build-infra: Adding X_CFLAGS and X_LIBS to lwawt and sizer compilation
Reviewed-by: ohair

! makefiles/CompileNativeLibraries.gmk
! makefiles/GensrcX11Wrappers.gmk

Changeset: 524d1a705f7b
Author:    erikj
Date:      2012-10-29 13:55 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/524d1a705f7b

8001898: build-infra: correct exclusion lists for mac jar builds
8001896: build-infra: UNLIMITED_CRYPTO changes
Reviewed-by: ohair

! makefiles/CreateJars.gmk

Changeset: 65d2c6726487
Author:    katleman
Date:      2012-10-25 09:54 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/65d2c6726487

Added tag jdk8-b62 for changeset 50b8b17449d2

! .hgtags

Changeset: 117eed515e42
Author:    bae
Date:      2012-10-23 13:10 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/117eed515e42

7051394: NullPointerException when running regression tests LoadProfileTest by using openjdk-7-b144
Reviewed-by: jgodinez, prr

! src/share/native/sun/java2d/cmm/lcms/LCMS.c

Changeset: aeb96dec1c6b
Author:    lana
Date:      2012-10-23 09:38 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/aeb96dec1c6b

Merge


Changeset: 93e2669f1ac2
Author:    leonidr
Date:      2012-10-09 18:00 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/93e2669f1ac2

7185280: Jre7cert: focusgained does not get called for all focus req when do alt + tab
Reviewed-by: anthony

! src/windows/native/sun/windows/awt_Window.cpp

Changeset: 527f8eeb8e8d
Author:    leonidr
Date:      2012-10-09 20:59 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/527f8eeb8e8d

7124321: [macosx] TrayIcon MouseListener is never triggered
Reviewed-by: anthony

! src/macosx/classes/sun/lwawt/macosx/CTrayIcon.java
! src/macosx/native/sun/awt/CTrayIcon.h
! src/macosx/native/sun/awt/CTrayIcon.m

Changeset: d4d0327e36e2
Author:    kshefov
Date:      2012-10-12 18:46 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/d4d0327e36e2

7184326: TEST_BUG: java/awt/Frame/7024749/bug7024749.java has a typo
Reviewed-by: anthony

! test/java/awt/Frame/7024749/bug7024749.java

Changeset: 34d502d14a61
Author:    lana
Date:      2012-10-12 14:47 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/34d502d14a61

Merge

- src/share/classes/sun/util/xml/XMLUtils.java
- src/share/test/pack200/pack.conf

Changeset: f42d178f0452
Author:    anthony
Date:      2012-10-16 20:11 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/f42d178f0452

6818083: When DISPLAY is bad, InternalError thrown, not AWTError
Summary: Throw AWTError instead of InternalError if the DISPLAY is bad
Reviewed-by: anthony, serb
Contributed-by: Mikhail Cherkasov <mikhail.cherkasov at oracle.com>

! src/solaris/native/sun/awt/awt_GraphicsEnv.c
+ test/java/awt/Toolkit/BadDisplayTest/BadDisplayTest.java
+ test/java/awt/Toolkit/BadDisplayTest/BadDisplayTest.sh

Changeset: 47cdc463b4b0
Author:    kizune
Date:      2012-10-17 14:32 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/47cdc463b4b0

7175704: [macosx] "8" PIT: NPE in GetDisplayMode fullscreen test
Reviewed-by: serb, leonidr

! src/macosx/classes/sun/awt/CGraphicsDevice.java

Changeset: e6a8ee65d248
Author:    alexsch
Date:      2012-10-17 17:33 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/e6a8ee65d248

8000969: [macosx] Directories are not deselected when JFileChooser has FILES_ONLY selection mode
Reviewed-by: rupashka

! src/macosx/classes/com/apple/laf/AquaFileChooserUI.java

Changeset: 29b7bd890d3a
Author:    alexsch
Date:      2012-10-17 10:16 -0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/29b7bd890d3a

8000626: Implement dead key detection for KeyEvent on Linux
Reviewed-by: kizune

! src/solaris/classes/sun/awt/X11/XKeysym.java
! src/solaris/classes/sun/awt/X11/XWindow.java
! src/solaris/classes/sun/awt/X11/keysym2ucs.h

Changeset: 9c6f60a4e996
Author:    alexsch
Date:      2012-10-18 17:50 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/9c6f60a4e996

7199708: FileChooser crashs when opening large folder
Reviewed-by: bagiras

! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java

Changeset: 8bbc6a5f1e92
Author:    alexsch
Date:      2012-10-18 18:28 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/8bbc6a5f1e92

7175707: [macosx] PIT: 8 b43 Not running on AppKit thread issue again
Reviewed-by: serb, anthony

! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/awt/AWTWindow.m

Changeset: 6b16f6fc41c5
Author:    serb
Date:      2012-10-19 15:23 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/6b16f6fc41c5

7124520: [macosx] re:6373505 Toolkit.getScreenResolution() != GraphicsConfiguration.getNormalizingTransform()
Reviewed-by: anthony, kizune

! src/macosx/classes/sun/awt/CGraphicsDevice.java
! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
+ test/java/awt/GraphicsConfiguration/NormalizingTransformTest/NormalizingTransformTest.java

Changeset: e0f91b40b8dd
Author:    alexsch
Date:      2012-10-23 14:30 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/e0f91b40b8dd

6624200: Regression test fails: test/closed/javax/swing/JMenuItem/4654927/bug4654927.java
Reviewed-by: rupashka

+ test/javax/swing/JMenuItem/4654927/bug4654927.java
! test/javax/swing/regtesthelpers/Util.java

Changeset: 37a6ead4a357
Author:    lana
Date:      2012-10-23 09:40 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/37a6ead4a357

Merge


Changeset: fecba6a8b78e
Author:    coffeys
Date:      2012-10-09 12:50 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/fecba6a8b78e

7196533: TimeZone.getDefault() slow due to synchronization bottleneck
Reviewed-by: okutsu

! src/share/classes/java/util/TimeZone.java

Changeset: 3b79177ebfef
Author:    alanb
Date:      2012-10-09 13:28 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/3b79177ebfef

7173494: some jdk tests are not run in test/Makefile
Reviewed-by: chegar, mchung, mduigou, iris

! make/jprt.properties
! test/Makefile
! test/ProblemList.txt

Changeset: 036c55976cef
Author:    lancea
Date:      2012-10-09 08:58 -0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/036c55976cef

7197395: Add @Deprecated to all deprecated methods to eliminate compiler warnings in JDBC
Reviewed-by: alanb, smarks

! src/share/classes/com/sun/rowset/CachedRowSetImpl.java
! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java
! src/share/classes/com/sun/rowset/JoinRowSetImpl.java
! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java
! src/share/classes/java/sql/CallableStatement.java
! src/share/classes/java/sql/Date.java
! src/share/classes/java/sql/DriverManager.java
! src/share/classes/java/sql/PreparedStatement.java
! src/share/classes/java/sql/ResultSet.java
! src/share/classes/javax/sql/rowset/BaseRowSet.java

Changeset: c725ce4bbf12
Author:    naoto
Date:      2012-10-09 09:59 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/c725ce4bbf12

7200341: DateFormatSymbols.hashCode() throws ArrayIndexOutOfBoundsException in some circumstances
Reviewed-by: okutsu

! src/share/classes/java/text/DateFormatSymbols.java
! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java
! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.sh
! test/java/util/PluggableLocale/fooprovider.jar
! test/java/util/PluggableLocale/providersrc/DateFormatSymbolsProviderImpl.java

Changeset: 71de5e31d497
Author:    coffeys
Date:      2012-10-09 19:45 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/71de5e31d497

7181793: Socket getOutputStream create streams that cannot be GC'ed until Socket is closed
Reviewed-by: alanb, chegar

! src/share/classes/java/net/AbstractPlainSocketImpl.java
+ test/java/net/Socket/SocketGrowth.java

Changeset: 3c4be36de073
Author:    lancea
Date:      2012-10-10 11:15 -0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/3c4be36de073

8000687: Correct javadoc typo for getLogWriter and setLogWriter
Reviewed-by: alanb

! src/share/classes/java/sql/DriverManager.java

Changeset: 6455182d2797
Author:    alanb
Date:      2012-10-10 20:47 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/6455182d2797

7192274: Deprecate LogManager addPropertyChangeListener and removePropertyChangeLister methods
Reviewed-by: mchung, lancea, chegar

! src/share/classes/java/util/logging/LogManager.java

Changeset: 734ca9f4719c
Author:    lancea
Date:      2012-10-10 17:34 -0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/734ca9f4719c

8000712: Remove unused fields in SyncFactory
Reviewed-by: mchung

! src/share/classes/javax/sql/rowset/spi/SyncFactory.java

Changeset: c2be39b27e1c
Author:    dxu
Date:      2012-10-11 11:47 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/c2be39b27e1c

7186817: Remove Windows 95/98/ME Support
Reviewed-by: alanb

! make/java/java/Makefile
! makefiles/CompileNativeLibraries.gmk
- src/windows/classes/java/io/Win32FileSystem.java
! src/windows/classes/java/io/WinNTFileSystem.java
! src/windows/native/java/io/FileSystem_md.c
- src/windows/native/java/io/Win32FileSystem_md.c
! src/windows/native/java/io/WinNTFileSystem_md.c
! src/windows/native/java/io/io_util_md.c
! src/windows/native/java/lang/ProcessImpl_md.c
! src/windows/native/java/util/TimeZone_md.c
! test/java/io/pathNames/win32/bug6344646.java

Changeset: 7c2f5e52863c
Author:    robm
Date:      2012-10-11 18:24 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/7c2f5e52863c

7152183: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently [sol]
Reviewed-by: alanb, martin, dholmes

! test/java/lang/ProcessBuilder/Basic.java

Changeset: daabaafd6798
Author:    lancea
Date:      2012-10-11 18:46 -0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/daabaafd6798

8000763: use XXX.valueOf methods instead of constructors
Reviewed-by: mchung, forax

! src/share/classes/com/sun/rowset/CachedRowSetImpl.java
! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java
! src/share/classes/javax/sql/rowset/BaseRowSet.java
! src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java

Changeset: e23f8e0a1d89
Author:    lana
Date:      2012-10-12 14:52 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/e23f8e0a1d89

Merge


Changeset: ff641c5b329b
Author:    jgish
Date:      2012-10-13 10:15 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/ff641c5b329b

7146552: java/util/logging/LoggingMXBeanTest.java failing intermittently
Reviewed-by: alanb, mchung

! test/java/util/logging/LoggingMXBeanTest.java
! test/java/util/logging/LoggingMXBeanTest2.java

Changeset: fe28e0b035e7
Author:    sflores
Date:      2012-10-14 22:58 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/fe28e0b035e7

7194449: String resources for Key Tool and Policy Tool should be in their respective packages
Reviewed-by: alanb, weijun, mullan

! make/common/Release.gmk
! make/launchers/Makefile
! make/sun/security/tools/Makefile
! makefiles/CompileLaunchers.gmk
! makefiles/CreateJars.gmk
- src/share/classes/sun/security/tools/CertAndKeyGen.java
- src/share/classes/sun/security/tools/JarSigner.java
- src/share/classes/sun/security/tools/JarSignerResources.java
- src/share/classes/sun/security/tools/JarSignerResources_ja.java
- src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java
! src/share/classes/sun/security/tools/KeyStoreUtil.java
- src/share/classes/sun/security/tools/KeyTool.java
- src/share/classes/sun/security/tools/TimestampedSigner.java
+ src/share/classes/sun/security/tools/jarsigner/Main.java
+ src/share/classes/sun/security/tools/jarsigner/Resources.java
+ src/share/classes/sun/security/tools/jarsigner/Resources_ja.java
+ src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java
+ src/share/classes/sun/security/tools/jarsigner/TimestampedSigner.java
+ src/share/classes/sun/security/tools/keytool/CertAndKeyGen.java
+ src/share/classes/sun/security/tools/keytool/Main.java
+ src/share/classes/sun/security/tools/keytool/Resources.java
+ src/share/classes/sun/security/tools/keytool/Resources_de.java
+ src/share/classes/sun/security/tools/keytool/Resources_es.java
+ src/share/classes/sun/security/tools/keytool/Resources_fr.java
+ src/share/classes/sun/security/tools/keytool/Resources_it.java
+ src/share/classes/sun/security/tools/keytool/Resources_ja.java
+ src/share/classes/sun/security/tools/keytool/Resources_ko.java
+ src/share/classes/sun/security/tools/keytool/Resources_pt_BR.java
+ src/share/classes/sun/security/tools/keytool/Resources_sv.java
+ src/share/classes/sun/security/tools/keytool/Resources_zh_CN.java
+ src/share/classes/sun/security/tools/keytool/Resources_zh_HK.java
+ src/share/classes/sun/security/tools/keytool/Resources_zh_TW.java
! src/share/classes/sun/security/tools/policytool/PolicyTool.java
+ src/share/classes/sun/security/tools/policytool/Resources.java
+ src/share/classes/sun/security/tools/policytool/Resources_de.java
+ src/share/classes/sun/security/tools/policytool/Resources_es.java
+ src/share/classes/sun/security/tools/policytool/Resources_fr.java
+ src/share/classes/sun/security/tools/policytool/Resources_it.java
+ src/share/classes/sun/security/tools/policytool/Resources_ja.java
+ src/share/classes/sun/security/tools/policytool/Resources_ko.java
+ src/share/classes/sun/security/tools/policytool/Resources_pt_BR.java
+ src/share/classes/sun/security/tools/policytool/Resources_sv.java
+ src/share/classes/sun/security/tools/policytool/Resources_zh_CN.java
+ src/share/classes/sun/security/tools/policytool/Resources_zh_HK.java
+ src/share/classes/sun/security/tools/policytool/Resources_zh_TW.java
! src/share/classes/sun/security/util/Resources.java
! src/share/classes/sun/security/util/Resources_de.java
! src/share/classes/sun/security/util/Resources_es.java
! src/share/classes/sun/security/util/Resources_fr.java
! src/share/classes/sun/security/util/Resources_it.java
! src/share/classes/sun/security/util/Resources_ja.java
! src/share/classes/sun/security/util/Resources_ko.java
! src/share/classes/sun/security/util/Resources_pt_BR.java
! src/share/classes/sun/security/util/Resources_sv.java
! src/share/classes/sun/security/util/Resources_zh_CN.java
! src/share/classes/sun/security/util/Resources_zh_TW.java
! test/sun/security/pkcs12/PKCS12SameKeyId.java
! test/sun/security/tools/jarsigner/JarSigningNonAscii.java
! test/sun/security/tools/jarsigner/LargeJarEntry.java
! test/sun/security/tools/keytool/CloseFile.java
! test/sun/security/tools/keytool/KeyToolTest.java
! test/sun/security/tools/keytool/NewSize7.java
! test/sun/security/tools/keytool/StartDateTest.java
! test/sun/security/tools/keytool/UnknownAndUnparseable.java
! test/sun/security/tools/keytool/autotest.sh
! test/sun/security/tools/keytool/standard.sh
! test/sun/security/util/Resources/Format.java
! test/sun/security/util/Resources/NewNamesFormat.java
! test/sun/security/util/Resources/NewResourcesNames.java
! test/sun/security/x509/AlgorithmId/NonStandardNames.java

Changeset: 7055257a25c4
Author:    robm
Date:      2012-10-15 03:26 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/7055257a25c4

8000817: Reinstate accidentally removed sleep() from ProcessBuilder/Basic.java
Reviewed-by: alanb, martin

! test/java/lang/ProcessBuilder/Basic.java

Changeset: c0736b62160e
Author:    robm
Date:      2012-10-15 22:34 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/c0736b62160e

8000487: Java JNDI connection library on ldap conn is not honoring configured timeout
Reviewed-by: vinnie

! src/share/classes/com/sun/jndi/ldap/Connection.java
! src/share/classes/com/sun/jndi/ldap/LdapClient.java
+ test/com/sun/jndi/ldap/LdapTimeoutTest.java
- test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java
- test/com/sun/jndi/ldap/ReadTimeoutTest.java

Changeset: 32452042b781
Author:    naoto
Date:      2012-10-16 10:59 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/32452042b781

8000245: SimpleDateFormat.format(date, StringBuffer, FieldPosition) doesn't work as expected with custom extensions
8000273: java.util.Locale.getDisplayVariant(Locale l) isn't transferred to the custom service provider
8000615: JRE adapter: timezone name of en_US is changed when extension directory is added
Reviewed-by: okutsu

! src/share/classes/sun/util/locale/provider/CurrencyNameProviderImpl.java
! src/share/classes/sun/util/locale/provider/LocaleNameProviderImpl.java
! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java
! src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java
! test/java/util/Locale/LocaleProviders.java
! test/java/util/Locale/LocaleProviders.sh
! test/java/util/PluggableLocale/CurrencyNameProviderTest.java
! test/java/util/PluggableLocale/LocaleNameProviderTest.java
! test/java/util/PluggableLocale/LocaleNameProviderTest.sh
! test/java/util/PluggableLocale/ProviderTest.java
! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java
! test/java/util/PluggableLocale/providersrc/LocaleNameProviderImpl.java

Changeset: 3a6b76a468bd
Author:    khazra
Date:      2012-10-16 15:23 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/3a6b76a468bd

7198073: (prefs) user prefs not saved [macosx]
Summary: Using class member field to get node instead of argument
Reviewed-by: alanb

! src/macosx/classes/java/util/prefs/MacOSXPreferences.java
+ test/java/util/prefs/CheckUserPrefFirst.java
+ test/java/util/prefs/CheckUserPrefLater.java
+ test/java/util/prefs/CheckUserPrefsStorage.sh

Changeset: 14b9e294d049
Author:    alanb
Date:      2012-10-17 11:43 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/14b9e294d049

8000685: (props) Properties.storeToXML/loadFromXML should only require UTF-8 and UTF-16 to be supported
Reviewed-by: mchung, chegar

! src/share/classes/java/util/Properties.java
! src/share/classes/sun/util/spi/XmlPropertiesProvider.java
! src/share/classes/sun/util/xml/PlatformXmlPropertiesProvider.java
! test/java/util/Properties/LoadAndStoreXML.java

Changeset: 5eed4a92ca8c
Author:    ngmr
Date:      2012-10-17 13:35 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/5eed4a92ca8c

8000955: Hashtable.Entry.hashCode() does not conform to Map.Entry.hashCode() defined behaviour
Reviewed-by: mduigou, alanb

! src/share/classes/java/util/Hashtable.java
+ test/java/util/Map/EntryHashCode.java

Changeset: b2d8a99a049e
Author:    dsamersoff
Date:      2012-10-17 18:34 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/b2d8a99a049e

6809322: javax.management.timer.Timer does not fire all notifications
Summary: Some notifications get dropped due to ConcurrentModificationException thrown in Timer.notifyAlarmClock() method.
Reviewed-by: dholmes, rbackman
Contributed-by: jaroslav.bachorik at oracle.com

! src/share/classes/javax/management/timer/Timer.java
+ test/javax/management/timer/MissingNotificationTest.java

Changeset: 6156b9235758
Author:    mchung
Date:      2012-10-17 12:03 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/6156b9235758

8001012: jdk8 SKIP_BUILD_CYCLE=false build fails with BUILD_JAXWS=false
Reviewed-by: alanb, ohair

! make/common/internal/Defs-jaxws.gmk

Changeset: 586028bbf885
Author:    psandoz
Date:      2012-10-17 20:34 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/586028bbf885

7198496: (sl) ServiceLoader.load(Class, null) behavior differs from spec
Reviewed-by: dholmes, alanb

! src/share/classes/java/util/ServiceLoader.java
! test/java/util/ServiceLoader/Basic.java
! test/java/util/ServiceLoader/basic.sh

Changeset: b265ead7f331
Author:    alanb
Date:      2012-10-17 21:05 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/b265ead7f331

8000362: (pack200) Deprecate Packer/Unpacker addPropertyChangeLister and removePropertyChangeListener methods
Reviewed-by: lancea, chegar, mchung, ksrini

! src/share/classes/java/util/jar/Pack200.java

Changeset: 60994591be6b
Author:    naoto
Date:      2012-10-17 13:22 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/60994591be6b

8001046: java/util/PluggableLocale/LocaleNameProviderTest.sh failing
Reviewed-by: okutsu

! test/java/util/PluggableLocale/barprovider.jar

Changeset: 3f62cfc4e83d
Author:    xuelei
Date:      2012-10-18 01:14 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/3f62cfc4e83d

7068321: Support TLS Server Name Indication (SNI) Extension in JSSE Server
Reviewed-by: mullan, weijun, wetmore

! src/share/classes/javax/net/ssl/ExtendedSSLSession.java
! src/share/classes/javax/net/ssl/HandshakeCompletedEvent.java
+ src/share/classes/javax/net/ssl/SNIHostName.java
+ src/share/classes/javax/net/ssl/SNIMatcher.java
+ src/share/classes/javax/net/ssl/SNIServerName.java
! src/share/classes/javax/net/ssl/SSLEngine.java
! src/share/classes/javax/net/ssl/SSLParameters.java
! src/share/classes/javax/net/ssl/SSLServerSocket.java
! src/share/classes/javax/net/ssl/SSLSocket.java
! src/share/classes/javax/net/ssl/SSLSocketFactory.java
+ src/share/classes/javax/net/ssl/StandardConstants.java
! src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java
! src/share/classes/sun/security/ssl/ClientHandshaker.java
! src/share/classes/sun/security/ssl/HandshakeInStream.java
! src/share/classes/sun/security/ssl/HandshakeMessage.java
! src/share/classes/sun/security/ssl/Handshaker.java
! src/share/classes/sun/security/ssl/HelloExtensions.java
! src/share/classes/sun/security/ssl/ProtocolList.java
! src/share/classes/sun/security/ssl/SSLEngineImpl.java
! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java
! src/share/classes/sun/security/ssl/SSLSessionImpl.java
! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java
! src/share/classes/sun/security/ssl/ServerHandshaker.java
! src/share/classes/sun/security/ssl/SunJSSE.java
+ src/share/classes/sun/security/ssl/Utilities.java
! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java
! src/share/classes/sun/security/ssl/X509TrustManagerImpl.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargePacket.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/SSLEngineService.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorer.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerUnmatchedSNI.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerWithCli.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerWithSrv.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketConsistentSNI.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorer.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerFailure.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerMatchedSNI.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerUnmatchedSNI.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerWithCliSNI.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerWithSrvSNI.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketInconsistentSNI.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java
+ test/sun/security/ssl/templates/SSLCapabilities.java
+ test/sun/security/ssl/templates/SSLExplorer.java

Changeset: 27f854a1e5c5
Author:    chegar
Date:      2012-10-19 11:43 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/27f854a1e5c5

8000206: Uninitialized variable in PlainDatagramSocketImpl.c
Reviewed-by: dsamersoff, khazra, chegar
Contributed-by: John Zavgren <john.zavgren at oracle.com>

! src/solaris/native/java/net/PlainDatagramSocketImpl.c

Changeset: 21f1b88e68ce
Author:    xuelei
Date:      2012-10-19 20:36 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/21f1b88e68ce

8000954: Add final keyword to new method in SSLParameters
Reviewed-by: wetmore

! src/share/classes/javax/net/ssl/SSLParameters.java

Changeset: 93303f8a4a8e
Author:    alanb
Date:      2012-10-20 21:07 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/93303f8a4a8e

8000941: Remove ftp from the required list of protocol handlers
Reviewed-by: chegar

! src/share/classes/java/net/ProxySelector.java
! src/share/classes/java/net/URL.java
! src/share/classes/java/net/URLStreamHandler.java
! src/share/classes/java/net/package.html

Changeset: a40b0f51613b
Author:    jjh
Date:      2012-10-20 22:49 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/a40b0f51613b

7197401: Add a subset of the org.objectweb.asm packages to jdk8
Reviewed-by: ohair, briangoetz, erikj, iris

! THIRD_PARTY_README
! make/Makefile
+ make/jdk/Makefile
+ make/jdk/asm/Makefile
+ src/share/classes/jdk/internal/org/objectweb/asm/AnnotationVisitor.java
+ src/share/classes/jdk/internal/org/objectweb/asm/AnnotationWriter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/Attribute.java
+ src/share/classes/jdk/internal/org/objectweb/asm/ByteVector.java
+ src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java
+ src/share/classes/jdk/internal/org/objectweb/asm/ClassVisitor.java
+ src/share/classes/jdk/internal/org/objectweb/asm/ClassWriter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/Edge.java
+ src/share/classes/jdk/internal/org/objectweb/asm/FieldVisitor.java
+ src/share/classes/jdk/internal/org/objectweb/asm/FieldWriter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/Frame.java
+ src/share/classes/jdk/internal/org/objectweb/asm/Handle.java
+ src/share/classes/jdk/internal/org/objectweb/asm/Handler.java
+ src/share/classes/jdk/internal/org/objectweb/asm/Item.java
+ src/share/classes/jdk/internal/org/objectweb/asm/Label.java
+ src/share/classes/jdk/internal/org/objectweb/asm/MethodVisitor.java
+ src/share/classes/jdk/internal/org/objectweb/asm/MethodWriter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java
+ src/share/classes/jdk/internal/org/objectweb/asm/Type.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/AdviceAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/AnalyzerAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/CodeSizeEvaluator.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/GeneratorAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/JSRInlinerAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/LocalVariablesSorter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/Method.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/Remapper.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingAnnotationAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingClassAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingFieldAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingMethodAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingSignatureAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/SerialVersionUIDAdder.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/SimpleRemapper.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/StaticInitMerger.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/TableSwitchGenerator.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/TryCatchBlockSorter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureReader.java
+ src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureVisitor.java
+ src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureWriter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/AbstractInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/AnnotationNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/ClassNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/FieldInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/FieldNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/FrameNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/IincInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/InnerClassNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/InsnList.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/InsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/IntInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/InvokeDynamicInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/JumpInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/LabelNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/LdcInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/LineNumberNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/LocalVariableNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/LookupSwitchInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/MethodInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/MethodNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/MultiANewArrayInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/TableSwitchInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/TryCatchBlockNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/TypeInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/VarInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Analyzer.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/AnalyzerException.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicInterpreter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicValue.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicVerifier.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Frame.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Interpreter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SimpleVerifier.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SmallSet.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SourceInterpreter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SourceValue.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Subroutine.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Value.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/ASMifiable.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/ASMifier.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/CheckAnnotationAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/CheckClassAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/CheckFieldAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/CheckSignatureAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/Printer.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/Textifiable.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/Textifier.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/TraceAnnotationVisitor.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/TraceClassVisitor.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/TraceFieldVisitor.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/TraceMethodVisitor.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/TraceSignatureVisitor.java
! src/share/lib/security/java.security
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
! test/Makefile
+ test/jdk/asm/AsmSanity.java

Changeset: b39ab9c6f4cb
Author:    weijun
Date:      2012-10-22 09:59 +0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/b39ab9c6f4cb

8001204: typo: Unable to obtain Princpal Name for authentication
Reviewed-by: xuelei

! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java

Changeset: e19dc885da0d
Author:    weijun
Date:      2012-10-22 17:01 +0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/e19dc885da0d

8000624: Move MaxRetries.java to ProblemList for the moment
Reviewed-by: alanb

! test/ProblemList.txt

Changeset: 2048ce5a12ff
Author:    twisti
Date:      2012-10-22 14:22 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/2048ce5a12ff

6771058: TEST_BUG: java/lang/ref/Basic.java may fail with -server -Xcomp
Reviewed-by: dholmes, mchung

! test/java/lang/ref/Basic.java

Changeset: a1e77f7ed52b
Author:    weijun
Date:      2012-10-23 10:02 +0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/a1e77f7ed52b

8001208: Fix for KRB5CCNAME not complete
Reviewed-by: xuelei

! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java
! test/sun/security/krb5/ccache/EmptyCC.java

Changeset: 29b58cb8e4fc
Author:    chegar
Date:      2012-10-23 11:57 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/29b58cb8e4fc

8000204: Memory leak in com/sun/security/auth/module/Unix.c
Reviewed-by: dsamersoff, wetmore, khazra, chegar
Contributed-by: John Zavgren <john.zavgren at oracle.com>

! src/solaris/native/com/sun/security/auth/module/Unix.c

Changeset: cdc7f9be3707
Author:    lana
Date:      2012-10-23 09:41 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/cdc7f9be3707

Merge

- src/share/classes/sun/security/tools/CertAndKeyGen.java
- src/share/classes/sun/security/tools/JarSigner.java
- src/share/classes/sun/security/tools/JarSignerResources.java
- src/share/classes/sun/security/tools/JarSignerResources_ja.java
- src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java
- src/share/classes/sun/security/tools/KeyTool.java
- src/share/classes/sun/security/tools/TimestampedSigner.java
- src/windows/classes/java/io/Win32FileSystem.java
- src/windows/native/java/io/Win32FileSystem_md.c
- test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java
- test/com/sun/jndi/ldap/ReadTimeoutTest.java

Changeset: 0582dc4674c9
Author:    wetmore
Date:      2012-05-21 15:42 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/0582dc4674c9

7167656: Multiple Seeders are being created
Reviewed-by: smarks, mduigou, ahgross

! src/share/classes/sun/security/provider/SecureRandom.java

Changeset: b4f35876d9b5
Author:    mullan
Date:      2012-06-08 11:02 -0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/b4f35876d9b5

7163198: Tightened package accessibility
7169887: Tightened package accessibility
Reviewed-by: vinnie, hawtin

! src/share/lib/security/java.security
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows

Changeset: 89a0551b98d8
Author:    weijun
Date:      2012-06-15 09:51 +0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/89a0551b98d8

6631398: FilePermission improved path checking
Reviewed-by: mullan, skoivu, jdn

! src/share/classes/java/io/FilePermission.java

Changeset: 7439e8007e09
Author:    mullan
Date:      2012-06-18 10:00 -0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/7439e8007e09

7172522: Improve DomainCombiner checking
Reviewed-by: vinnie, ahgross

! src/share/classes/java/security/AccessController.java

Changeset: 2a98c51549a8
Author:    smarks
Date:      2012-06-21 00:20 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/2a98c51549a8

7093490: adjust package access in rmiregistry
Reviewed-by: ahgross, coffeys, dmocek

! src/share/classes/sun/rmi/registry/RegistryImpl.java

Changeset: 263f15439f4b
Author:    dsamersoff
Date:      2012-06-22 16:22 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/263f15439f4b

7158796: Tighten properties checking in EnvHelp
Summary: Move getProperty call out of computeBooleanFromString
Reviewed-by: skoivu, sla

! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java
! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java
! src/share/classes/javax/management/remote/rmi/RMIConnector.java
! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java

Changeset: 3a825f6cbc71
Author:    dsamersoff
Date:      2012-06-22 18:19 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/3a825f6cbc71

7169888: Narrowing resource definitions in JMX RMI connector
Summary: CPU bug, we can't put offending calls outside doPrivileged, but narrow granted permissions.
Reviewed-by: ahgross, fparain

! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java

Changeset: 90498c1cc87c
Author:    xuelei
Date:      2012-07-28 19:42 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/90498c1cc87c

7186286: TLS implementation to better adhere to RFC
Summary: also reviewed by Alexander Fomin <Alexander.Fomin at Oracle.COM>, Andrew Gross<Andrew.Gross at Oracle.COM>, Sean Coffey<Sean.Coffey at Oracle.COM>
Reviewed-by: valeriep, wetmore

! src/share/classes/sun/security/ssl/HandshakeInStream.java
! src/share/classes/sun/security/ssl/Handshaker.java
! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java

Changeset: 983c17aecdac
Author:    mullan
Date:      2012-08-15 15:31 -0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/983c17aecdac

7189490: More improvements to DomainCombiner checking
Reviewed-by: ahgross, jdn, vinnie

! src/share/classes/java/security/AccessController.java

Changeset: 6cc28cc213b6
Author:    chegar
Date:      2012-08-16 15:02 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/6cc28cc213b6

7189103: Executors needs to maintain state
Reviewed-by: dholmes, hawtin

! src/share/classes/java/util/concurrent/Executors.java

Changeset: a09b9ebb61b6
Author:    chegar
Date:      2012-08-29 14:05 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/a09b9ebb61b6

7189567: java net obselete protocol
Reviewed-by: alanb, ahgross

! make/sun/net/FILES_java.gmk
- src/share/classes/sun/net/www/protocol/gopher/GopherClient.java
- src/share/classes/sun/net/www/protocol/gopher/Handler.java
! test/java/net/URL/Test.java

Changeset: 2ac636f46c5b
Author:    alanb
Date:      2012-09-08 20:31 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/2ac636f46c5b

7169884: LogManager checks do not work correctly for sub-types
Reviewed-by: mchung, ahgross

! src/share/classes/java/util/logging/FileHandler.java
! src/share/classes/java/util/logging/Handler.java
! src/share/classes/java/util/logging/LogManager.java
! src/share/classes/java/util/logging/Logger.java
! src/share/classes/java/util/logging/MemoryHandler.java
! src/share/classes/java/util/logging/StreamHandler.java

Changeset: 4488ea026532
Author:    asaha
Date:      2012-09-08 22:23 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/4488ea026532

Merge


Changeset: e869a8513cb7
Author:    smarks
Date:      2012-09-10 16:05 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/e869a8513cb7

7195919: (sl) ServiceLoader can throw CCE without needing to create instance
Reviewed-by: ahgross, alanb, dmeetry

! src/share/classes/java/util/ServiceLoader.java
! src/share/classes/sun/misc/Service.java

Changeset: 9a7e2fa3c9c5
Author:    malenkov
Date:      2012-09-11 12:57 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/9a7e2fa3c9c5

7195549: Better bean object persistence
Reviewed-by: art, ahgross

! src/share/classes/com/sun/beans/decoder/PropertyElementHandler.java

Changeset: 1d1fcf0c1ce8
Author:    rupashka
Date:      2012-09-11 15:59 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/1d1fcf0c1ce8

7195194: Better data validation for Swing
Reviewed-by: art, ahgross

! src/share/classes/javax/swing/text/DefaultFormatter.java

Changeset: 3b49bd3c392b
Author:    malenkov
Date:      2012-09-19 21:42 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/3b49bd3c392b

7195917: XMLDecoder parsing at close-time should be improved
Reviewed-by: art, ahgross

! src/share/classes/com/sun/beans/decoder/DocumentHandler.java
! src/share/classes/java/beans/XMLDecoder.java

Changeset: 762eee5e6e16
Author:    jrose
Date:      2012-09-20 14:02 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/762eee5e6e16

7196190: Improve method of handling MethodHandles
Summary: Bind callers to caller-sensitive methods.
Reviewed-by: twisti, jjh, vlivanov, ahgross

! src/share/classes/java/lang/invoke/MethodHandleImpl.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/sun/invoke/anon/AnonymousClassLoader.java
! src/share/classes/sun/invoke/util/ValueConversions.java
+ test/java/lang/invoke/7196190/ClassForNameTest.java
+ test/java/lang/invoke/7196190/GetUnsafeTest.java
+ test/java/lang/invoke/7196190/MHProxyTest.java
+ test/java/lang/invoke/7196190/jtreg.security.policy

Changeset: e113ffde452a
Author:    dsamersoff
Date:      2012-09-24 16:15 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/e113ffde452a

7198296: Problem with classloader in JMX
Summary: wb classes have to be available for hotspot tests
Reviewed-by: ahgross, asaha
Contributed-by: frederic.parain at oracle.com, daniel.fuchs at oracle.com, jean-francois.denise at oracle.com

! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java

Changeset: ca79b33a0731
Author:    dsamersoff
Date:      2012-09-24 17:00 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/ca79b33a0731

7192975: Issue with JMX reflection
Summary: Make security check unconditional
Reviewed-by: ahgross, asaha
Contributed-by: jaroslav.bachorik at oracle.com

! src/share/classes/javax/management/modelmbean/DescriptorSupport.java

Changeset: 74eec13c464e
Author:    asaha
Date:      2012-09-25 11:48 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/74eec13c464e

Merge

- make/common/Defs-embedded.gmk
- make/common/Release-embedded.gmk

Changeset: e4ce54b79bb4
Author:    asaha
Date:      2012-10-10 14:31 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/e4ce54b79bb4

Merge

- src/macosx/classes/sun/awt/SunToolkitSubclass.java
! src/share/classes/java/io/FilePermission.java
- src/share/classes/sun/management/LockDataConverter.java
- src/share/classes/sun/management/LockDataConverterMXBean.java
- src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java
- src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java
- test/sun/misc/URLClassPath/ClassnameCharTest.sh
- test/sun/net/www/httptest/HttpServer.java
- test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java

Changeset: 28fe37b50e3c
Author:    asaha
Date:      2012-10-11 15:30 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/28fe37b50e3c

Merge


Changeset: d3b3fea7d1d7
Author:    asaha
Date:      2012-10-18 22:01 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/d3b3fea7d1d7

Merge

! src/share/classes/java/io/FilePermission.java
! src/share/classes/java/util/ServiceLoader.java
- src/share/classes/sun/util/xml/XMLUtils.java
- src/share/test/pack200/pack.conf

Changeset: e6fbbb2c610d
Author:    lana
Date:      2012-10-23 11:29 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/e6fbbb2c610d

Merge

! src/share/classes/java/util/ServiceLoader.java
! src/share/classes/java/util/logging/LogManager.java
- src/share/classes/sun/net/www/protocol/gopher/GopherClient.java
- src/share/classes/sun/net/www/protocol/gopher/Handler.java
! src/share/classes/sun/security/ssl/HandshakeInStream.java
! src/share/classes/sun/security/ssl/Handshaker.java
! src/share/lib/security/java.security
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows

Changeset: dfd509da3da6
Author:    lana
Date:      2012-10-25 20:32 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/dfd509da3da6

Merge

! make/common/Release.gmk
! src/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/share/classes/java/lang/invoke/MethodHandleStatics.java
! src/share/classes/sun/invoke/util/ValueConversions.java
- src/share/classes/sun/net/www/protocol/gopher/GopherClient.java
- src/share/classes/sun/net/www/protocol/gopher/Handler.java
- src/share/classes/sun/security/tools/CertAndKeyGen.java
- src/share/classes/sun/security/tools/JarSigner.java
- src/share/classes/sun/security/tools/JarSignerResources.java
- src/share/classes/sun/security/tools/JarSignerResources_ja.java
- src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java
- src/share/classes/sun/security/tools/KeyTool.java
- src/share/classes/sun/security/tools/TimestampedSigner.java
- src/windows/classes/java/io/Win32FileSystem.java
- src/windows/native/java/io/Win32FileSystem_md.c
! test/ProblemList.txt
- test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java
- test/com/sun/jndi/ldap/ReadTimeoutTest.java

Changeset: f117a3e06f78
Author:    katleman
Date:      2012-10-31 18:35 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/f117a3e06f78

Merge

! makefiles/CompileLaunchers.gmk
! makefiles/CompileNativeLibraries.gmk
! makefiles/CreateJars.gmk
- makefiles/docs/CORE_PKGS.gmk
- makefiles/docs/Makefile
- makefiles/docs/NON_CORE_PKGS.gmk
- makefiles/docs/Notes.html
- makefiles/mapfiles/launchers/mapfile-amd64
- makefiles/mapfiles/launchers/mapfile-i586
- makefiles/mapfiles/libawt_headless/reorder-i586
- makefiles/mapfiles/libjava/reorder-i586
- makefiles/mapfiles/libjpeg/reorder-i586
- makefiles/mapfiles/libnio/mapfile-bsd
- makefiles/mapfiles/libnio/reorder-i586
- makefiles/mapfiles/libverify/reorder-i586
- makefiles/mapfiles/libzip/reorder-i586
- makefiles/sun/xawt/ToBin.java

Changeset: 1910cdfe2ca9
Author:    erikj
Date:      2012-11-02 12:07 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/1910cdfe2ca9

Merge

! make/Makefile
! make/common/Release.gmk
! makefiles/CompileLaunchers.gmk
! makefiles/CompileNativeLibraries.gmk
! makefiles/CreateJars.gmk
! makefiles/GensrcX11Wrappers.gmk
! makefiles/mapfiles/libnio/mapfile-macosx
- src/share/classes/sun/net/www/protocol/gopher/GopherClient.java
- src/share/classes/sun/net/www/protocol/gopher/Handler.java
- src/share/classes/sun/security/tools/CertAndKeyGen.java
- src/share/classes/sun/security/tools/JarSigner.java
- src/share/classes/sun/security/tools/JarSignerResources.java
- src/share/classes/sun/security/tools/JarSignerResources_ja.java
- src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java
- src/share/classes/sun/security/tools/KeyTool.java
- src/share/classes/sun/security/tools/TimestampedSigner.java
- src/windows/classes/java/io/Win32FileSystem.java
- src/windows/native/java/io/Win32FileSystem_md.c
- test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java
- test/com/sun/jndi/ldap/ReadTimeoutTest.java

Changeset: 13657091667a
Author:    erikj
Date:      2012-11-02 13:03 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/13657091667a

8002184: Fixed exclude and includes for jarsigner in new build.

! makefiles/CreateJars.gmk



From fredrik.ohrstrom at oracle.com  Fri Nov  2 06:56:56 2012
From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com)
Date: Fri, 02 Nov 2012 13:56:56 +0000
Subject: hg: build-infra/jdk8/langtools: Synced with jdk8/tl/langtools
Message-ID: <20121102135700.210C047736@hg.openjdk.java.net>

Changeset: f6b12bc96897
Author:    ohrstrom
Date:      2012-11-02 14:55 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/langtools/rev/f6b12bc96897

Synced with jdk8/tl/langtools

! make/tools/genstubs/GenStubs.java
! src/share/classes/com/sun/javadoc/SerialFieldTag.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/Comment.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocument.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/ClassWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java
- src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DirectoryManager.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFile.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocLink.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPath.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletConstants.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java
- src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourcePath.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java
! src/share/classes/com/sun/tools/javac/code/Attribute.java
! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/code/Kinds.java
! src/share/classes/com/sun/tools/javac/code/Lint.java
! src/share/classes/com/sun/tools/javac/code/Printer.java
! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/code/Type.java
+ src/share/classes/com/sun/tools/javac/code/TypeTag.java
- src/share/classes/com/sun/tools/javac/code/TypeTags.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Annotate.java
! 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/ConstFold.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Enter.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
+ src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java
! src/share/classes/com/sun/tools/javac/file/Locations.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/jvm/UninitializedType.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javac/model/JavacElements.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/share/classes/com/sun/tools/javac/tree/Pretty.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java
! src/share/classes/com/sun/tools/javac/util/Constants.java
! src/share/classes/com/sun/tools/javac/util/Names.java
! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java
! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java
! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java
! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java
! src/share/classes/com/sun/tools/javadoc/ParameterizedTypeImpl.java
! src/share/classes/com/sun/tools/javadoc/SerializedForm.java
! src/share/classes/com/sun/tools/javadoc/TypeMaker.java
! src/share/classes/com/sun/tools/javah/JavahFileManager.java
! src/share/classes/com/sun/tools/javah/JavahTask.java
! src/share/classes/com/sun/tools/javap/JavapFileManager.java



From vincent.x.ryan at oracle.com  Fri Nov  2 09:38:44 2012
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Fri, 2 Nov 2012 16:38:44 +0000
Subject: New builds from the build-infra team
References: <70C78781-9057-4B6C-9F80-E39F637A9AD5@oracle.com>
Message-ID: <4E118E25-D6AB-4C7E-9CF9-56495CBB5B92@oracle.com>

> From: Vincent Ryan <vincent.x.ryan at oracle.com>
> Subject: Re: New builds from the build-infra team
> Date: 2 November 2012 15:48:03 GMT
> To: build-infra-dev at openjdk.java.net
> 
> I tried this out on the latest Solaris 11 Update 1 (sparc) but the build encountered problems locating libc when
> building jdk. (BTW the old build works correctly, just slower)
> 
> :
> :
> strerror                            /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
> vfprintf                            /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_error.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
> fprintf                             /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_init.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
> gethrvtime                          /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
> ld: fatal: symbol referencing errors. No output written to /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so
> gmake[3]: *** [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so] Error 1
> gmake[3]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
> gmake[2]: *** [libs-only] Error 2
> gmake[2]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
> make[1]: *** [jdk-only] Error 2
> make[1]: Leaving directory `/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release'
> make: *** [all] Error 2
> t4%
> 
> 
> 
> 
> FYI I've attached the config script that was generated by configure.sh.
> 
> 
> 
> 
> On 1 Nov 2012, at 18:38, Kelly O'Hair wrote:
> 
>> 
>> Pardon the wide email, but this impacts everyone building the OpenJDK jdk8/jdk8 derived forests.
>> 
>> Please only reply to the build-infra-dev mailing list, or just me.
>> 
>> With some recent integrations from the build-infra project into jdk8/jdk8 repositories, the build-infra team
>> would like to get more exposure of the new builds. These jdk8/jdk8 changes will start showing up in various
>> jdk8 and team forests over the next few weeks. The default is still the old builds, but both builds work in most
>> cases for OpenJDK as far as we know.
>> 
>> At a very high level, the intent is that once you get a forest:
>> hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>> cd j8
>> sh ./get_source.sh
>> 
>> You should be able to simply configure&&make (the ultimate goal is this simple anyway), e.g.
>>  sh ./configure
>>  make NEWBUILD=true     # The NEWBUILD=true will become the default when we formally switch.
>> 
>> Where "make" is GNU make 3.81, and your system has all the requires packages and PATH contains the
>> needed tools. Note that on Windows, MKS unix utilities cannot be used with the new builds, just CYGWIN
>> is recommended at this time.
>> 
>> Of course, we know, it's never as easy as a simple configure&&make, and often you will need to pass in
>> configure options.
>> 
>> What we would like to know is where a simple configure&&make does not work, and anything people had
>> to do to make it work.
>> 
>> I know many of you are quite used to the old builds, so I have a temporary  "bridgeBuild" target
>> people can try that will attempt to map the ALT_* environment variables to an appropriate configure command
>> and then run that configure command and do the build, e.g.
>> 
>> make NEWBUILD=true bridgeBuild
>> 
>> People willing to do comparisons between the old and new builds could:
>> rm -f -r build
>> time make NEWBUILD=true bridgeBuild
>> rm -f -r build
>> time make NO_DOCS=true     # Old builds do not generate javadocs by default
>> 
>> Any observations about speed of the builds would be appreciated, as will any impressions on what you see.
>> 
>> At this time, we think this is working pretty well with a few caveats:
>> * GNU make with the new builds is doing much more parallel processing and this can stress out a system
>>   - Use "make JOBS=1" if you suspect a problem, then try adjusting it up slowly.
>> * Partial builds are limited, right now full builds of the entire OpenJDK is the target
>>   - Hotspot can still be built on it's own, but everyone else needs to build hotspot at least once
>> * Paths with multiple names can cause problems, e.g. being on system svc6, and access an exported share
>>   area as /net/svc6/export/foobar  instead of /export/foobar  will cause problems. Use local paths.
>> 
>> We know there are still issues and we will be focusing heavily on the critical ones in the next few weeks, but
>> we do need the community to tell us what the critical issues really are.
>> 
>> Our number one priority at this time is that everyone that was able to build the old way, should be able to build
>> with the new build-infra makefiles. Please help us verify that.
>> 
>> -kto
>> 
> 



From kelly.ohair at oracle.com  Fri Nov  2 10:45:21 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Fri, 2 Nov 2012 10:45:21 -0700
Subject: New builds from the build-infra team
In-Reply-To: <4E118E25-D6AB-4C7E-9CF9-56495CBB5B92@oracle.com>
References: <70C78781-9057-4B6C-9F80-E39F637A9AD5@oracle.com>
	<4E118E25-D6AB-4C7E-9CF9-56495CBB5B92@oracle.com>
Message-ID: <DBF14695-B54B-4092-A420-1B12D11D19A6@oracle.com>

The attachment is missing.

This looks like the  -lc   is missing from the creation of hprof, we should never let libc be an implicit dependency.

I wonder if Solaris 11.1 has tightened up the rules on implicit dependencies. We have not seen this on Solaris 10.
We just got svc6 setup as a 11.1 system, I'll see if it reproduces there.

And thank you for reporting this. Although Solaris 11.1 is not one of our critical systems, it's very important that this works.

-kto

On Nov 2, 2012, at 9:38 AM, Vincent Ryan wrote:

>> From: Vincent Ryan <vincent.x.ryan at oracle.com>
>> Subject: Re: New builds from the build-infra team
>> Date: 2 November 2012 15:48:03 GMT
>> To: build-infra-dev at openjdk.java.net
>> 
>> I tried this out on the latest Solaris 11 Update 1 (sparc) but the build encountered problems locating libc when
>> building jdk. (BTW the old build works correctly, just slower)
>> 
>> :
>> :
>> strerror                            /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>> vfprintf                            /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_error.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>> fprintf                             /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_init.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>> gethrvtime                          /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>> ld: fatal: symbol referencing errors. No output written to /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so
>> gmake[3]: *** [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so] Error 1
>> gmake[3]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>> gmake[2]: *** [libs-only] Error 2
>> gmake[2]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>> make[1]: *** [jdk-only] Error 2
>> make[1]: Leaving directory `/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release'
>> make: *** [all] Error 2
>> t4%
>> 
>> 
>> 
>> 
>> FYI I've attached the config script that was generated by configure.sh.
>> 
>> 
>> 
>> 
>> On 1 Nov 2012, at 18:38, Kelly O'Hair wrote:
>> 
>>> 
>>> Pardon the wide email, but this impacts everyone building the OpenJDK jdk8/jdk8 derived forests.
>>> 
>>> Please only reply to the build-infra-dev mailing list, or just me.
>>> 
>>> With some recent integrations from the build-infra project into jdk8/jdk8 repositories, the build-infra team
>>> would like to get more exposure of the new builds. These jdk8/jdk8 changes will start showing up in various
>>> jdk8 and team forests over the next few weeks. The default is still the old builds, but both builds work in most
>>> cases for OpenJDK as far as we know.
>>> 
>>> At a very high level, the intent is that once you get a forest:
>>> hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>>> cd j8
>>> sh ./get_source.sh
>>> 
>>> You should be able to simply configure&&make (the ultimate goal is this simple anyway), e.g.
>>> sh ./configure
>>> make NEWBUILD=true     # The NEWBUILD=true will become the default when we formally switch.
>>> 
>>> Where "make" is GNU make 3.81, and your system has all the requires packages and PATH contains the
>>> needed tools. Note that on Windows, MKS unix utilities cannot be used with the new builds, just CYGWIN
>>> is recommended at this time.
>>> 
>>> Of course, we know, it's never as easy as a simple configure&&make, and often you will need to pass in
>>> configure options.
>>> 
>>> What we would like to know is where a simple configure&&make does not work, and anything people had
>>> to do to make it work.
>>> 
>>> I know many of you are quite used to the old builds, so I have a temporary  "bridgeBuild" target
>>> people can try that will attempt to map the ALT_* environment variables to an appropriate configure command
>>> and then run that configure command and do the build, e.g.
>>> 
>>> make NEWBUILD=true bridgeBuild
>>> 
>>> People willing to do comparisons between the old and new builds could:
>>> rm -f -r build
>>> time make NEWBUILD=true bridgeBuild
>>> rm -f -r build
>>> time make NO_DOCS=true     # Old builds do not generate javadocs by default
>>> 
>>> Any observations about speed of the builds would be appreciated, as will any impressions on what you see.
>>> 
>>> At this time, we think this is working pretty well with a few caveats:
>>> * GNU make with the new builds is doing much more parallel processing and this can stress out a system
>>>  - Use "make JOBS=1" if you suspect a problem, then try adjusting it up slowly.
>>> * Partial builds are limited, right now full builds of the entire OpenJDK is the target
>>>  - Hotspot can still be built on it's own, but everyone else needs to build hotspot at least once
>>> * Paths with multiple names can cause problems, e.g. being on system svc6, and access an exported share
>>>  area as /net/svc6/export/foobar  instead of /export/foobar  will cause problems. Use local paths.
>>> 
>>> We know there are still issues and we will be focusing heavily on the critical ones in the next few weeks, but
>>> we do need the community to tell us what the critical issues really are.
>>> 
>>> Our number one priority at this time is that everyone that was able to build the old way, should be able to build
>>> with the new build-infra makefiles. Please help us verify that.
>>> 
>>> -kto
>>> 
>> 
> 



From vincent.x.ryan at oracle.com  Fri Nov  2 11:17:20 2012
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Fri, 2 Nov 2012 18:17:20 +0000
Subject: New builds from the build-infra team
In-Reply-To: <DBF14695-B54B-4092-A420-1B12D11D19A6@oracle.com>
References: <70C78781-9057-4B6C-9F80-E39F637A9AD5@oracle.com>
	<4E118E25-D6AB-4C7E-9CF9-56495CBB5B92@oracle.com>
	<DBF14695-B54B-4092-A420-1B12D11D19A6@oracle.com>
Message-ID: <A7D41D1F-A00C-4041-9609-AB987F0CEDB0@oracle.com>

That attachment got dropped when I re-sent my message (previously I wasn't a member of the build-infra-dev email alias). I've attached it again in case it proves useful.

-------------- next part --------------



I realize Solaris 11 is not an official build platform for JDK8 but I thought I'd give it a spin on a reasonably
beefy server.
Thanks.


On 2 Nov 2012, at 17:45, Kelly O'Hair wrote:

> The attachment is missing.
> 
> This looks like the  -lc   is missing from the creation of hprof, we should never let libc be an implicit dependency.
> 
> I wonder if Solaris 11.1 has tightened up the rules on implicit dependencies. We have not seen this on Solaris 10.
> We just got svc6 setup as a 11.1 system, I'll see if it reproduces there.
> 
> And thank you for reporting this. Although Solaris 11.1 is not one of our critical systems, it's very important that this works.
> 
> -kto
> 
> On Nov 2, 2012, at 9:38 AM, Vincent Ryan wrote:
> 
>>> From: Vincent Ryan <vincent.x.ryan at oracle.com>
>>> Subject: Re: New builds from the build-infra team
>>> Date: 2 November 2012 15:48:03 GMT
>>> To: build-infra-dev at openjdk.java.net
>>> 
>>> I tried this out on the latest Solaris 11 Update 1 (sparc) but the build encountered problems locating libc when
>>> building jdk. (BTW the old build works correctly, just slower)
>>> 
>>> :
>>> :
>>> strerror                            /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>> vfprintf                            /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_error.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>> fprintf                             /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_init.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>> gethrvtime                          /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>> ld: fatal: symbol referencing errors. No output written to /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so
>>> gmake[3]: *** [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so] Error 1
>>> gmake[3]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>> gmake[2]: *** [libs-only] Error 2
>>> gmake[2]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>> make[1]: *** [jdk-only] Error 2
>>> make[1]: Leaving directory `/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release'
>>> make: *** [all] Error 2
>>> t4%
>>> 
>>> 
>>> 
>>> 
>>> FYI I've attached the config script that was generated by configure.sh.
>>> 
>>> 
>>> 
>>> 
>>> On 1 Nov 2012, at 18:38, Kelly O'Hair wrote:
>>> 
>>>> 
>>>> Pardon the wide email, but this impacts everyone building the OpenJDK jdk8/jdk8 derived forests.
>>>> 
>>>> Please only reply to the build-infra-dev mailing list, or just me.
>>>> 
>>>> With some recent integrations from the build-infra project into jdk8/jdk8 repositories, the build-infra team
>>>> would like to get more exposure of the new builds. These jdk8/jdk8 changes will start showing up in various
>>>> jdk8 and team forests over the next few weeks. The default is still the old builds, but both builds work in most
>>>> cases for OpenJDK as far as we know.
>>>> 
>>>> At a very high level, the intent is that once you get a forest:
>>>> hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>>>> cd j8
>>>> sh ./get_source.sh
>>>> 
>>>> You should be able to simply configure&&make (the ultimate goal is this simple anyway), e.g.
>>>> sh ./configure
>>>> make NEWBUILD=true     # The NEWBUILD=true will become the default when we formally switch.
>>>> 
>>>> Where "make" is GNU make 3.81, and your system has all the requires packages and PATH contains the
>>>> needed tools. Note that on Windows, MKS unix utilities cannot be used with the new builds, just CYGWIN
>>>> is recommended at this time.
>>>> 
>>>> Of course, we know, it's never as easy as a simple configure&&make, and often you will need to pass in
>>>> configure options.
>>>> 
>>>> What we would like to know is where a simple configure&&make does not work, and anything people had
>>>> to do to make it work.
>>>> 
>>>> I know many of you are quite used to the old builds, so I have a temporary  "bridgeBuild" target
>>>> people can try that will attempt to map the ALT_* environment variables to an appropriate configure command
>>>> and then run that configure command and do the build, e.g.
>>>> 
>>>> make NEWBUILD=true bridgeBuild
>>>> 
>>>> People willing to do comparisons between the old and new builds could:
>>>> rm -f -r build
>>>> time make NEWBUILD=true bridgeBuild
>>>> rm -f -r build
>>>> time make NO_DOCS=true     # Old builds do not generate javadocs by default
>>>> 
>>>> Any observations about speed of the builds would be appreciated, as will any impressions on what you see.
>>>> 
>>>> At this time, we think this is working pretty well with a few caveats:
>>>> * GNU make with the new builds is doing much more parallel processing and this can stress out a system
>>>> - Use "make JOBS=1" if you suspect a problem, then try adjusting it up slowly.
>>>> * Partial builds are limited, right now full builds of the entire OpenJDK is the target
>>>> - Hotspot can still be built on it's own, but everyone else needs to build hotspot at least once
>>>> * Paths with multiple names can cause problems, e.g. being on system svc6, and access an exported share
>>>> area as /net/svc6/export/foobar  instead of /export/foobar  will cause problems. Use local paths.
>>>> 
>>>> We know there are still issues and we will be focusing heavily on the critical ones in the next few weeks, but
>>>> we do need the community to tell us what the critical issues really are.
>>>> 
>>>> Our number one priority at this time is that everyone that was able to build the old way, should be able to build
>>>> with the new build-infra makefiles. Please help us verify that.
>>>> 
>>>> -kto
>>>> 
>>> 
>> 
> 


From kelly.ohair at oracle.com  Fri Nov  2 11:38:16 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Fri, 2 Nov 2012 11:38:16 -0700
Subject: New builds from the build-infra team
In-Reply-To: <A7D41D1F-A00C-4041-9609-AB987F0CEDB0@oracle.com>
References: <70C78781-9057-4B6C-9F80-E39F637A9AD5@oracle.com>
	<4E118E25-D6AB-4C7E-9CF9-56495CBB5B92@oracle.com>
	<DBF14695-B54B-4092-A420-1B12D11D19A6@oracle.com>
	<A7D41D1F-A00C-4041-9609-AB987F0CEDB0@oracle.com>
Message-ID: <28B38282-EFD5-46EF-B5BE-57A6110DFC51@oracle.com>


On Nov 2, 2012, at 11:17 AM, Vincent Ryan wrote:

> That attachment got dropped when I re-sent my message (previously I wasn't a member of the build-infra-dev email alias). I've attached it again in case it proves useful.
> 
> <config.status>
> 
> 
> I realize Solaris 11 is not an official build platform for JDK8 but I thought I'd give it a spin on a reasonably
> beefy server.

It's great that you tried this, thanks.

As far as I can tell, this seems to be a sparcv9 Solaris 11.1 issue, because I tried Solaris 11.1 X64 and it worked fine.
However, the link of libhprof.so IS missing the -lc option.
So why sparcv9 would complain and amd64 would not is a bit puzzling.

The change I think needs to be made is:

diff --git a/makefiles/CompileNativeLibraries.gmk b/makefiles/CompileNativeLibraries.gmk
--- a/makefiles/CompileNativeLibraries.gmk
+++ b/makefiles/CompileNativeLibraries.gmk
@@ -1807,7 +1807,7 @@
 BUILD_LIBHPROF_LDFLAGS:=
 
 ifeq ($(OPENJDK_TARGET_OS),solaris)
-     BUILD_LIBHPROF_LDFLAGS += -lsocket -lnsl
+     BUILD_LIBHPROF_LDFLAGS += -lsocket -lnsl -lc
 endif
 
 LIBHPROF_OPTIMIZATION:=HIGHEST



But I have not tested it yet.
Did you want to give this patch a spin?

-kto

> Thanks.
> 
> 
> On 2 Nov 2012, at 17:45, Kelly O'Hair wrote:
> 
>> The attachment is missing.
>> 
>> This looks like the  -lc   is missing from the creation of hprof, we should never let libc be an implicit dependency.
>> 
>> I wonder if Solaris 11.1 has tightened up the rules on implicit dependencies. We have not seen this on Solaris 10.
>> We just got svc6 setup as a 11.1 system, I'll see if it reproduces there.
>> 
>> And thank you for reporting this. Although Solaris 11.1 is not one of our critical systems, it's very important that this works.
>> 
>> -kto
>> 
>> On Nov 2, 2012, at 9:38 AM, Vincent Ryan wrote:
>> 
>>>> From: Vincent Ryan <vincent.x.ryan at oracle.com>
>>>> Subject: Re: New builds from the build-infra team
>>>> Date: 2 November 2012 15:48:03 GMT
>>>> To: build-infra-dev at openjdk.java.net
>>>> 
>>>> I tried this out on the latest Solaris 11 Update 1 (sparc) but the build encountered problems locating libc when
>>>> building jdk. (BTW the old build works correctly, just slower)
>>>> 
>>>> :
>>>> :
>>>> strerror                            /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>> vfprintf                            /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_error.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>> fprintf                             /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_init.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>> gethrvtime                          /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>> ld: fatal: symbol referencing errors. No output written to /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so
>>>> gmake[3]: *** [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so] Error 1
>>>> gmake[3]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>> gmake[2]: *** [libs-only] Error 2
>>>> gmake[2]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>> make[1]: *** [jdk-only] Error 2
>>>> make[1]: Leaving directory `/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release'
>>>> make: *** [all] Error 2
>>>> t4%
>>>> 
>>>> 
>>>> 
>>>> 
>>>> FYI I've attached the config script that was generated by configure.sh.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 1 Nov 2012, at 18:38, Kelly O'Hair wrote:
>>>> 
>>>>> 
>>>>> Pardon the wide email, but this impacts everyone building the OpenJDK jdk8/jdk8 derived forests.
>>>>> 
>>>>> Please only reply to the build-infra-dev mailing list, or just me.
>>>>> 
>>>>> With some recent integrations from the build-infra project into jdk8/jdk8 repositories, the build-infra team
>>>>> would like to get more exposure of the new builds. These jdk8/jdk8 changes will start showing up in various
>>>>> jdk8 and team forests over the next few weeks. The default is still the old builds, but both builds work in most
>>>>> cases for OpenJDK as far as we know.
>>>>> 
>>>>> At a very high level, the intent is that once you get a forest:
>>>>> hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>>>>> cd j8
>>>>> sh ./get_source.sh
>>>>> 
>>>>> You should be able to simply configure&&make (the ultimate goal is this simple anyway), e.g.
>>>>> sh ./configure
>>>>> make NEWBUILD=true     # The NEWBUILD=true will become the default when we formally switch.
>>>>> 
>>>>> Where "make" is GNU make 3.81, and your system has all the requires packages and PATH contains the
>>>>> needed tools. Note that on Windows, MKS unix utilities cannot be used with the new builds, just CYGWIN
>>>>> is recommended at this time.
>>>>> 
>>>>> Of course, we know, it's never as easy as a simple configure&&make, and often you will need to pass in
>>>>> configure options.
>>>>> 
>>>>> What we would like to know is where a simple configure&&make does not work, and anything people had
>>>>> to do to make it work.
>>>>> 
>>>>> I know many of you are quite used to the old builds, so I have a temporary  "bridgeBuild" target
>>>>> people can try that will attempt to map the ALT_* environment variables to an appropriate configure command
>>>>> and then run that configure command and do the build, e.g.
>>>>> 
>>>>> make NEWBUILD=true bridgeBuild
>>>>> 
>>>>> People willing to do comparisons between the old and new builds could:
>>>>> rm -f -r build
>>>>> time make NEWBUILD=true bridgeBuild
>>>>> rm -f -r build
>>>>> time make NO_DOCS=true     # Old builds do not generate javadocs by default
>>>>> 
>>>>> Any observations about speed of the builds would be appreciated, as will any impressions on what you see.
>>>>> 
>>>>> At this time, we think this is working pretty well with a few caveats:
>>>>> * GNU make with the new builds is doing much more parallel processing and this can stress out a system
>>>>> - Use "make JOBS=1" if you suspect a problem, then try adjusting it up slowly.
>>>>> * Partial builds are limited, right now full builds of the entire OpenJDK is the target
>>>>> - Hotspot can still be built on it's own, but everyone else needs to build hotspot at least once
>>>>> * Paths with multiple names can cause problems, e.g. being on system svc6, and access an exported share
>>>>> area as /net/svc6/export/foobar  instead of /export/foobar  will cause problems. Use local paths.
>>>>> 
>>>>> We know there are still issues and we will be focusing heavily on the critical ones in the next few weeks, but
>>>>> we do need the community to tell us what the critical issues really are.
>>>>> 
>>>>> Our number one priority at this time is that everyone that was able to build the old way, should be able to build
>>>>> with the new build-infra makefiles. Please help us verify that.
>>>>> 
>>>>> -kto
>>>>> 
>>>> 
>>> 
>> 
> 



From vincent.x.ryan at oracle.com  Fri Nov  2 13:08:04 2012
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Fri, 02 Nov 2012 20:08:04 +0000
Subject: New builds from the build-infra team
In-Reply-To: <28B38282-EFD5-46EF-B5BE-57A6110DFC51@oracle.com>
References: <70C78781-9057-4B6C-9F80-E39F637A9AD5@oracle.com>
	<4E118E25-D6AB-4C7E-9CF9-56495CBB5B92@oracle.com>
	<DBF14695-B54B-4092-A420-1B12D11D19A6@oracle.com>
	<A7D41D1F-A00C-4041-9609-AB987F0CEDB0@oracle.com>
	<28B38282-EFD5-46EF-B5BE-57A6110DFC51@oracle.com>
Message-ID: <50942824.1000102@oracle.com>

Thanks Kelly.

I re-ran the build with your patch and got better results but there
seems to be another linker problem later in the jdk build.

Here's the tail of the build output:

  :
  :
Undefined                       first referenced
  symbol                             in file
free 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
__iob 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
abort 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
snprintf 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
calloc 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
malloc 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
memcpy 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
memset 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
strcmp 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
strlen 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
realloc 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
strncmp 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
fprintf 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
ld: fatal: symbol referencing errors. No output written to 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libjava_crw_demo.so
gmake[3]: *** 
[/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libjava_crw_demo.so] 
Error 1
gmake[3]: *** Waiting for unfinished jobs....
Undefined                       first referenced
  symbol                             in file
exit 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
free 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
__iob 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
abort 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
iconv 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
__ctype 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
iconv_open 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
calloc 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
memcpy 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
strcmp 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
strdup 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
strlen 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
nl_langinfo 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
sprintf 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
setlocale 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
iconv_close 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
fprintf 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
ld: fatal: symbol referencing errors. No output written to 
/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libnpt.so
gmake[3]: *** 
[/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libnpt.so] 
Error 1
gmake[3]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
gmake[2]: *** [libs-only] Error 2
gmake[2]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
make[1]: *** [jdk-only] Error 2
make[1]: Leaving directory 
`/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release'
make: *** [all] Error 2
t4%





On 02/11/2012 18:38, Kelly O'Hair wrote:
>
> On Nov 2, 2012, at 11:17 AM, Vincent Ryan wrote:
>
>> That attachment got dropped when I re-sent my message (previously I wasn't a member of the build-infra-dev email alias). I've attached it again in case it proves useful.
>>
>> <config.status>
>>
>>
>> I realize Solaris 11 is not an official build platform for JDK8 but I thought I'd give it a spin on a reasonably
>> beefy server.
>
> It's great that you tried this, thanks.
>
> As far as I can tell, this seems to be a sparcv9 Solaris 11.1 issue, because I tried Solaris 11.1 X64 and it worked fine.
> However, the link of libhprof.so IS missing the -lc option.
> So why sparcv9 would complain and amd64 would not is a bit puzzling.
>
> The change I think needs to be made is:
>
> diff --git a/makefiles/CompileNativeLibraries.gmk b/makefiles/CompileNativeLibraries.gmk
> --- a/makefiles/CompileNativeLibraries.gmk
> +++ b/makefiles/CompileNativeLibraries.gmk
> @@ -1807,7 +1807,7 @@
>   BUILD_LIBHPROF_LDFLAGS:=
>
>   ifeq ($(OPENJDK_TARGET_OS),solaris)
> -     BUILD_LIBHPROF_LDFLAGS += -lsocket -lnsl
> +     BUILD_LIBHPROF_LDFLAGS += -lsocket -lnsl -lc
>   endif
>
>   LIBHPROF_OPTIMIZATION:=HIGHEST
>
>
>
> But I have not tested it yet.
> Did you want to give this patch a spin?
>
> -kto
>
>> Thanks.
>>
>>
>> On 2 Nov 2012, at 17:45, Kelly O'Hair wrote:
>>
>>> The attachment is missing.
>>>
>>> This looks like the  -lc   is missing from the creation of hprof, we should never let libc be an implicit dependency.
>>>
>>> I wonder if Solaris 11.1 has tightened up the rules on implicit dependencies. We have not seen this on Solaris 10.
>>> We just got svc6 setup as a 11.1 system, I'll see if it reproduces there.
>>>
>>> And thank you for reporting this. Although Solaris 11.1 is not one of our critical systems, it's very important that this works.
>>>
>>> -kto
>>>
>>> On Nov 2, 2012, at 9:38 AM, Vincent Ryan wrote:
>>>
>>>>> From: Vincent Ryan <vincent.x.ryan at oracle.com>
>>>>> Subject: Re: New builds from the build-infra team
>>>>> Date: 2 November 2012 15:48:03 GMT
>>>>> To: build-infra-dev at openjdk.java.net
>>>>>
>>>>> I tried this out on the latest Solaris 11 Update 1 (sparc) but the build encountered problems locating libc when
>>>>> building jdk. (BTW the old build works correctly, just slower)
>>>>>
>>>>> :
>>>>> :
>>>>> strerror                            /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>> vfprintf                            /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_error.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>> fprintf                             /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_init.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>> gethrvtime                          /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>> ld: fatal: symbol referencing errors. No output written to /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so
>>>>> gmake[3]: *** [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so] Error 1
>>>>> gmake[3]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>>> gmake[2]: *** [libs-only] Error 2
>>>>> gmake[2]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>>> make[1]: *** [jdk-only] Error 2
>>>>> make[1]: Leaving directory `/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release'
>>>>> make: *** [all] Error 2
>>>>> t4%
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> FYI I've attached the config script that was generated by configure.sh.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 1 Nov 2012, at 18:38, Kelly O'Hair wrote:
>>>>>
>>>>>>
>>>>>> Pardon the wide email, but this impacts everyone building the OpenJDK jdk8/jdk8 derived forests.
>>>>>>
>>>>>> Please only reply to the build-infra-dev mailing list, or just me.
>>>>>>
>>>>>> With some recent integrations from the build-infra project into jdk8/jdk8 repositories, the build-infra team
>>>>>> would like to get more exposure of the new builds. These jdk8/jdk8 changes will start showing up in various
>>>>>> jdk8 and team forests over the next few weeks. The default is still the old builds, but both builds work in most
>>>>>> cases for OpenJDK as far as we know.
>>>>>>
>>>>>> At a very high level, the intent is that once you get a forest:
>>>>>> hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>>>>>> cd j8
>>>>>> sh ./get_source.sh
>>>>>>
>>>>>> You should be able to simply configure&&make (the ultimate goal is this simple anyway), e.g.
>>>>>> sh ./configure
>>>>>> make NEWBUILD=true     # The NEWBUILD=true will become the default when we formally switch.
>>>>>>
>>>>>> Where "make" is GNU make 3.81, and your system has all the requires packages and PATH contains the
>>>>>> needed tools. Note that on Windows, MKS unix utilities cannot be used with the new builds, just CYGWIN
>>>>>> is recommended at this time.
>>>>>>
>>>>>> Of course, we know, it's never as easy as a simple configure&&make, and often you will need to pass in
>>>>>> configure options.
>>>>>>
>>>>>> What we would like to know is where a simple configure&&make does not work, and anything people had
>>>>>> to do to make it work.
>>>>>>
>>>>>> I know many of you are quite used to the old builds, so I have a temporary  "bridgeBuild" target
>>>>>> people can try that will attempt to map the ALT_* environment variables to an appropriate configure command
>>>>>> and then run that configure command and do the build, e.g.
>>>>>>
>>>>>> make NEWBUILD=true bridgeBuild
>>>>>>
>>>>>> People willing to do comparisons between the old and new builds could:
>>>>>> rm -f -r build
>>>>>> time make NEWBUILD=true bridgeBuild
>>>>>> rm -f -r build
>>>>>> time make NO_DOCS=true     # Old builds do not generate javadocs by default
>>>>>>
>>>>>> Any observations about speed of the builds would be appreciated, as will any impressions on what you see.
>>>>>>
>>>>>> At this time, we think this is working pretty well with a few caveats:
>>>>>> * GNU make with the new builds is doing much more parallel processing and this can stress out a system
>>>>>> - Use "make JOBS=1" if you suspect a problem, then try adjusting it up slowly.
>>>>>> * Partial builds are limited, right now full builds of the entire OpenJDK is the target
>>>>>> - Hotspot can still be built on it's own, but everyone else needs to build hotspot at least once
>>>>>> * Paths with multiple names can cause problems, e.g. being on system svc6, and access an exported share
>>>>>> area as /net/svc6/export/foobar  instead of /export/foobar  will cause problems. Use local paths.
>>>>>>
>>>>>> We know there are still issues and we will be focusing heavily on the critical ones in the next few weeks, but
>>>>>> we do need the community to tell us what the critical issues really are.
>>>>>>
>>>>>> Our number one priority at this time is that everyone that was able to build the old way, should be able to build
>>>>>> with the new build-infra makefiles. Please help us verify that.
>>>>>>
>>>>>> -kto
>>>>>>
>>>>>
>>>>
>>>
>>
>



From kelly.ohair at oracle.com  Fri Nov  2 18:49:17 2012
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Sat, 03 Nov 2012 01:49:17 +0000
Subject: hg: build-infra/jdk8/jdk: Added -lc to libraryes that should have
	explicit dependencce on libc for solaris.
Message-ID: <20121103014958.BE4F547753@hg.openjdk.java.net>

Changeset: b7c0e7297480
Author:    ohair
Date:      2012-11-02 18:49 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/b7c0e7297480

Added -lc to libraryes that should have explicit dependencce on libc for solaris.

! makefiles/CompileNativeLibraries.gmk



From kelly.ohair at oracle.com  Sat Nov  3 16:36:46 2012
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Sat, 03 Nov 2012 23:36:46 +0000
Subject: hg: build-infra/jdk8: 3 new changesets
Message-ID: <20121103233648.EEE8147762@hg.openjdk.java.net>

Changeset: e20ffc02e437
Author:    erikj
Date:      2012-11-03 16:15 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/e20ffc02e437

8002183: Increased max number of paths to list in ListPathsSafely to 16000.
Reviewed-by: ohair

! common/makefiles/MakeBase.gmk

Changeset: ed9e5635fc80
Author:    erikj
Date:      2012-11-03 16:28 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/ed9e5635fc80

8002220: build-infra: update for mac, solaris 11 issues
8002184: Fixed exclude and includes for jarsigner in new build
Reviewed-by: ohair

! common/autoconf/basics.m4
! common/autoconf/basics_windows.m4
! common/autoconf/compare.sh.in
! common/autoconf/generated-configure.sh
! common/autoconf/libraries.m4
! common/bin/compare.sh
! common/bin/compare_exceptions.sh.incl
! common/makefiles/JavaCompilation.gmk

Changeset: 6fb87ba37842
Author:    ohair
Date:      2012-11-03 16:33 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/6fb87ba37842

Merge

! common/autoconf/basics.m4
! common/autoconf/basics_windows.m4
! common/autoconf/compare.sh.in
! common/autoconf/generated-configure.sh
! common/autoconf/libraries.m4
! common/bin/compare.sh
! common/bin/compare_exceptions.sh.incl
! common/makefiles/JavaCompilation.gmk
! common/makefiles/MakeBase.gmk



From kelly.ohair at oracle.com  Sat Nov  3 16:36:51 2012
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Sat, 03 Nov 2012 23:36:51 +0000
Subject: hg: build-infra/jdk8/jdk: 2 new changesets
Message-ID: <20121103233749.4238B47763@hg.openjdk.java.net>

Changeset: 63726e5b90da
Author:    erikj
Date:      2012-11-03 16:27 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/63726e5b90da

8002220: build-infra: update for mac, solaris 11 issues
8002184: Fixed exclude and includes for jarsigner in new build
Reviewed-by: ohair

! makefiles/CompileJavaClasses.gmk
! makefiles/CompileNativeLibraries.gmk
! makefiles/CreateJars.gmk
! makefiles/GensrcJObjC.gmk

Changeset: 95325502074e
Author:    ohair
Date:      2012-11-03 16:33 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/95325502074e

Merge

! makefiles/CompileJavaClasses.gmk
! makefiles/CompileNativeLibraries.gmk
! makefiles/CreateJars.gmk
! makefiles/GensrcJObjC.gmk



From kelly.ohair at oracle.com  Sat Nov  3 20:06:46 2012
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Sun, 04 Nov 2012 03:06:46 +0000
Subject: hg: build-infra/jdk8: Remove execute permission on m4 file.
Message-ID: <20121104030646.E199847769@hg.openjdk.java.net>

Changeset: 859c174a8dcb
Author:    ohair
Date:      2012-11-03 20:06 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/859c174a8dcb

Remove execute permission on m4 file.




From fredrik.ohrstrom at oracle.com  Mon Nov  5 01:50:12 2012
From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com)
Date: Mon, 05 Nov 2012 09:50:12 +0000
Subject: hg: build-infra/jdk8: Incremental build of changes in jaf/jaxws did
	not update the jar properly because
Message-ID: <20121105095013.04AFA47785@hg.openjdk.java.net>

Changeset: 48859f58e330
Author:    ohrstrom
Date:      2012-11-05 10:49 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/48859f58e330

Incremental build of changes in jaf/jaxws did not update the jar properly because
the contents file sometimes contains whitespace, even though there is nothing to do.
The test must clean out the whitespace.

! common/makefiles/JavaCompilation.gmk



From alan.bateman at oracle.com  Mon Nov  5 07:24:45 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Mon, 05 Nov 2012 15:24:45 +0000
Subject: hg: jdk8/profiles/jdk: Add test to check that java -version includes
	the profile name
Message-ID: <20121105152533.448CC4778A@hg.openjdk.java.net>

Changeset: c3268b2766c8
Author:    alanb
Date:      2012-11-05 15:22 +0000
URL:       http://hg.openjdk.java.net/jdk8/profiles/jdk/rev/c3268b2766c8

Add test to check that java -version includes the profile name

+ test/tools/launcher/profiles/VersionCheck.java



From fredrik.ohrstrom at oracle.com  Mon Nov  5 08:38:28 2012
From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com)
Date: Mon, 05 Nov 2012 16:38:28 +0000
Subject: hg: build-infra/jdk8/langtools: Drive letters, they go up,
	and they go down.....
Message-ID: <20121105163832.F3D584778F@hg.openjdk.java.net>

Changeset: 2827d946ba3b
Author:    ohrstrom
Date:      2012-11-05 17:37 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/langtools/rev/2827d946ba3b

Drive letters, they go up, and they go down.....

! src/share/classes/com/sun/tools/sjavac/JavacState.java
! src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java
! src/share/classes/com/sun/tools/sjavac/server/JavacServer.java
! src/share/classes/com/sun/tools/sjavac/server/PortFile.java



From fredrik.ohrstrom at oracle.com  Mon Nov  5 09:40:21 2012
From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com)
Date: Mon, 05 Nov 2012 17:40:21 +0000
Subject: hg: build-infra/jdk8/langtools: Remember to delete the port file when
	the stop file has been found.
Message-ID: <20121105174025.DB98D47794@hg.openjdk.java.net>

Changeset: 98d98608afd5
Author:    ohrstrom
Date:      2012-11-05 18:40 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/langtools/rev/98d98608afd5

Remember to delete the port file when the stop file has been found.

! src/share/classes/com/sun/tools/sjavac/server/JavacServer.java



From fredrik.ohrstrom at oracle.com  Mon Nov  5 09:41:27 2012
From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com)
Date: Mon, 05 Nov 2012 17:41:27 +0000
Subject: hg: build-infra/jdk8: Stop the sjavac server using a stop file
	instead of deleting its port file.
Message-ID: <20121105174127.42BAD47795@hg.openjdk.java.net>

Changeset: 845f6e515bf5
Author:    ohrstrom
Date:      2012-11-05 18:41 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/845f6e515bf5

Stop the sjavac server using a stop file instead of deleting its port file.

! common/makefiles/MakeHelpers.gmk



From fredrik.ohrstrom at oracle.com  Mon Nov  5 10:11:13 2012
From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com)
Date: Mon, 05 Nov 2012 18:11:13 +0000
Subject: hg: build-infra/jdk8: Remove the stop file and the port file,
	before the build begins.
Message-ID: <20121105181113.9A49747796@hg.openjdk.java.net>

Changeset: 469160838ab7
Author:    ohrstrom
Date:      2012-11-05 19:10 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/469160838ab7

Remove the stop file and the port file, before the build begins.

! common/makefiles/MakeHelpers.gmk



From fredrik.ohrstrom at oracle.com  Mon Nov  5 12:49:23 2012
From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com)
Date: Mon, 05 Nov 2012 20:49:23 +0000
Subject: hg: build-infra/jdk8/langtools: Log options to sjavac compilers.
Message-ID: <20121105204928.B4BA64779C@hg.openjdk.java.net>

Changeset: ab90a3c1d509
Author:    ohrstrom
Date:      2012-11-05 21:48 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/langtools/rev/ab90a3c1d509

Log options to sjavac compilers.

! src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java



From fredrik.ohrstrom at oracle.com  Mon Nov  5 12:50:58 2012
From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com)
Date: Mon, 05 Nov 2012 20:50:58 +0000
Subject: hg: build-infra/jdk8: Stop the sjavac server properly.
Message-ID: <20121105205059.14E144779D@hg.openjdk.java.net>

Changeset: fede39a91268
Author:    ohrstrom
Date:      2012-11-05 21:50 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/fede39a91268

Stop the sjavac server properly.

! common/autoconf/spec.gmk.in
! common/makefiles/MakeHelpers.gmk



From erik.joelsson at oracle.com  Tue Nov  6 02:20:09 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 06 Nov 2012 10:20:09 +0000
Subject: hg: build-infra/jdk8/langtools: Added a drive letter case normalizer
	method to Util and use it to make
Message-ID: <20121106102017.701D1477AF@hg.openjdk.java.net>

Changeset: c03675025d00
Author:    erikj
Date:      2012-11-06 11:19 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/langtools/rev/c03675025d00

Added a drive letter case normalizer method to Util and use it to make
comparisons with exclude/include patterns work on windows.

! src/share/classes/com/sun/tools/sjavac/Main.java
! src/share/classes/com/sun/tools/sjavac/Source.java
! src/share/classes/com/sun/tools/sjavac/Util.java



From fredrik.ohrstrom at oracle.com  Tue Nov  6 03:48:31 2012
From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com)
Date: Tue, 06 Nov 2012 11:48:31 +0000
Subject: hg: build-infra/jdk8/langtools: Debug pubapi changes.
Message-ID: <20121106114838.0A8A1477B2@hg.openjdk.java.net>

Changeset: 2022cc2c7c16
Author:    ohrstrom
Date:      2012-11-06 12:47 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/langtools/rev/2022cc2c7c16

Debug pubapi changes.

! src/share/classes/com/sun/tools/sjavac/Package.java



From erik.joelsson at oracle.com  Tue Nov  6 08:14:47 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 06 Nov 2012 16:14:47 +0000
Subject: hg: build-infra/jdk8/langtools: Fix for broken pubapis in javac_state
	file.
Message-ID: <20121106161452.06C10477B8@hg.openjdk.java.net>

Changeset: c8651adb8b77
Author:    erikj
Date:      2012-11-06 17:14 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/langtools/rev/c8651adb8b77

Fix for broken pubapis in javac_state file.

! src/share/classes/com/sun/tools/sjavac/server/JavacServer.java



From kelly.ohair at oracle.com  Tue Nov  6 08:33:23 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 6 Nov 2012 08:33:23 -0800
Subject: New builds from the build-infra team
In-Reply-To: <50942824.1000102@oracle.com>
References: <70C78781-9057-4B6C-9F80-E39F637A9AD5@oracle.com>
	<4E118E25-D6AB-4C7E-9CF9-56495CBB5B92@oracle.com>
	<DBF14695-B54B-4092-A420-1B12D11D19A6@oracle.com>
	<A7D41D1F-A00C-4041-9609-AB987F0CEDB0@oracle.com>
	<28B38282-EFD5-46EF-B5BE-57A6110DFC51@oracle.com>
	<50942824.1000102@oracle.com>
Message-ID: <7BDA9278-91CA-449D-98AD-D1520941A5E5@oracle.com>

If you get a chance, could you try this experiment again with the latest in jdk8/build forest?
I fixed a few more libraries that I think had a missing -lc.

I don't have access to a Solaris SPARC 11.1 system, and so far the issues you have run into seem to
be unique to SPARCV9 builds on 11.1, the Solaris X64 11.1 systems I have access to don't seem to reproduce this issue.
I can only assume that the compiler or the system behaves differently between SPARCV9 and X64 on 11.1. :^(

-kto

On Nov 2, 2012, at 1:08 PM, Vincent Ryan wrote:

> Thanks Kelly.
> 
> I re-ran the build with your patch and got better results but there
> seems to be another linker problem later in the jdk build.
> 
> Here's the tail of the build output:
> 
> :
> :
> Undefined                       first referenced
> symbol                             in file
> free /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
> __iob /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
> abort /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
> snprintf /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
> calloc /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
> malloc /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
> memcpy /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
> memset /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
> strcmp /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
> strlen /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
> realloc /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
> strncmp /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
> fprintf /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
> ld: fatal: symbol referencing errors. No output written to /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libjava_crw_demo.so
> gmake[3]: *** [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libjava_crw_demo.so] Error 1
> gmake[3]: *** Waiting for unfinished jobs....
> Undefined                       first referenced
> symbol                             in file
> exit /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
> free /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
> __iob /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
> abort /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
> iconv /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
> __ctype /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
> iconv_open /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
> calloc /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
> memcpy /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
> strcmp /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
> strdup /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
> strlen /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
> nl_langinfo /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
> sprintf /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
> setlocale /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
> iconv_close /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
> fprintf /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
> ld: fatal: symbol referencing errors. No output written to /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libnpt.so
> gmake[3]: *** [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libnpt.so] Error 1
> gmake[3]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
> gmake[2]: *** [libs-only] Error 2
> gmake[2]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
> make[1]: *** [jdk-only] Error 2
> make[1]: Leaving directory `/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release'
> make: *** [all] Error 2
> t4%
> 
> 
> 
> 
> 
> On 02/11/2012 18:38, Kelly O'Hair wrote:
>> 
>> On Nov 2, 2012, at 11:17 AM, Vincent Ryan wrote:
>> 
>>> That attachment got dropped when I re-sent my message (previously I wasn't a member of the build-infra-dev email alias). I've attached it again in case it proves useful.
>>> 
>>> <config.status>
>>> 
>>> 
>>> I realize Solaris 11 is not an official build platform for JDK8 but I thought I'd give it a spin on a reasonably
>>> beefy server.
>> 
>> It's great that you tried this, thanks.
>> 
>> As far as I can tell, this seems to be a sparcv9 Solaris 11.1 issue, because I tried Solaris 11.1 X64 and it worked fine.
>> However, the link of libhprof.so IS missing the -lc option.
>> So why sparcv9 would complain and amd64 would not is a bit puzzling.
>> 
>> The change I think needs to be made is:
>> 
>> diff --git a/makefiles/CompileNativeLibraries.gmk b/makefiles/CompileNativeLibraries.gmk
>> --- a/makefiles/CompileNativeLibraries.gmk
>> +++ b/makefiles/CompileNativeLibraries.gmk
>> @@ -1807,7 +1807,7 @@
>>  BUILD_LIBHPROF_LDFLAGS:=
>> 
>>  ifeq ($(OPENJDK_TARGET_OS),solaris)
>> -     BUILD_LIBHPROF_LDFLAGS += -lsocket -lnsl
>> +     BUILD_LIBHPROF_LDFLAGS += -lsocket -lnsl -lc
>>  endif
>> 
>>  LIBHPROF_OPTIMIZATION:=HIGHEST
>> 
>> 
>> 
>> But I have not tested it yet.
>> Did you want to give this patch a spin?
>> 
>> -kto
>> 
>>> Thanks.
>>> 
>>> 
>>> On 2 Nov 2012, at 17:45, Kelly O'Hair wrote:
>>> 
>>>> The attachment is missing.
>>>> 
>>>> This looks like the  -lc   is missing from the creation of hprof, we should never let libc be an implicit dependency.
>>>> 
>>>> I wonder if Solaris 11.1 has tightened up the rules on implicit dependencies. We have not seen this on Solaris 10.
>>>> We just got svc6 setup as a 11.1 system, I'll see if it reproduces there.
>>>> 
>>>> And thank you for reporting this. Although Solaris 11.1 is not one of our critical systems, it's very important that this works.
>>>> 
>>>> -kto
>>>> 
>>>> On Nov 2, 2012, at 9:38 AM, Vincent Ryan wrote:
>>>> 
>>>>>> From: Vincent Ryan <vincent.x.ryan at oracle.com>
>>>>>> Subject: Re: New builds from the build-infra team
>>>>>> Date: 2 November 2012 15:48:03 GMT
>>>>>> To: build-infra-dev at openjdk.java.net
>>>>>> 
>>>>>> I tried this out on the latest Solaris 11 Update 1 (sparc) but the build encountered problems locating libc when
>>>>>> building jdk. (BTW the old build works correctly, just slower)
>>>>>> 
>>>>>> :
>>>>>> :
>>>>>> strerror                            /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>> vfprintf                            /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_error.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>> fprintf                             /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_init.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>> gethrvtime                          /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>> ld: fatal: symbol referencing errors. No output written to /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so
>>>>>> gmake[3]: *** [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so] Error 1
>>>>>> gmake[3]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>>>> gmake[2]: *** [libs-only] Error 2
>>>>>> gmake[2]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>>>> make[1]: *** [jdk-only] Error 2
>>>>>> make[1]: Leaving directory `/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release'
>>>>>> make: *** [all] Error 2
>>>>>> t4%
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> FYI I've attached the config script that was generated by configure.sh.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 1 Nov 2012, at 18:38, Kelly O'Hair wrote:
>>>>>> 
>>>>>>> 
>>>>>>> Pardon the wide email, but this impacts everyone building the OpenJDK jdk8/jdk8 derived forests.
>>>>>>> 
>>>>>>> Please only reply to the build-infra-dev mailing list, or just me.
>>>>>>> 
>>>>>>> With some recent integrations from the build-infra project into jdk8/jdk8 repositories, the build-infra team
>>>>>>> would like to get more exposure of the new builds. These jdk8/jdk8 changes will start showing up in various
>>>>>>> jdk8 and team forests over the next few weeks. The default is still the old builds, but both builds work in most
>>>>>>> cases for OpenJDK as far as we know.
>>>>>>> 
>>>>>>> At a very high level, the intent is that once you get a forest:
>>>>>>> hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>>>>>>> cd j8
>>>>>>> sh ./get_source.sh
>>>>>>> 
>>>>>>> You should be able to simply configure&&make (the ultimate goal is this simple anyway), e.g.
>>>>>>> sh ./configure
>>>>>>> make NEWBUILD=true     # The NEWBUILD=true will become the default when we formally switch.
>>>>>>> 
>>>>>>> Where "make" is GNU make 3.81, and your system has all the requires packages and PATH contains the
>>>>>>> needed tools. Note that on Windows, MKS unix utilities cannot be used with the new builds, just CYGWIN
>>>>>>> is recommended at this time.
>>>>>>> 
>>>>>>> Of course, we know, it's never as easy as a simple configure&&make, and often you will need to pass in
>>>>>>> configure options.
>>>>>>> 
>>>>>>> What we would like to know is where a simple configure&&make does not work, and anything people had
>>>>>>> to do to make it work.
>>>>>>> 
>>>>>>> I know many of you are quite used to the old builds, so I have a temporary  "bridgeBuild" target
>>>>>>> people can try that will attempt to map the ALT_* environment variables to an appropriate configure command
>>>>>>> and then run that configure command and do the build, e.g.
>>>>>>> 
>>>>>>> make NEWBUILD=true bridgeBuild
>>>>>>> 
>>>>>>> People willing to do comparisons between the old and new builds could:
>>>>>>> rm -f -r build
>>>>>>> time make NEWBUILD=true bridgeBuild
>>>>>>> rm -f -r build
>>>>>>> time make NO_DOCS=true     # Old builds do not generate javadocs by default
>>>>>>> 
>>>>>>> Any observations about speed of the builds would be appreciated, as will any impressions on what you see.
>>>>>>> 
>>>>>>> At this time, we think this is working pretty well with a few caveats:
>>>>>>> * GNU make with the new builds is doing much more parallel processing and this can stress out a system
>>>>>>> - Use "make JOBS=1" if you suspect a problem, then try adjusting it up slowly.
>>>>>>> * Partial builds are limited, right now full builds of the entire OpenJDK is the target
>>>>>>> - Hotspot can still be built on it's own, but everyone else needs to build hotspot at least once
>>>>>>> * Paths with multiple names can cause problems, e.g. being on system svc6, and access an exported share
>>>>>>> area as /net/svc6/export/foobar  instead of /export/foobar  will cause problems. Use local paths.
>>>>>>> 
>>>>>>> We know there are still issues and we will be focusing heavily on the critical ones in the next few weeks, but
>>>>>>> we do need the community to tell us what the critical issues really are.
>>>>>>> 
>>>>>>> Our number one priority at this time is that everyone that was able to build the old way, should be able to build
>>>>>>> with the new build-infra makefiles. Please help us verify that.
>>>>>>> 
>>>>>>> -kto
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 



From vincent.x.ryan at oracle.com  Tue Nov  6 09:34:19 2012
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Tue, 6 Nov 2012 17:34:19 +0000
Subject: New builds from the build-infra team
In-Reply-To: <7BDA9278-91CA-449D-98AD-D1520941A5E5@oracle.com>
References: <70C78781-9057-4B6C-9F80-E39F637A9AD5@oracle.com>
	<4E118E25-D6AB-4C7E-9CF9-56495CBB5B92@oracle.com>
	<DBF14695-B54B-4092-A420-1B12D11D19A6@oracle.com>
	<A7D41D1F-A00C-4041-9609-AB987F0CEDB0@oracle.com>
	<28B38282-EFD5-46EF-B5BE-57A6110DFC51@oracle.com>
	<50942824.1000102@oracle.com>
	<7BDA9278-91CA-449D-98AD-D1520941A5E5@oracle.com>
Message-ID: <7145E484-6D99-4D34-B47C-A09A9F2A5714@oracle.com>

I picked up the 2 changesets that were pushed over the weekend. The build makes more
progress but it still fails due to missing C lib. I guess there are a few more corner cases.

Is there a way to activate more debugging during the build? I'd like to examine the exact
compiler flags that are in use when the failure occurs.



On 6 Nov 2012, at 16:33, Kelly O'Hair wrote:

> If you get a chance, could you try this experiment again with the latest in jdk8/build forest?
> I fixed a few more libraries that I think had a missing -lc.
> 
> I don't have access to a Solaris SPARC 11.1 system, and so far the issues you have run into seem to
> be unique to SPARCV9 builds on 11.1, the Solaris X64 11.1 systems I have access to don't seem to reproduce this issue.
> I can only assume that the compiler or the system behaves differently between SPARCV9 and X64 on 11.1. :^(
> 
> -kto
> 
> On Nov 2, 2012, at 1:08 PM, Vincent Ryan wrote:
> 
>> Thanks Kelly.
>> 
>> I re-ran the build with your patch and got better results but there
>> seems to be another linker problem later in the jdk build.
>> 
>> Here's the tail of the build output:
>> 
>> :
>> :
>> Undefined                       first referenced
>> symbol                             in file
>> free /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>> __iob /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>> abort /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>> snprintf /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>> calloc /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>> malloc /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>> memcpy /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>> memset /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>> strcmp /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>> strlen /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>> realloc /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>> strncmp /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>> fprintf /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>> ld: fatal: symbol referencing errors. No output written to /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libjava_crw_demo.so
>> gmake[3]: *** [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libjava_crw_demo.so] Error 1
>> gmake[3]: *** Waiting for unfinished jobs....
>> Undefined                       first referenced
>> symbol                             in file
>> exit /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>> free /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>> __iob /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>> abort /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
>> iconv /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>> __ctype /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
>> iconv_open /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>> calloc /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>> memcpy /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>> strcmp /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>> strdup /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>> strlen /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
>> nl_langinfo /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>> sprintf /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
>> setlocale /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>> iconv_close /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>> fprintf /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>> ld: fatal: symbol referencing errors. No output written to /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libnpt.so
>> gmake[3]: *** [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libnpt.so] Error 1
>> gmake[3]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>> gmake[2]: *** [libs-only] Error 2
>> gmake[2]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>> make[1]: *** [jdk-only] Error 2
>> make[1]: Leaving directory `/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release'
>> make: *** [all] Error 2
>> t4%
>> 
>> 
>> 
>> 
>> 
>> On 02/11/2012 18:38, Kelly O'Hair wrote:
>>> 
>>> On Nov 2, 2012, at 11:17 AM, Vincent Ryan wrote:
>>> 
>>>> That attachment got dropped when I re-sent my message (previously I wasn't a member of the build-infra-dev email alias). I've attached it again in case it proves useful.
>>>> 
>>>> <config.status>
>>>> 
>>>> 
>>>> I realize Solaris 11 is not an official build platform for JDK8 but I thought I'd give it a spin on a reasonably
>>>> beefy server.
>>> 
>>> It's great that you tried this, thanks.
>>> 
>>> As far as I can tell, this seems to be a sparcv9 Solaris 11.1 issue, because I tried Solaris 11.1 X64 and it worked fine.
>>> However, the link of libhprof.so IS missing the -lc option.
>>> So why sparcv9 would complain and amd64 would not is a bit puzzling.
>>> 
>>> The change I think needs to be made is:
>>> 
>>> diff --git a/makefiles/CompileNativeLibraries.gmk b/makefiles/CompileNativeLibraries.gmk
>>> --- a/makefiles/CompileNativeLibraries.gmk
>>> +++ b/makefiles/CompileNativeLibraries.gmk
>>> @@ -1807,7 +1807,7 @@
>>> BUILD_LIBHPROF_LDFLAGS:=
>>> 
>>> ifeq ($(OPENJDK_TARGET_OS),solaris)
>>> -     BUILD_LIBHPROF_LDFLAGS += -lsocket -lnsl
>>> +     BUILD_LIBHPROF_LDFLAGS += -lsocket -lnsl -lc
>>> endif
>>> 
>>> LIBHPROF_OPTIMIZATION:=HIGHEST
>>> 
>>> 
>>> 
>>> But I have not tested it yet.
>>> Did you want to give this patch a spin?
>>> 
>>> -kto
>>> 
>>>> Thanks.
>>>> 
>>>> 
>>>> On 2 Nov 2012, at 17:45, Kelly O'Hair wrote:
>>>> 
>>>>> The attachment is missing.
>>>>> 
>>>>> This looks like the  -lc   is missing from the creation of hprof, we should never let libc be an implicit dependency.
>>>>> 
>>>>> I wonder if Solaris 11.1 has tightened up the rules on implicit dependencies. We have not seen this on Solaris 10.
>>>>> We just got svc6 setup as a 11.1 system, I'll see if it reproduces there.
>>>>> 
>>>>> And thank you for reporting this. Although Solaris 11.1 is not one of our critical systems, it's very important that this works.
>>>>> 
>>>>> -kto
>>>>> 
>>>>> On Nov 2, 2012, at 9:38 AM, Vincent Ryan wrote:
>>>>> 
>>>>>>> From: Vincent Ryan <vincent.x.ryan at oracle.com>
>>>>>>> Subject: Re: New builds from the build-infra team
>>>>>>> Date: 2 November 2012 15:48:03 GMT
>>>>>>> To: build-infra-dev at openjdk.java.net
>>>>>>> 
>>>>>>> I tried this out on the latest Solaris 11 Update 1 (sparc) but the build encountered problems locating libc when
>>>>>>> building jdk. (BTW the old build works correctly, just slower)
>>>>>>> 
>>>>>>> :
>>>>>>> :
>>>>>>> strerror                            /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>>> vfprintf                            /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_error.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>>> fprintf                             /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_init.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>>> gethrvtime                          /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>>> ld: fatal: symbol referencing errors. No output written to /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so
>>>>>>> gmake[3]: *** [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so] Error 1
>>>>>>> gmake[3]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>>>>> gmake[2]: *** [libs-only] Error 2
>>>>>>> gmake[2]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>>>>> make[1]: *** [jdk-only] Error 2
>>>>>>> make[1]: Leaving directory `/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release'
>>>>>>> make: *** [all] Error 2
>>>>>>> t4%
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> FYI I've attached the config script that was generated by configure.sh.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 1 Nov 2012, at 18:38, Kelly O'Hair wrote:
>>>>>>> 
>>>>>>>> 
>>>>>>>> Pardon the wide email, but this impacts everyone building the OpenJDK jdk8/jdk8 derived forests.
>>>>>>>> 
>>>>>>>> Please only reply to the build-infra-dev mailing list, or just me.
>>>>>>>> 
>>>>>>>> With some recent integrations from the build-infra project into jdk8/jdk8 repositories, the build-infra team
>>>>>>>> would like to get more exposure of the new builds. These jdk8/jdk8 changes will start showing up in various
>>>>>>>> jdk8 and team forests over the next few weeks. The default is still the old builds, but both builds work in most
>>>>>>>> cases for OpenJDK as far as we know.
>>>>>>>> 
>>>>>>>> At a very high level, the intent is that once you get a forest:
>>>>>>>> hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>>>>>>>> cd j8
>>>>>>>> sh ./get_source.sh
>>>>>>>> 
>>>>>>>> You should be able to simply configure&&make (the ultimate goal is this simple anyway), e.g.
>>>>>>>> sh ./configure
>>>>>>>> make NEWBUILD=true     # The NEWBUILD=true will become the default when we formally switch.
>>>>>>>> 
>>>>>>>> Where "make" is GNU make 3.81, and your system has all the requires packages and PATH contains the
>>>>>>>> needed tools. Note that on Windows, MKS unix utilities cannot be used with the new builds, just CYGWIN
>>>>>>>> is recommended at this time.
>>>>>>>> 
>>>>>>>> Of course, we know, it's never as easy as a simple configure&&make, and often you will need to pass in
>>>>>>>> configure options.
>>>>>>>> 
>>>>>>>> What we would like to know is where a simple configure&&make does not work, and anything people had
>>>>>>>> to do to make it work.
>>>>>>>> 
>>>>>>>> I know many of you are quite used to the old builds, so I have a temporary  "bridgeBuild" target
>>>>>>>> people can try that will attempt to map the ALT_* environment variables to an appropriate configure command
>>>>>>>> and then run that configure command and do the build, e.g.
>>>>>>>> 
>>>>>>>> make NEWBUILD=true bridgeBuild
>>>>>>>> 
>>>>>>>> People willing to do comparisons between the old and new builds could:
>>>>>>>> rm -f -r build
>>>>>>>> time make NEWBUILD=true bridgeBuild
>>>>>>>> rm -f -r build
>>>>>>>> time make NO_DOCS=true     # Old builds do not generate javadocs by default
>>>>>>>> 
>>>>>>>> Any observations about speed of the builds would be appreciated, as will any impressions on what you see.
>>>>>>>> 
>>>>>>>> At this time, we think this is working pretty well with a few caveats:
>>>>>>>> * GNU make with the new builds is doing much more parallel processing and this can stress out a system
>>>>>>>> - Use "make JOBS=1" if you suspect a problem, then try adjusting it up slowly.
>>>>>>>> * Partial builds are limited, right now full builds of the entire OpenJDK is the target
>>>>>>>> - Hotspot can still be built on it's own, but everyone else needs to build hotspot at least once
>>>>>>>> * Paths with multiple names can cause problems, e.g. being on system svc6, and access an exported share
>>>>>>>> area as /net/svc6/export/foobar  instead of /export/foobar  will cause problems. Use local paths.
>>>>>>>> 
>>>>>>>> We know there are still issues and we will be focusing heavily on the critical ones in the next few weeks, but
>>>>>>>> we do need the community to tell us what the critical issues really are.
>>>>>>>> 
>>>>>>>> Our number one priority at this time is that everyone that was able to build the old way, should be able to build
>>>>>>>> with the new build-infra makefiles. Please help us verify that.
>>>>>>>> 
>>>>>>>> -kto
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 



From kelly.ohair at oracle.com  Tue Nov  6 10:10:40 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 6 Nov 2012 10:10:40 -0800
Subject: New builds from the build-infra team
In-Reply-To: <7145E484-6D99-4D34-B47C-A09A9F2A5714@oracle.com>
References: <70C78781-9057-4B6C-9F80-E39F637A9AD5@oracle.com>
	<4E118E25-D6AB-4C7E-9CF9-56495CBB5B92@oracle.com>
	<DBF14695-B54B-4092-A420-1B12D11D19A6@oracle.com>
	<A7D41D1F-A00C-4041-9609-AB987F0CEDB0@oracle.com>
	<28B38282-EFD5-46EF-B5BE-57A6110DFC51@oracle.com>
	<50942824.1000102@oracle.com>
	<7BDA9278-91CA-449D-98AD-D1520941A5E5@oracle.com>
	<7145E484-6D99-4D34-B47C-A09A9F2A5714@oracle.com>
Message-ID: <FCA6CF40-49C2-4359-9ED8-E165AF47E887@oracle.com>


On Nov 6, 2012, at 9:34 AM, Vincent Ryan wrote:

> I picked up the 2 changesets that were pushed over the weekend. The build makes more
> progress but it still fails due to missing C lib. I guess there are a few more corner cases.
> 
> Is there a way to activate more debugging during the build? I'd like to examine the exact
> compiler flags that are in use when the failure occurs.

Use 

   gmake LOG=debug  

-kto

> 
> 
> 
> On 6 Nov 2012, at 16:33, Kelly O'Hair wrote:
> 
>> If you get a chance, could you try this experiment again with the latest in jdk8/build forest?
>> I fixed a few more libraries that I think had a missing -lc.
>> 
>> I don't have access to a Solaris SPARC 11.1 system, and so far the issues you have run into seem to
>> be unique to SPARCV9 builds on 11.1, the Solaris X64 11.1 systems I have access to don't seem to reproduce this issue.
>> I can only assume that the compiler or the system behaves differently between SPARCV9 and X64 on 11.1. :^(
>> 
>> -kto
>> 
>> On Nov 2, 2012, at 1:08 PM, Vincent Ryan wrote:
>> 
>>> Thanks Kelly.
>>> 
>>> I re-ran the build with your patch and got better results but there
>>> seems to be another linker problem later in the jdk build.
>>> 
>>> Here's the tail of the build output:
>>> 
>>> :
>>> :
>>> Undefined                       first referenced
>>> symbol                             in file
>>> free /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>> __iob /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>> abort /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>> snprintf /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>> calloc /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>> malloc /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>> memcpy /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>> memset /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>> strcmp /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>> strlen /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>> realloc /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>> strncmp /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>> fprintf /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>> ld: fatal: symbol referencing errors. No output written to /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libjava_crw_demo.so
>>> gmake[3]: *** [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libjava_crw_demo.so] Error 1
>>> gmake[3]: *** Waiting for unfinished jobs....
>>> Undefined                       first referenced
>>> symbol                             in file
>>> exit /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>> free /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>> __iob /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>> abort /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
>>> iconv /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>> __ctype /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
>>> iconv_open /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>> calloc /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>> memcpy /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>> strcmp /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>> strdup /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>> strlen /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
>>> nl_langinfo /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>> sprintf /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
>>> setlocale /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>> iconv_close /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>> fprintf /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>> ld: fatal: symbol referencing errors. No output written to /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libnpt.so
>>> gmake[3]: *** [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libnpt.so] Error 1
>>> gmake[3]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>> gmake[2]: *** [libs-only] Error 2
>>> gmake[2]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>> make[1]: *** [jdk-only] Error 2
>>> make[1]: Leaving directory `/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release'
>>> make: *** [all] Error 2
>>> t4%
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 02/11/2012 18:38, Kelly O'Hair wrote:
>>>> 
>>>> On Nov 2, 2012, at 11:17 AM, Vincent Ryan wrote:
>>>> 
>>>>> That attachment got dropped when I re-sent my message (previously I wasn't a member of the build-infra-dev email alias). I've attached it again in case it proves useful.
>>>>> 
>>>>> <config.status>
>>>>> 
>>>>> 
>>>>> I realize Solaris 11 is not an official build platform for JDK8 but I thought I'd give it a spin on a reasonably
>>>>> beefy server.
>>>> 
>>>> It's great that you tried this, thanks.
>>>> 
>>>> As far as I can tell, this seems to be a sparcv9 Solaris 11.1 issue, because I tried Solaris 11.1 X64 and it worked fine.
>>>> However, the link of libhprof.so IS missing the -lc option.
>>>> So why sparcv9 would complain and amd64 would not is a bit puzzling.
>>>> 
>>>> The change I think needs to be made is:
>>>> 
>>>> diff --git a/makefiles/CompileNativeLibraries.gmk b/makefiles/CompileNativeLibraries.gmk
>>>> --- a/makefiles/CompileNativeLibraries.gmk
>>>> +++ b/makefiles/CompileNativeLibraries.gmk
>>>> @@ -1807,7 +1807,7 @@
>>>> BUILD_LIBHPROF_LDFLAGS:=
>>>> 
>>>> ifeq ($(OPENJDK_TARGET_OS),solaris)
>>>> -     BUILD_LIBHPROF_LDFLAGS += -lsocket -lnsl
>>>> +     BUILD_LIBHPROF_LDFLAGS += -lsocket -lnsl -lc
>>>> endif
>>>> 
>>>> LIBHPROF_OPTIMIZATION:=HIGHEST
>>>> 
>>>> 
>>>> 
>>>> But I have not tested it yet.
>>>> Did you want to give this patch a spin?
>>>> 
>>>> -kto
>>>> 
>>>>> Thanks.
>>>>> 
>>>>> 
>>>>> On 2 Nov 2012, at 17:45, Kelly O'Hair wrote:
>>>>> 
>>>>>> The attachment is missing.
>>>>>> 
>>>>>> This looks like the  -lc   is missing from the creation of hprof, we should never let libc be an implicit dependency.
>>>>>> 
>>>>>> I wonder if Solaris 11.1 has tightened up the rules on implicit dependencies. We have not seen this on Solaris 10.
>>>>>> We just got svc6 setup as a 11.1 system, I'll see if it reproduces there.
>>>>>> 
>>>>>> And thank you for reporting this. Although Solaris 11.1 is not one of our critical systems, it's very important that this works.
>>>>>> 
>>>>>> -kto
>>>>>> 
>>>>>> On Nov 2, 2012, at 9:38 AM, Vincent Ryan wrote:
>>>>>> 
>>>>>>>> From: Vincent Ryan <vincent.x.ryan at oracle.com>
>>>>>>>> Subject: Re: New builds from the build-infra team
>>>>>>>> Date: 2 November 2012 15:48:03 GMT
>>>>>>>> To: build-infra-dev at openjdk.java.net
>>>>>>>> 
>>>>>>>> I tried this out on the latest Solaris 11 Update 1 (sparc) but the build encountered problems locating libc when
>>>>>>>> building jdk. (BTW the old build works correctly, just slower)
>>>>>>>> 
>>>>>>>> :
>>>>>>>> :
>>>>>>>> strerror                            /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>>>> vfprintf                            /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_error.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>>>> fprintf                             /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_init.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>>>> gethrvtime                          /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>>>> ld: fatal: symbol referencing errors. No output written to /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so
>>>>>>>> gmake[3]: *** [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so] Error 1
>>>>>>>> gmake[3]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>>>>>> gmake[2]: *** [libs-only] Error 2
>>>>>>>> gmake[2]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>>>>>> make[1]: *** [jdk-only] Error 2
>>>>>>>> make[1]: Leaving directory `/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release'
>>>>>>>> make: *** [all] Error 2
>>>>>>>> t4%
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> FYI I've attached the config script that was generated by configure.sh.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 1 Nov 2012, at 18:38, Kelly O'Hair wrote:
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Pardon the wide email, but this impacts everyone building the OpenJDK jdk8/jdk8 derived forests.
>>>>>>>>> 
>>>>>>>>> Please only reply to the build-infra-dev mailing list, or just me.
>>>>>>>>> 
>>>>>>>>> With some recent integrations from the build-infra project into jdk8/jdk8 repositories, the build-infra team
>>>>>>>>> would like to get more exposure of the new builds. These jdk8/jdk8 changes will start showing up in various
>>>>>>>>> jdk8 and team forests over the next few weeks. The default is still the old builds, but both builds work in most
>>>>>>>>> cases for OpenJDK as far as we know.
>>>>>>>>> 
>>>>>>>>> At a very high level, the intent is that once you get a forest:
>>>>>>>>> hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>>>>>>>>> cd j8
>>>>>>>>> sh ./get_source.sh
>>>>>>>>> 
>>>>>>>>> You should be able to simply configure&&make (the ultimate goal is this simple anyway), e.g.
>>>>>>>>> sh ./configure
>>>>>>>>> make NEWBUILD=true     # The NEWBUILD=true will become the default when we formally switch.
>>>>>>>>> 
>>>>>>>>> Where "make" is GNU make 3.81, and your system has all the requires packages and PATH contains the
>>>>>>>>> needed tools. Note that on Windows, MKS unix utilities cannot be used with the new builds, just CYGWIN
>>>>>>>>> is recommended at this time.
>>>>>>>>> 
>>>>>>>>> Of course, we know, it's never as easy as a simple configure&&make, and often you will need to pass in
>>>>>>>>> configure options.
>>>>>>>>> 
>>>>>>>>> What we would like to know is where a simple configure&&make does not work, and anything people had
>>>>>>>>> to do to make it work.
>>>>>>>>> 
>>>>>>>>> I know many of you are quite used to the old builds, so I have a temporary  "bridgeBuild" target
>>>>>>>>> people can try that will attempt to map the ALT_* environment variables to an appropriate configure command
>>>>>>>>> and then run that configure command and do the build, e.g.
>>>>>>>>> 
>>>>>>>>> make NEWBUILD=true bridgeBuild
>>>>>>>>> 
>>>>>>>>> People willing to do comparisons between the old and new builds could:
>>>>>>>>> rm -f -r build
>>>>>>>>> time make NEWBUILD=true bridgeBuild
>>>>>>>>> rm -f -r build
>>>>>>>>> time make NO_DOCS=true     # Old builds do not generate javadocs by default
>>>>>>>>> 
>>>>>>>>> Any observations about speed of the builds would be appreciated, as will any impressions on what you see.
>>>>>>>>> 
>>>>>>>>> At this time, we think this is working pretty well with a few caveats:
>>>>>>>>> * GNU make with the new builds is doing much more parallel processing and this can stress out a system
>>>>>>>>> - Use "make JOBS=1" if you suspect a problem, then try adjusting it up slowly.
>>>>>>>>> * Partial builds are limited, right now full builds of the entire OpenJDK is the target
>>>>>>>>> - Hotspot can still be built on it's own, but everyone else needs to build hotspot at least once
>>>>>>>>> * Paths with multiple names can cause problems, e.g. being on system svc6, and access an exported share
>>>>>>>>> area as /net/svc6/export/foobar  instead of /export/foobar  will cause problems. Use local paths.
>>>>>>>>> 
>>>>>>>>> We know there are still issues and we will be focusing heavily on the critical ones in the next few weeks, but
>>>>>>>>> we do need the community to tell us what the critical issues really are.
>>>>>>>>> 
>>>>>>>>> Our number one priority at this time is that everyone that was able to build the old way, should be able to build
>>>>>>>>> with the new build-infra makefiles. Please help us verify that.
>>>>>>>>> 
>>>>>>>>> -kto
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 



From kelly.ohair at oracle.com  Tue Nov  6 14:26:23 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 6 Nov 2012 14:26:23 -0800
Subject: How to build 32-bit builds on 64-bit Ubuntu
In-Reply-To: <508FF934.3000701@oracle.com>
References: <508EA7EE.70704@oracle.com>
	<508F519B.1030707@oracle.com>	<508FD1AF.60902@oracle.com>
	<596E26E4-79DA-465C-A126-4130E7E1A4BF@oracle.com>
	<508FF934.3000701@oracle.com>
Message-ID: <F3BA35B6-91BC-46B6-A9C0-474C991611A3@oracle.com>

I see all kinds of 'ifdef OPENJDK' patterns in the old makefiles, enough that I never trust myself
with regards to what happens between an open and closed build.

This is something I hope we can make much clearer in the future, or at least more obvious.

-kto

On Oct 30, 2012, at 8:58 AM, Phil Race wrote:

> On 10/30/2012 7:54 AM, Kelly Ohair wrote:
>> keep in mind that a closed build will be different than an openjdk build with regards to X11 dependences
> 
> XRender is used in open and closed. I don't think there's much difference wrt X11 for open vs. closed
> for the packages. Probably zero difference at that level.
> freetype is the only extra openjdk dependency that might be considered such as its most frequently available
> as part of X11 but it doesn't have to be and in fact is needed for headless too ..
> 
> -phil.
> 
>> 
>> Sent from my iPhone
>> 
>> On Oct 30, 2012, at 6:10, Magnus Ihse Bursie<magnus.ihse.bursie at oracle.com>  wrote:
>> 
>>> On 2012-10-30 05:03, David Holmes wrote:
>>>> Hi Magnus,
>>>> 
>>>> On 30/10/2012 1:59 AM, Magnus Ihse Bursie wrote:
>>>>> I was asked to document how to build 32-bit builds on 64-bit Ubuntu.
>>>>> 
>>>>> You need to install three packages:
>>>>> sudo apt-get install libc6-dev-i386 lib32stdc++6 ia32-libs
>>>> We also had to do:
>>>> 
>>>> apt-get install libxext-dev:i386 libxrender-dev:i386 libxtst-dev:i386
>>>> 
>>>> for X11. But these are the 32-bit libs that broke their 64-bit counterparts. I don't know exactly which one is to blame, or whether it has now been fixed upstream. We have had a lot of problems trying to install 32-bit libraries on these Ubuntu systems.
>>> Yeah, I can imagine. If I understand apt-get correctly, you are forcing install of 32-bit libraries as if it were a 32-bit system you installed on.
>>> 
>>> The libxext and libxtst packages seems to provide two .a files. Are these really needed? libxrender-dev provides libXrender.so, but the 32-bit version is provided in usr/lib32/libXrender.so by the package ia32-libs. That was all that I needed to install to be able to build for X11. (Without it, I could still build headless only).
>>> 
>>> This might of course have changed from one Ubuntu release to another. I am using 11.04 Natty. (I know, it's really old, but I haven't been comfortable switching to Unity.)
>>> 
>>> 
>>>>> However, these are broken, and do not place proper symlinks. (This is a
>>>>> bug that should probably be reported upstream to Ubuntu, if anyone
>>>>> bothers...). Therefore, you also need to do:
>>>>> sudo ln -s /usr/lib32/libstdc++.so.6 /usr/lib32/libstdc++.so
>>>>> sudo ln -s /usr/lib32/libasound.so.2 /usr/lib32/libasound.so
>>>> We have not had to do this AFAIK for our servers. At least for libasound there is an asound-dev package that has to be installed. It may be lib32asound-dev (can't check as the build servers are offline due to the storm).
>>> You are indeed correct, I had installed lib32asound2 and forgot about it. I also have lib32gcc1 installed, but I don't remember if I did that manually to support building reduced OpenJDK builds.
>>> 
>>> /Magnus
>>> 
> 



From kelly.ohair at oracle.com  Tue Nov  6 16:54:39 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 6 Nov 2012 16:54:39 -0800
Subject: Fwd: New builds from the build-infra team
References: <DCA50F95-9C8E-45BB-86BE-6BE322E1E916@oracle.com>
Message-ID: <AA30E7CB-8CF3-4254-8855-57F17D239B80@oracle.com>


Just another reminder.
For those of you that have tried the new builds, thank you.

But we have gotten very few reports from anyone having problems with these new build-infra builds.
That means things are working really well and we have done a fantastic job, or people are too busy to try it.
At some point, we will have to assume that everything is working really well and get puffy chests. ;^)

So if you have some time, please give it a try, and keep us honest.

Please only reply to the build-infra-dev mailing list, or just me.

-kto


Begin forwarded message:

> From: Kelly O'Hair <kelly.ohair at oracle.com>
> Subject: New builds from the build-infra team
> Date: November 1, 2012 11:38:07 AM PDT
> To: jdk8-dev at openjdk.java.net
> Cc: build-infra-dev at openjdk.java.net, "build-dev at openjdk.java.net build-dev" <build-dev at openjdk.java.net>
> Reply-To: build-infra-dev at openjdk.java.net
> 
> 
> Pardon the wide email, but this impacts everyone building the OpenJDK jdk8/jdk8 derived forests.
> 
> Please only reply to the build-infra-dev mailing list, or just me.
> 
> With some recent integrations from the build-infra project into jdk8/jdk8 repositories, the build-infra team
> would like to get more exposure of the new builds. These jdk8/jdk8 changes will start showing up in various
> jdk8 and team forests over the next few weeks. The default is still the old builds, but both builds work in most
> cases for OpenJDK as far as we know.
> 
> At a very high level, the intent is that once you get a forest:
>  hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>  cd j8
>  sh ./get_source.sh
> 
> You should be able to simply configure&&make (the ultimate goal is this simple anyway), e.g.
>   sh ./configure
>   make NEWBUILD=true     # The NEWBUILD=true will become the default when we formally switch.
> 
> Where "make" is GNU make 3.81, and your system has all the requires packages and PATH contains the
> needed tools. Note that on Windows, MKS unix utilities cannot be used with the new builds, just CYGWIN
> is recommended at this time.
> 
> Of course, we know, it's never as easy as a simple configure&&make, and often you will need to pass in
> configure options.
> 
> What we would like to know is where a simple configure&&make does not work, and anything people had
> to do to make it work.
> 
> I know many of you are quite used to the old builds, so I have a temporary  "bridgeBuild" target
> people can try that will attempt to map the ALT_* environment variables to an appropriate configure command
> and then run that configure command and do the build, e.g.
> 
>  make NEWBUILD=true bridgeBuild
> 
> People willing to do comparisons between the old and new builds could:
>  rm -f -r build
>  time make NEWBUILD=true bridgeBuild
>  rm -f -r build
>  time make NO_DOCS=true     # Old builds do not generate javadocs by default
> 
> Any observations about speed of the builds would be appreciated, as will any impressions on what you see.
> 
> At this time, we think this is working pretty well with a few caveats:
>  * GNU make with the new builds is doing much more parallel processing and this can stress out a system
>    - Use "make JOBS=1" if you suspect a problem, then try adjusting it up slowly.
>  * Partial builds are limited, right now full builds of the entire OpenJDK is the target
>    - Hotspot can still be built on it's own, but everyone else needs to build hotspot at least once
>  * Paths with multiple names can cause problems, e.g. being on system svc6, and access an exported share
>    area as /net/svc6/export/foobar  instead of /export/foobar  will cause problems. Use local paths.
> 
> We know there are still issues and we will be focusing heavily on the critical ones in the next few weeks, but
> we do need the community to tell us what the critical issues really are.
> 
> Our number one priority at this time is that everyone that was able to build the old way, should be able to build
> with the new build-infra makefiles. Please help us verify that.
> 
> -kto
> 



From vincent.x.ryan at oracle.com  Tue Nov  6 17:24:32 2012
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Wed, 07 Nov 2012 01:24:32 +0000
Subject: New builds from the build-infra team
In-Reply-To: <FCA6CF40-49C2-4359-9ED8-E165AF47E887@oracle.com>
References: <70C78781-9057-4B6C-9F80-E39F637A9AD5@oracle.com>
	<4E118E25-D6AB-4C7E-9CF9-56495CBB5B92@oracle.com>
	<DBF14695-B54B-4092-A420-1B12D11D19A6@oracle.com>
	<A7D41D1F-A00C-4041-9609-AB987F0CEDB0@oracle.com>
	<28B38282-EFD5-46EF-B5BE-57A6110DFC51@oracle.com>
	<50942824.1000102@oracle.com>
	<7BDA9278-91CA-449D-98AD-D1520941A5E5@oracle.com>
	<7145E484-6D99-4D34-B47C-A09A9F2A5714@oracle.com>
	<FCA6CF40-49C2-4359-9ED8-E165AF47E887@oracle.com>
Message-ID: <5099B850.1080305@oracle.com>

I finally have a clean build of 
http://hg.openjdk.java.net/build-infra/jdk8 on Solaris 11.1 Sparc and 
the times for a full build
are not too shabby:

00:00:34 corba
00:04:14 hotspot
00:00:29 jaxp
00:00:40 jaxws
00:03:19 jdk
00:00:38 langtools
00:09:54 TOTAL

The fix involves adding '-lc' to LDFLAGS for almost every native
library in CompileNativeLibraries.gmk. There may be a more elegant fix
but this one works for me...




diff --git a/makefiles/CompileNativeLibraries.gmk 
b/makefiles/CompileNativeLibraries.gmk
--- a/makefiles/CompileNativeLibraries.gmk
+++ b/makefiles/CompileNativeLibraries.gmk
@@ -300,6 +300,7 @@ endif
                          $(call SET_SHARED_LIBRARY_ORIGIN),\
                 LDFLAGS_SUFFIX:=$(BUILD_LIBMLIB_LDLIBS) \
                                 $(LDFLAGS_JDKLIB_SUFFIX),\
+               LDFLAGS_SUFFIX_solaris:=-lc, \
 
VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
                 RC_FLAGS:=$(RC_FLAGS)\
                           -D "JDK_FNAME=mlib_image.dll" \
@@ -428,6 +429,7 @@ BUILD_LIBMLIB_V_CFLAGS := $(filter-out -
                 LDFLAGS:=$(LDFLAGS_JDKLIB) \
                           $(BUILD_LIBMLIB_LDLIBS) -ljava -ljvm \
                          $(call SET_SHARED_LIBRARY_ORIGIN),\
+               LDFLAGS_SUFFIX_solaris:=-lc, \
                 OBJECT_DIR:=$(JDK_OUTPUTDIR)/objs/libmlib_image_v))

  $(BUILD_LIBMLIB_IMAGE_V): $(BUILD_LIBJAVA)
@@ -710,7 +712,7 @@ endif
                 LDFLAGS:=$(LDFLAGS_JDKLIB) $(call 
SET_SHARED_LIBRARY_ORIGIN),\
 
LDFLAGS_solaris:=-R/usr/dt/lib$(OPENJDK_TARGET_CPU_ISADIR) 
-R$(OPENWIN_LIB)$(OPENJDK_TARGET_CPU_ISADIR),\
                 LDFLAGS_SUFFIX_linux:=-ljvm $(LIBM) $(LIBDL) -ljava,\
-               LDFLAGS_SUFFIX_solaris:=-ljvm $(LIBM) $(LIBDL) -ljava,\
+               LDFLAGS_SUFFIX_solaris:=-ljvm $(LIBM) $(LIBDL) -ljava -lc,\
                 LDFLAGS_SUFFIX_macosx:=-lmlib_image -ljvm $(LIBM) \
                                        -framework Cocoa \
                                        -framework OpenGL \
@@ -966,7 +968,7 @@ endif
                                  -export:ZIP_ReadEntry 
-export:ZIP_GetNextEntry jvm.lib \
                                  $(WIN_JAVA_LIB),\
                 LDFLAGS_SUFFIX_linux:=-ljvm -ljava $(LIBZ),\
-               LDFLAGS_SUFFIX_solaris:=-ljvm -ljava $(LIBZ),\
+               LDFLAGS_SUFFIX_solaris:=-ljvm -ljava $(LIBZ) -lc,\
                 LDFLAGS_SUFFIX_macosx:=$(LIBZ) -ljava -ljvm,\
 
VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
                 RC_FLAGS:=$(RC_FLAGS)\
@@ -1144,7 +1146,7 @@ endif # OPENJDK_TARGET_OS
                 LDFLAGS:=$(LDFLAGS_JDKLIB) \
                          $(call SET_SHARED_LIBRARY_ORIGIN),\
                 LDFLAGS_SUFFIX_linux:=$(LIBDL),\
-               LDFLAGS_SUFFIX_solaris:=$(LIBDL),\
+               LDFLAGS_SUFFIX_solaris:=$(LIBDL) -lc,\
                 LDFLAGS_SUFFIX_windows:=$(LDFLAGS_JDKLIB_SUFFIX),\
                 LDFLAGS_SUFFIX:=,\
 
VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
@@ -1187,6 +1189,7 @@ endif
                 LDFLAGS_windows:=netapi32.lib user32.lib mpr.lib 
advapi32.lib,\
                 LDFLAGS_SUFFIX_windows:=$(LDFLAGS_JDKLIB_SUFFIX),\
                 LDFLAGS_SUFFIX:=,\
+               LDFLAGS_SUFFIX_solaris:=-lc,\
                 EXCLUDE_FILES:=$(LIBJAAS_EXCLUDE_FILES),\
 
VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
                 RC_FLAGS:=$(RC_FLAGS) \
@@ -1217,6 +1220,7 @@ BUILD_LIBRARIES += $(BUILD_LIBJAAS)
                 LDFLAGS_SUFFIX_linux:=$(LIBDL),\
                 LDFLAGS_SUFFIX_windows:=$(LDFLAGS_JDKLIB_SUFFIX) $(LIBDL),\
                 LDFLAGS_SUFFIX_macosx:=                         $(LIBDL),\
+               LDFLAGS_SUFFIX_solaris:=-lc,\
                 LDFLAGS_SUFFIX:=,\
 
VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
                 RC_FLAGS:=$(RC_FLAGS)\
@@ -1259,7 +1263,7 @@ ifdef OPENJDK
                           $(call SET_SHARED_LIBRARY_ORIGIN), \
 
LDFLAGS_solaris:=/usr/lib$(OPENJDK_TARGET_CPU_ISADIR)/libm.so.2,\
                 LDFLAGS_windows:=$(WIN_AWT_LIB) $(WIN_JAVA_LIB),\
-               LDFLAGS_SUFFIX_solaris:=-lawt -ljava -ljvm,\
+               LDFLAGS_SUFFIX_solaris:=-lawt -ljava -ljvm -lc,\
                 LDFLAGS_SUFFIX_macosx:=$(LIBM) -lawt -ljava -ljvm,\
                 LDFLAGS_SUFFIX_linux:=-lm -lawt -ljava -ljvm,\
 
VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
@@ -1716,7 +1720,7 @@ endif
                                 -framework Cocoa -framework Security 
-framework ApplicationServices,\
                 LDFLAGS_SUFFIX:=$(LIBINSTRUMENT_LDFLAGS_SUFFIX),\
                 LDFLAGS_SUFFIX_macosx:=-liconv $(LIBZ),\
-               LDFLAGS_SUFFIX_solaris:=$(LIBZ) -L 
$(INSTALL_LIBRARIES_HERE)/jli -ljli $(LIBDL),\
+               LDFLAGS_SUFFIX_solaris:=$(LIBZ) -L 
$(INSTALL_LIBRARIES_HERE)/jli -ljli $(LIBDL) -lc,\
                 LDFLAGS_SUFFIX_linux:=$(LIBZ) -L 
$(INSTALL_LIBRARIES_HERE)/jli -ljli $(LIBDL),\
 
VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
                 RC_FLAGS:=$(RC_FLAGS)\
@@ -1858,6 +1862,7 @@ BUILD_LIBRARIES += $(BUILD_LIBHPROF)
 
MAPFILE:=$(JDK_TOPDIR)/makefiles/mapfiles/libjava_crw_demo/mapfile-vers, \
                 LDFLAGS:=$(LDFLAGS_JDKLIB) \
                          $(call SET_SHARED_LIBRARY_ORIGIN),\
+               LDFLAGS_SUFFIX_solaris:=-lc, \
 
VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
                 RC_FLAGS:=$(RC_FLAGS)\
                           -D "JDK_FNAME=java_crw_demo.dll" \
@@ -2488,7 +2493,7 @@ endif
                 LDFLAGS_linux:=$(call SET_SHARED_LIBRARY_ORIGIN,/..),\
                 LDFLAGS_solaris:=$(call SET_SHARED_LIBRARY_ORIGIN,/..) \
 
-R/usr/dt/lib$(OPENJDK_TARGET_CPU_ISADIR) \
- 
-R$(OPENWIN_LIB)$(OPENJDK_TARGET_CPU_ISADIR),\
+ 
-R$(OPENWIN_LIB)$(OPENJDK_TARGET_CPU_ISADIR) -lc,\
                 LDFLAGS_macosx:=$(call SET_SHARED_LIBRARY_ORIGIN).,\
                 REORDER:=$(LIBAWT_HEADLESS_REORDER), \
                 LDFLAGS_SUFFIX_linux:=-ljvm -lawt -lm $(LIBDL) -ljava,\
@@ -2662,6 +2667,7 @@ endif # OPENJDK_TARGET_OS
                 LDFLAGS:=$(LDFLAGS_JDKLIB) \
                          $(call SET_SHARED_LIBRARY_ORIGIN),\
                 LDFLAGS_SUFFIX:=$(LIBSPLASHSCREEN_LDFLAGS_SUFFIX) $(LIBZ),\
+               LDFLAGS_SUFFIX_solaris:=-lc,\
 
VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
                 RC_FLAGS:=$(RC_FLAGS)\
                           -D "JDK_FNAME=splashscreen.dll" \
@@ -2737,6 +2743,7 @@ endif
                          $(call SET_SHARED_LIBRARY_ORIGIN),\
                 LDFLAGS_SUFFIX_posix:=$(LIBDL), \
                 LDFLAGS_SUFFIX_windows:=winscard.lib,\
+               LDFLAGS_SUFFIX_solaris:=-lc,\
 
VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
                 RC_FLAGS:=$(RC_FLAGS)\
                           -D "JDK_FNAME=j2pcsc.dll" \
@@ -2764,6 +2771,7 @@ ifneq ($(OPENJDK_TARGET_OS), windows)
                 LDFLAGS:=$(LDFLAGS_JDKLIB) \
                          $(call SET_SHARED_LIBRARY_ORIGIN),\
                 LDFLAGS_SUFFIX:=$(LIBDL), \
+               LDFLAGS_SUFFIX_solaris:=-lc,\
                 OBJECT_DIR:=$(JDK_OUTPUTDIR)/objs/libj2gss))

  BUILD_LIBRARIES += $(BUILD_LIBJ2GSS)
@@ -2858,6 +2866,7 @@ endif
                 LDFLAGS:=$(LDFLAGS_JDKLIB) \
                          $(call SET_SHARED_LIBRARY_ORIGIN),\
                 LDFLAGS_SUFFIX_posix:=$(LIBDL), \
+               LDFLAGS_SUFFIX_solaris:=-lc, \
 
VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
                 RC_FLAGS:=$(RC_FLAGS)\
                           -D "JDK_FNAME=j2pkcs11.dll" \





On 06/11/2012 18:10, Kelly O'Hair wrote:
>
> On Nov 6, 2012, at 9:34 AM, Vincent Ryan wrote:
>
>> I picked up the 2 changesets that were pushed over the weekend. The build makes more
>> progress but it still fails due to missing C lib. I guess there are a few more corner cases.
>>
>> Is there a way to activate more debugging during the build? I'd like to examine the exact
>> compiler flags that are in use when the failure occurs.
>
> Use
>
>     gmake LOG=debug
>
> -kto
>
>>
>>
>>
>> On 6 Nov 2012, at 16:33, Kelly O'Hair wrote:
>>
>>> If you get a chance, could you try this experiment again with the latest in jdk8/build forest?
>>> I fixed a few more libraries that I think had a missing -lc.
>>>
>>> I don't have access to a Solaris SPARC 11.1 system, and so far the issues you have run into seem to
>>> be unique to SPARCV9 builds on 11.1, the Solaris X64 11.1 systems I have access to don't seem to reproduce this issue.
>>> I can only assume that the compiler or the system behaves differently between SPARCV9 and X64 on 11.1. :^(
>>>
>>> -kto
>>>
>>> On Nov 2, 2012, at 1:08 PM, Vincent Ryan wrote:
>>>
>>>> Thanks Kelly.
>>>>
>>>> I re-ran the build with your patch and got better results but there
>>>> seems to be another linker problem later in the jdk build.
>>>>
>>>> Here's the tail of the build output:
>>>>
>>>> :
>>>> :
>>>> Undefined                       first referenced
>>>> symbol                             in file
>>>> free /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>> __iob /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>> abort /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>> snprintf /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>> calloc /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>> malloc /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>> memcpy /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>> memset /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>> strcmp /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>> strlen /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>> realloc /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>> strncmp /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>> fprintf /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>> ld: fatal: symbol referencing errors. No output written to /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libjava_crw_demo.so
>>>> gmake[3]: *** [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libjava_crw_demo.so] Error 1
>>>> gmake[3]: *** Waiting for unfinished jobs....
>>>> Undefined                       first referenced
>>>> symbol                             in file
>>>> exit /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>> free /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>> __iob /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>> abort /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
>>>> iconv /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>>> __ctype /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
>>>> iconv_open /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>>> calloc /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>> memcpy /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>>> strcmp /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>> strdup /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>> strlen /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
>>>> nl_langinfo /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>>> sprintf /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
>>>> setlocale /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>>> iconv_close /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>>> fprintf /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>> ld: fatal: symbol referencing errors. No output written to /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libnpt.so
>>>> gmake[3]: *** [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libnpt.so] Error 1
>>>> gmake[3]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>> gmake[2]: *** [libs-only] Error 2
>>>> gmake[2]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>> make[1]: *** [jdk-only] Error 2
>>>> make[1]: Leaving directory `/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release'
>>>> make: *** [all] Error 2
>>>> t4%
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 02/11/2012 18:38, Kelly O'Hair wrote:
>>>>>
>>>>> On Nov 2, 2012, at 11:17 AM, Vincent Ryan wrote:
>>>>>
>>>>>> That attachment got dropped when I re-sent my message (previously I wasn't a member of the build-infra-dev email alias). I've attached it again in case it proves useful.
>>>>>>
>>>>>> <config.status>
>>>>>>
>>>>>>
>>>>>> I realize Solaris 11 is not an official build platform for JDK8 but I thought I'd give it a spin on a reasonably
>>>>>> beefy server.
>>>>>
>>>>> It's great that you tried this, thanks.
>>>>>
>>>>> As far as I can tell, this seems to be a sparcv9 Solaris 11.1 issue, because I tried Solaris 11.1 X64 and it worked fine.
>>>>> However, the link of libhprof.so IS missing the -lc option.
>>>>> So why sparcv9 would complain and amd64 would not is a bit puzzling.
>>>>>
>>>>> The change I think needs to be made is:
>>>>>
>>>>> diff --git a/makefiles/CompileNativeLibraries.gmk b/makefiles/CompileNativeLibraries.gmk
>>>>> --- a/makefiles/CompileNativeLibraries.gmk
>>>>> +++ b/makefiles/CompileNativeLibraries.gmk
>>>>> @@ -1807,7 +1807,7 @@
>>>>> BUILD_LIBHPROF_LDFLAGS:=
>>>>>
>>>>> ifeq ($(OPENJDK_TARGET_OS),solaris)
>>>>> -     BUILD_LIBHPROF_LDFLAGS += -lsocket -lnsl
>>>>> +     BUILD_LIBHPROF_LDFLAGS += -lsocket -lnsl -lc
>>>>> endif
>>>>>
>>>>> LIBHPROF_OPTIMIZATION:=HIGHEST
>>>>>
>>>>>
>>>>>
>>>>> But I have not tested it yet.
>>>>> Did you want to give this patch a spin?
>>>>>
>>>>> -kto
>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>>
>>>>>> On 2 Nov 2012, at 17:45, Kelly O'Hair wrote:
>>>>>>
>>>>>>> The attachment is missing.
>>>>>>>
>>>>>>> This looks like the  -lc   is missing from the creation of hprof, we should never let libc be an implicit dependency.
>>>>>>>
>>>>>>> I wonder if Solaris 11.1 has tightened up the rules on implicit dependencies. We have not seen this on Solaris 10.
>>>>>>> We just got svc6 setup as a 11.1 system, I'll see if it reproduces there.
>>>>>>>
>>>>>>> And thank you for reporting this. Although Solaris 11.1 is not one of our critical systems, it's very important that this works.
>>>>>>>
>>>>>>> -kto
>>>>>>>
>>>>>>> On Nov 2, 2012, at 9:38 AM, Vincent Ryan wrote:
>>>>>>>
>>>>>>>>> From: Vincent Ryan <vincent.x.ryan at oracle.com>
>>>>>>>>> Subject: Re: New builds from the build-infra team
>>>>>>>>> Date: 2 November 2012 15:48:03 GMT
>>>>>>>>> To: build-infra-dev at openjdk.java.net
>>>>>>>>>
>>>>>>>>> I tried this out on the latest Solaris 11 Update 1 (sparc) but the build encountered problems locating libc when
>>>>>>>>> building jdk. (BTW the old build works correctly, just slower)
>>>>>>>>>
>>>>>>>>> :
>>>>>>>>> :
>>>>>>>>> strerror                            /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>>>>> vfprintf                            /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_error.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>>>>> fprintf                             /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_init.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>>>>> gethrvtime                          /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>>>>> ld: fatal: symbol referencing errors. No output written to /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so
>>>>>>>>> gmake[3]: *** [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so] Error 1
>>>>>>>>> gmake[3]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>>>>>>> gmake[2]: *** [libs-only] Error 2
>>>>>>>>> gmake[2]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>>>>>>> make[1]: *** [jdk-only] Error 2
>>>>>>>>> make[1]: Leaving directory `/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release'
>>>>>>>>> make: *** [all] Error 2
>>>>>>>>> t4%
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> FYI I've attached the config script that was generated by configure.sh.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 1 Nov 2012, at 18:38, Kelly O'Hair wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Pardon the wide email, but this impacts everyone building the OpenJDK jdk8/jdk8 derived forests.
>>>>>>>>>>
>>>>>>>>>> Please only reply to the build-infra-dev mailing list, or just me.
>>>>>>>>>>
>>>>>>>>>> With some recent integrations from the build-infra project into jdk8/jdk8 repositories, the build-infra team
>>>>>>>>>> would like to get more exposure of the new builds. These jdk8/jdk8 changes will start showing up in various
>>>>>>>>>> jdk8 and team forests over the next few weeks. The default is still the old builds, but both builds work in most
>>>>>>>>>> cases for OpenJDK as far as we know.
>>>>>>>>>>
>>>>>>>>>> At a very high level, the intent is that once you get a forest:
>>>>>>>>>> hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>>>>>>>>>> cd j8
>>>>>>>>>> sh ./get_source.sh
>>>>>>>>>>
>>>>>>>>>> You should be able to simply configure&&make (the ultimate goal is this simple anyway), e.g.
>>>>>>>>>> sh ./configure
>>>>>>>>>> make NEWBUILD=true     # The NEWBUILD=true will become the default when we formally switch.
>>>>>>>>>>
>>>>>>>>>> Where "make" is GNU make 3.81, and your system has all the requires packages and PATH contains the
>>>>>>>>>> needed tools. Note that on Windows, MKS unix utilities cannot be used with the new builds, just CYGWIN
>>>>>>>>>> is recommended at this time.
>>>>>>>>>>
>>>>>>>>>> Of course, we know, it's never as easy as a simple configure&&make, and often you will need to pass in
>>>>>>>>>> configure options.
>>>>>>>>>>
>>>>>>>>>> What we would like to know is where a simple configure&&make does not work, and anything people had
>>>>>>>>>> to do to make it work.
>>>>>>>>>>
>>>>>>>>>> I know many of you are quite used to the old builds, so I have a temporary  "bridgeBuild" target
>>>>>>>>>> people can try that will attempt to map the ALT_* environment variables to an appropriate configure command
>>>>>>>>>> and then run that configure command and do the build, e.g.
>>>>>>>>>>
>>>>>>>>>> make NEWBUILD=true bridgeBuild
>>>>>>>>>>
>>>>>>>>>> People willing to do comparisons between the old and new builds could:
>>>>>>>>>> rm -f -r build
>>>>>>>>>> time make NEWBUILD=true bridgeBuild
>>>>>>>>>> rm -f -r build
>>>>>>>>>> time make NO_DOCS=true     # Old builds do not generate javadocs by default
>>>>>>>>>>
>>>>>>>>>> Any observations about speed of the builds would be appreciated, as will any impressions on what you see.
>>>>>>>>>>
>>>>>>>>>> At this time, we think this is working pretty well with a few caveats:
>>>>>>>>>> * GNU make with the new builds is doing much more parallel processing and this can stress out a system
>>>>>>>>>> - Use "make JOBS=1" if you suspect a problem, then try adjusting it up slowly.
>>>>>>>>>> * Partial builds are limited, right now full builds of the entire OpenJDK is the target
>>>>>>>>>> - Hotspot can still be built on it's own, but everyone else needs to build hotspot at least once
>>>>>>>>>> * Paths with multiple names can cause problems, e.g. being on system svc6, and access an exported share
>>>>>>>>>> area as /net/svc6/export/foobar  instead of /export/foobar  will cause problems. Use local paths.
>>>>>>>>>>
>>>>>>>>>> We know there are still issues and we will be focusing heavily on the critical ones in the next few weeks, but
>>>>>>>>>> we do need the community to tell us what the critical issues really are.
>>>>>>>>>>
>>>>>>>>>> Our number one priority at this time is that everyone that was able to build the old way, should be able to build
>>>>>>>>>> with the new build-infra makefiles. Please help us verify that.
>>>>>>>>>>
>>>>>>>>>> -kto
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From staffan.larsen at oracle.com  Wed Nov  7 00:55:32 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 7 Nov 2012 09:55:32 +0100
Subject: Cannot list safely more than 10000 paths
Message-ID: <A731A037-4BF2-4FBB-A73A-EDF752A61D36@oracle.com>

I'm trying out the latest in jdk8/jdk8 on OS X and get the error below.

This is on OS X 10.8.2 with both closed and open repos.

Any ideas?

/Staffan

Generating jobjc framework bridge
Compiling 4 files for BUILD_BREAKITERATOR
Generating HTML DTD file
[Parsed DTD html32 in 294ms]
CompileJavaClasses.gmk:402: warning: overriding commands for target `/Users/staffan/mercurial/jdk8/build/macosx-x86_64-normal-server-release/jdk/gensrc_headers/_the.headers'
CompileJavaClasses.gmk:295: warning: ignoring old commands for target `/Users/staffan/mercurial/jdk8/build/macosx-x86_64-normal-server-release/jdk/gensrc_headers/_the.headers'
CompileJavaClasses.gmk:295: *** Cannot list safely more than 10000 paths. BUILD_JDK_SRCS has 10070 paths!.  Stop.
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [classes-only] Error 2
make[1]: *** [jdk-only] Error 2
make: *** [all] Error 2

From erik.joelsson at oracle.com  Wed Nov  7 01:01:19 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 07 Nov 2012 10:01:19 +0100
Subject: New builds from the build-infra team
In-Reply-To: <5099B850.1080305@oracle.com>
References: <70C78781-9057-4B6C-9F80-E39F637A9AD5@oracle.com>	<4E118E25-D6AB-4C7E-9CF9-56495CBB5B92@oracle.com>	<DBF14695-B54B-4092-A420-1B12D11D19A6@oracle.com>	<A7D41D1F-A00C-4041-9609-AB987F0CEDB0@oracle.com>	<28B38282-EFD5-46EF-B5BE-57A6110DFC51@oracle.com>	<50942824.1000102@oracle.com>	<7BDA9278-91CA-449D-98AD-D1520941A5E5@oracle.com>	<7145E484-6D99-4D34-B47C-A09A9F2A5714@oracle.com>	<FCA6CF40-49C2-4359-9ED8-E165AF47E887@oracle.com>
	<5099B850.1080305@oracle.com>
Message-ID: <509A235F.3050600@oracle.com>

I will try these changes and see if they have any impact on our old vs 
new build comparison. Thanks for the patch!

/Erik

On 2012-11-07 02:24, Vincent Ryan wrote:
> I finally have a clean build of 
> http://hg.openjdk.java.net/build-infra/jdk8 on Solaris 11.1 Sparc and 
> the times for a full build
> are not too shabby:
>
> 00:00:34 corba
> 00:04:14 hotspot
> 00:00:29 jaxp
> 00:00:40 jaxws
> 00:03:19 jdk
> 00:00:38 langtools
> 00:09:54 TOTAL
>
> The fix involves adding '-lc' to LDFLAGS for almost every native
> library in CompileNativeLibraries.gmk. There may be a more elegant fix
> but this one works for me...
>
>
>
>
> diff --git a/makefiles/CompileNativeLibraries.gmk 
> b/makefiles/CompileNativeLibraries.gmk
> --- a/makefiles/CompileNativeLibraries.gmk
> +++ b/makefiles/CompileNativeLibraries.gmk
> @@ -300,6 +300,7 @@ endif
>                          $(call SET_SHARED_LIBRARY_ORIGIN),\
>                 LDFLAGS_SUFFIX:=$(BUILD_LIBMLIB_LDLIBS) \
>                                 $(LDFLAGS_JDKLIB_SUFFIX),\
> +               LDFLAGS_SUFFIX_solaris:=-lc, \
>
> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>                 RC_FLAGS:=$(RC_FLAGS)\
>                           -D "JDK_FNAME=mlib_image.dll" \
> @@ -428,6 +429,7 @@ BUILD_LIBMLIB_V_CFLAGS := $(filter-out -
>                 LDFLAGS:=$(LDFLAGS_JDKLIB) \
>                           $(BUILD_LIBMLIB_LDLIBS) -ljava -ljvm \
>                          $(call SET_SHARED_LIBRARY_ORIGIN),\
> +               LDFLAGS_SUFFIX_solaris:=-lc, \
>                 OBJECT_DIR:=$(JDK_OUTPUTDIR)/objs/libmlib_image_v))
>
>  $(BUILD_LIBMLIB_IMAGE_V): $(BUILD_LIBJAVA)
> @@ -710,7 +712,7 @@ endif
>                 LDFLAGS:=$(LDFLAGS_JDKLIB) $(call 
> SET_SHARED_LIBRARY_ORIGIN),\
>
> LDFLAGS_solaris:=-R/usr/dt/lib$(OPENJDK_TARGET_CPU_ISADIR) 
> -R$(OPENWIN_LIB)$(OPENJDK_TARGET_CPU_ISADIR),\
>                 LDFLAGS_SUFFIX_linux:=-ljvm $(LIBM) $(LIBDL) -ljava,\
> -               LDFLAGS_SUFFIX_solaris:=-ljvm $(LIBM) $(LIBDL) -ljava,\
> +               LDFLAGS_SUFFIX_solaris:=-ljvm $(LIBM) $(LIBDL) -ljava 
> -lc,\
>                 LDFLAGS_SUFFIX_macosx:=-lmlib_image -ljvm $(LIBM) \
>                                        -framework Cocoa \
>                                        -framework OpenGL \
> @@ -966,7 +968,7 @@ endif
>                                  -export:ZIP_ReadEntry 
> -export:ZIP_GetNextEntry jvm.lib \
>                                  $(WIN_JAVA_LIB),\
>                 LDFLAGS_SUFFIX_linux:=-ljvm -ljava $(LIBZ),\
> -               LDFLAGS_SUFFIX_solaris:=-ljvm -ljava $(LIBZ),\
> +               LDFLAGS_SUFFIX_solaris:=-ljvm -ljava $(LIBZ) -lc,\
>                 LDFLAGS_SUFFIX_macosx:=$(LIBZ) -ljava -ljvm,\
>
> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>                 RC_FLAGS:=$(RC_FLAGS)\
> @@ -1144,7 +1146,7 @@ endif # OPENJDK_TARGET_OS
>                 LDFLAGS:=$(LDFLAGS_JDKLIB) \
>                          $(call SET_SHARED_LIBRARY_ORIGIN),\
>                 LDFLAGS_SUFFIX_linux:=$(LIBDL),\
> -               LDFLAGS_SUFFIX_solaris:=$(LIBDL),\
> +               LDFLAGS_SUFFIX_solaris:=$(LIBDL) -lc,\
>                 LDFLAGS_SUFFIX_windows:=$(LDFLAGS_JDKLIB_SUFFIX),\
>                 LDFLAGS_SUFFIX:=,\
>
> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
> @@ -1187,6 +1189,7 @@ endif
>                 LDFLAGS_windows:=netapi32.lib user32.lib mpr.lib 
> advapi32.lib,\
>                 LDFLAGS_SUFFIX_windows:=$(LDFLAGS_JDKLIB_SUFFIX),\
>                 LDFLAGS_SUFFIX:=,\
> +               LDFLAGS_SUFFIX_solaris:=-lc,\
>                 EXCLUDE_FILES:=$(LIBJAAS_EXCLUDE_FILES),\
>
> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>                 RC_FLAGS:=$(RC_FLAGS) \
> @@ -1217,6 +1220,7 @@ BUILD_LIBRARIES += $(BUILD_LIBJAAS)
>                 LDFLAGS_SUFFIX_linux:=$(LIBDL),\
>                 LDFLAGS_SUFFIX_windows:=$(LDFLAGS_JDKLIB_SUFFIX) 
> $(LIBDL),\
>                 LDFLAGS_SUFFIX_macosx:=                         
> $(LIBDL),\
> +               LDFLAGS_SUFFIX_solaris:=-lc,\
>                 LDFLAGS_SUFFIX:=,\
>
> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>                 RC_FLAGS:=$(RC_FLAGS)\
> @@ -1259,7 +1263,7 @@ ifdef OPENJDK
>                           $(call SET_SHARED_LIBRARY_ORIGIN), \
>
> LDFLAGS_solaris:=/usr/lib$(OPENJDK_TARGET_CPU_ISADIR)/libm.so.2,\
>                 LDFLAGS_windows:=$(WIN_AWT_LIB) $(WIN_JAVA_LIB),\
> -               LDFLAGS_SUFFIX_solaris:=-lawt -ljava -ljvm,\
> +               LDFLAGS_SUFFIX_solaris:=-lawt -ljava -ljvm -lc,\
>                 LDFLAGS_SUFFIX_macosx:=$(LIBM) -lawt -ljava -ljvm,\
>                 LDFLAGS_SUFFIX_linux:=-lm -lawt -ljava -ljvm,\
>
> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
> @@ -1716,7 +1720,7 @@ endif
>                                 -framework Cocoa -framework Security 
> -framework ApplicationServices,\
>                 LDFLAGS_SUFFIX:=$(LIBINSTRUMENT_LDFLAGS_SUFFIX),\
>                 LDFLAGS_SUFFIX_macosx:=-liconv $(LIBZ),\
> -               LDFLAGS_SUFFIX_solaris:=$(LIBZ) -L 
> $(INSTALL_LIBRARIES_HERE)/jli -ljli $(LIBDL),\
> +               LDFLAGS_SUFFIX_solaris:=$(LIBZ) -L 
> $(INSTALL_LIBRARIES_HERE)/jli -ljli $(LIBDL) -lc,\
>                 LDFLAGS_SUFFIX_linux:=$(LIBZ) -L 
> $(INSTALL_LIBRARIES_HERE)/jli -ljli $(LIBDL),\
>
> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>                 RC_FLAGS:=$(RC_FLAGS)\
> @@ -1858,6 +1862,7 @@ BUILD_LIBRARIES += $(BUILD_LIBHPROF)
>
> MAPFILE:=$(JDK_TOPDIR)/makefiles/mapfiles/libjava_crw_demo/mapfile-vers, 
> \
>                 LDFLAGS:=$(LDFLAGS_JDKLIB) \
>                          $(call SET_SHARED_LIBRARY_ORIGIN),\
> +               LDFLAGS_SUFFIX_solaris:=-lc, \
>
> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>                 RC_FLAGS:=$(RC_FLAGS)\
>                           -D "JDK_FNAME=java_crw_demo.dll" \
> @@ -2488,7 +2493,7 @@ endif
>                 LDFLAGS_linux:=$(call SET_SHARED_LIBRARY_ORIGIN,/..),\
>                 LDFLAGS_solaris:=$(call SET_SHARED_LIBRARY_ORIGIN,/..) \
>
> -R/usr/dt/lib$(OPENJDK_TARGET_CPU_ISADIR) \
> - -R$(OPENWIN_LIB)$(OPENJDK_TARGET_CPU_ISADIR),\
> + -R$(OPENWIN_LIB)$(OPENJDK_TARGET_CPU_ISADIR) -lc,\
>                 LDFLAGS_macosx:=$(call SET_SHARED_LIBRARY_ORIGIN).,\
>                 REORDER:=$(LIBAWT_HEADLESS_REORDER), \
>                 LDFLAGS_SUFFIX_linux:=-ljvm -lawt -lm $(LIBDL) -ljava,\
> @@ -2662,6 +2667,7 @@ endif # OPENJDK_TARGET_OS
>                 LDFLAGS:=$(LDFLAGS_JDKLIB) \
>                          $(call SET_SHARED_LIBRARY_ORIGIN),\
>                 LDFLAGS_SUFFIX:=$(LIBSPLASHSCREEN_LDFLAGS_SUFFIX) 
> $(LIBZ),\
> +               LDFLAGS_SUFFIX_solaris:=-lc,\
>
> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>                 RC_FLAGS:=$(RC_FLAGS)\
>                           -D "JDK_FNAME=splashscreen.dll" \
> @@ -2737,6 +2743,7 @@ endif
>                          $(call SET_SHARED_LIBRARY_ORIGIN),\
>                 LDFLAGS_SUFFIX_posix:=$(LIBDL), \
>                 LDFLAGS_SUFFIX_windows:=winscard.lib,\
> +               LDFLAGS_SUFFIX_solaris:=-lc,\
>
> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>                 RC_FLAGS:=$(RC_FLAGS)\
>                           -D "JDK_FNAME=j2pcsc.dll" \
> @@ -2764,6 +2771,7 @@ ifneq ($(OPENJDK_TARGET_OS), windows)
>                 LDFLAGS:=$(LDFLAGS_JDKLIB) \
>                          $(call SET_SHARED_LIBRARY_ORIGIN),\
>                 LDFLAGS_SUFFIX:=$(LIBDL), \
> +               LDFLAGS_SUFFIX_solaris:=-lc,\
>                 OBJECT_DIR:=$(JDK_OUTPUTDIR)/objs/libj2gss))
>
>  BUILD_LIBRARIES += $(BUILD_LIBJ2GSS)
> @@ -2858,6 +2866,7 @@ endif
>                 LDFLAGS:=$(LDFLAGS_JDKLIB) \
>                          $(call SET_SHARED_LIBRARY_ORIGIN),\
>                 LDFLAGS_SUFFIX_posix:=$(LIBDL), \
> +               LDFLAGS_SUFFIX_solaris:=-lc, \
>
> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>                 RC_FLAGS:=$(RC_FLAGS)\
>                           -D "JDK_FNAME=j2pkcs11.dll" \
>
>
>
>
>
> On 06/11/2012 18:10, Kelly O'Hair wrote:
>>
>> On Nov 6, 2012, at 9:34 AM, Vincent Ryan wrote:
>>
>>> I picked up the 2 changesets that were pushed over the weekend. The 
>>> build makes more
>>> progress but it still fails due to missing C lib. I guess there are 
>>> a few more corner cases.
>>>
>>> Is there a way to activate more debugging during the build? I'd like 
>>> to examine the exact
>>> compiler flags that are in use when the failure occurs.
>>
>> Use
>>
>>     gmake LOG=debug
>>
>> -kto
>>
>>>
>>>
>>>
>>> On 6 Nov 2012, at 16:33, Kelly O'Hair wrote:
>>>
>>>> If you get a chance, could you try this experiment again with the 
>>>> latest in jdk8/build forest?
>>>> I fixed a few more libraries that I think had a missing -lc.
>>>>
>>>> I don't have access to a Solaris SPARC 11.1 system, and so far the 
>>>> issues you have run into seem to
>>>> be unique to SPARCV9 builds on 11.1, the Solaris X64 11.1 systems I 
>>>> have access to don't seem to reproduce this issue.
>>>> I can only assume that the compiler or the system behaves 
>>>> differently between SPARCV9 and X64 on 11.1. :^(
>>>>
>>>> -kto
>>>>
>>>> On Nov 2, 2012, at 1:08 PM, Vincent Ryan wrote:
>>>>
>>>>> Thanks Kelly.
>>>>>
>>>>> I re-ran the build with your patch and got better results but there
>>>>> seems to be another linker problem later in the jdk build.
>>>>>
>>>>> Here's the tail of the build output:
>>>>>
>>>>> :
>>>>> :
>>>>> Undefined                       first referenced
>>>>> symbol                             in file
>>>>> free 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> __iob 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> abort 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> snprintf 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> calloc 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> malloc 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> memcpy 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> memset 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> strcmp 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> strlen 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> realloc 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> strncmp 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> fprintf 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> ld: fatal: symbol referencing errors. No output written to 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libjava_crw_demo.so 
>>>>>
>>>>> gmake[3]: *** 
>>>>> [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libjava_crw_demo.so] 
>>>>> Error 1
>>>>> gmake[3]: *** Waiting for unfinished jobs....
>>>>> Undefined                       first referenced
>>>>> symbol                             in file
>>>>> exit 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>>> free 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>>> __iob 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>>> abort 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
>>>>> iconv 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>>>> __ctype 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
>>>>> iconv_open 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>>>> calloc 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>>> memcpy 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>>>> strcmp 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>>> strdup 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>>> strlen 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
>>>>> nl_langinfo 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>>>> sprintf 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
>>>>> setlocale 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>>>> iconv_close 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>>>> fprintf 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>>> ld: fatal: symbol referencing errors. No output written to 
>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libnpt.so 
>>>>>
>>>>> gmake[3]: *** 
>>>>> [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libnpt.so] 
>>>>> Error 1
>>>>> gmake[3]: Leaving directory 
>>>>> `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>>> gmake[2]: *** [libs-only] Error 2
>>>>> gmake[2]: Leaving directory 
>>>>> `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>>> make[1]: *** [jdk-only] Error 2
>>>>> make[1]: Leaving directory 
>>>>> `/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release'
>>>>> make: *** [all] Error 2
>>>>> t4%
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 02/11/2012 18:38, Kelly O'Hair wrote:
>>>>>>
>>>>>> On Nov 2, 2012, at 11:17 AM, Vincent Ryan wrote:
>>>>>>
>>>>>>> That attachment got dropped when I re-sent my message 
>>>>>>> (previously I wasn't a member of the build-infra-dev email 
>>>>>>> alias). I've attached it again in case it proves useful.
>>>>>>>
>>>>>>> <config.status>
>>>>>>>
>>>>>>>
>>>>>>> I realize Solaris 11 is not an official build platform for JDK8 
>>>>>>> but I thought I'd give it a spin on a reasonably
>>>>>>> beefy server.
>>>>>>
>>>>>> It's great that you tried this, thanks.
>>>>>>
>>>>>> As far as I can tell, this seems to be a sparcv9 Solaris 11.1 
>>>>>> issue, because I tried Solaris 11.1 X64 and it worked fine.
>>>>>> However, the link of libhprof.so IS missing the -lc option.
>>>>>> So why sparcv9 would complain and amd64 would not is a bit puzzling.
>>>>>>
>>>>>> The change I think needs to be made is:
>>>>>>
>>>>>> diff --git a/makefiles/CompileNativeLibraries.gmk 
>>>>>> b/makefiles/CompileNativeLibraries.gmk
>>>>>> --- a/makefiles/CompileNativeLibraries.gmk
>>>>>> +++ b/makefiles/CompileNativeLibraries.gmk
>>>>>> @@ -1807,7 +1807,7 @@
>>>>>> BUILD_LIBHPROF_LDFLAGS:=
>>>>>>
>>>>>> ifeq ($(OPENJDK_TARGET_OS),solaris)
>>>>>> -     BUILD_LIBHPROF_LDFLAGS += -lsocket -lnsl
>>>>>> +     BUILD_LIBHPROF_LDFLAGS += -lsocket -lnsl -lc
>>>>>> endif
>>>>>>
>>>>>> LIBHPROF_OPTIMIZATION:=HIGHEST
>>>>>>
>>>>>>
>>>>>>
>>>>>> But I have not tested it yet.
>>>>>> Did you want to give this patch a spin?
>>>>>>
>>>>>> -kto
>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>>
>>>>>>> On 2 Nov 2012, at 17:45, Kelly O'Hair wrote:
>>>>>>>
>>>>>>>> The attachment is missing.
>>>>>>>>
>>>>>>>> This looks like the  -lc   is missing from the creation of 
>>>>>>>> hprof, we should never let libc be an implicit dependency.
>>>>>>>>
>>>>>>>> I wonder if Solaris 11.1 has tightened up the rules on implicit 
>>>>>>>> dependencies. We have not seen this on Solaris 10.
>>>>>>>> We just got svc6 setup as a 11.1 system, I'll see if it 
>>>>>>>> reproduces there.
>>>>>>>>
>>>>>>>> And thank you for reporting this. Although Solaris 11.1 is not 
>>>>>>>> one of our critical systems, it's very important that this works.
>>>>>>>>
>>>>>>>> -kto
>>>>>>>>
>>>>>>>> On Nov 2, 2012, at 9:38 AM, Vincent Ryan wrote:
>>>>>>>>
>>>>>>>>>> From: Vincent Ryan <vincent.x.ryan at oracle.com>
>>>>>>>>>> Subject: Re: New builds from the build-infra team
>>>>>>>>>> Date: 2 November 2012 15:48:03 GMT
>>>>>>>>>> To: build-infra-dev at openjdk.java.net
>>>>>>>>>>
>>>>>>>>>> I tried this out on the latest Solaris 11 Update 1 (sparc) 
>>>>>>>>>> but the build encountered problems locating libc when
>>>>>>>>>> building jdk. (BTW the old build works correctly, just slower)
>>>>>>>>>>
>>>>>>>>>> :
>>>>>>>>>> :
>>>>>>>>>> strerror                            
>>>>>>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  
>>>>>>>>>> (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>>>>>> vfprintf                            
>>>>>>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_error.o  
>>>>>>>>>> (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>>>>>> fprintf                             
>>>>>>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_init.o  
>>>>>>>>>> (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>>>>>> gethrvtime                          
>>>>>>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  
>>>>>>>>>> (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>>>>>> ld: fatal: symbol referencing errors. No output written to 
>>>>>>>>>> /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so
>>>>>>>>>> gmake[3]: *** 
>>>>>>>>>> [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so] 
>>>>>>>>>> Error 1
>>>>>>>>>> gmake[3]: Leaving directory 
>>>>>>>>>> `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>>>>>>>> gmake[2]: *** [libs-only] Error 2
>>>>>>>>>> gmake[2]: Leaving directory 
>>>>>>>>>> `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>>>>>>>> make[1]: *** [jdk-only] Error 2
>>>>>>>>>> make[1]: Leaving directory 
>>>>>>>>>> `/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release'
>>>>>>>>>> make: *** [all] Error 2
>>>>>>>>>> t4%
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> FYI I've attached the config script that was generated by 
>>>>>>>>>> configure.sh.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 1 Nov 2012, at 18:38, Kelly O'Hair wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Pardon the wide email, but this impacts everyone building 
>>>>>>>>>>> the OpenJDK jdk8/jdk8 derived forests.
>>>>>>>>>>>
>>>>>>>>>>> Please only reply to the build-infra-dev mailing list, or 
>>>>>>>>>>> just me.
>>>>>>>>>>>
>>>>>>>>>>> With some recent integrations from the build-infra project 
>>>>>>>>>>> into jdk8/jdk8 repositories, the build-infra team
>>>>>>>>>>> would like to get more exposure of the new builds. These 
>>>>>>>>>>> jdk8/jdk8 changes will start showing up in various
>>>>>>>>>>> jdk8 and team forests over the next few weeks. The default 
>>>>>>>>>>> is still the old builds, but both builds work in most
>>>>>>>>>>> cases for OpenJDK as far as we know.
>>>>>>>>>>>
>>>>>>>>>>> At a very high level, the intent is that once you get a forest:
>>>>>>>>>>> hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>>>>>>>>>>> cd j8
>>>>>>>>>>> sh ./get_source.sh
>>>>>>>>>>>
>>>>>>>>>>> You should be able to simply configure&&make (the ultimate 
>>>>>>>>>>> goal is this simple anyway), e.g.
>>>>>>>>>>> sh ./configure
>>>>>>>>>>> make NEWBUILD=true     # The NEWBUILD=true will become the 
>>>>>>>>>>> default when we formally switch.
>>>>>>>>>>>
>>>>>>>>>>> Where "make" is GNU make 3.81, and your system has all the 
>>>>>>>>>>> requires packages and PATH contains the
>>>>>>>>>>> needed tools. Note that on Windows, MKS unix utilities 
>>>>>>>>>>> cannot be used with the new builds, just CYGWIN
>>>>>>>>>>> is recommended at this time.
>>>>>>>>>>>
>>>>>>>>>>> Of course, we know, it's never as easy as a simple 
>>>>>>>>>>> configure&&make, and often you will need to pass in
>>>>>>>>>>> configure options.
>>>>>>>>>>>
>>>>>>>>>>> What we would like to know is where a simple configure&&make 
>>>>>>>>>>> does not work, and anything people had
>>>>>>>>>>> to do to make it work.
>>>>>>>>>>>
>>>>>>>>>>> I know many of you are quite used to the old builds, so I 
>>>>>>>>>>> have a temporary  "bridgeBuild" target
>>>>>>>>>>> people can try that will attempt to map the ALT_* 
>>>>>>>>>>> environment variables to an appropriate configure command
>>>>>>>>>>> and then run that configure command and do the build, e.g.
>>>>>>>>>>>
>>>>>>>>>>> make NEWBUILD=true bridgeBuild
>>>>>>>>>>>
>>>>>>>>>>> People willing to do comparisons between the old and new 
>>>>>>>>>>> builds could:
>>>>>>>>>>> rm -f -r build
>>>>>>>>>>> time make NEWBUILD=true bridgeBuild
>>>>>>>>>>> rm -f -r build
>>>>>>>>>>> time make NO_DOCS=true     # Old builds do not generate 
>>>>>>>>>>> javadocs by default
>>>>>>>>>>>
>>>>>>>>>>> Any observations about speed of the builds would be 
>>>>>>>>>>> appreciated, as will any impressions on what you see.
>>>>>>>>>>>
>>>>>>>>>>> At this time, we think this is working pretty well with a 
>>>>>>>>>>> few caveats:
>>>>>>>>>>> * GNU make with the new builds is doing much more parallel 
>>>>>>>>>>> processing and this can stress out a system
>>>>>>>>>>> - Use "make JOBS=1" if you suspect a problem, then try 
>>>>>>>>>>> adjusting it up slowly.
>>>>>>>>>>> * Partial builds are limited, right now full builds of the 
>>>>>>>>>>> entire OpenJDK is the target
>>>>>>>>>>> - Hotspot can still be built on it's own, but everyone else 
>>>>>>>>>>> needs to build hotspot at least once
>>>>>>>>>>> * Paths with multiple names can cause problems, e.g. being 
>>>>>>>>>>> on system svc6, and access an exported share
>>>>>>>>>>> area as /net/svc6/export/foobar  instead of /export/foobar  
>>>>>>>>>>> will cause problems. Use local paths.
>>>>>>>>>>>
>>>>>>>>>>> We know there are still issues and we will be focusing 
>>>>>>>>>>> heavily on the critical ones in the next few weeks, but
>>>>>>>>>>> we do need the community to tell us what the critical issues 
>>>>>>>>>>> really are.
>>>>>>>>>>>
>>>>>>>>>>> Our number one priority at this time is that everyone that 
>>>>>>>>>>> was able to build the old way, should be able to build
>>>>>>>>>>> with the new build-infra makefiles. Please help us verify that.
>>>>>>>>>>>
>>>>>>>>>>> -kto
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


From oehrstroem at gmail.com  Wed Nov  7 01:01:23 2012
From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=)
Date: Wed, 7 Nov 2012 10:01:23 +0100
Subject: Cannot list safely more than 10000 paths
In-Reply-To: <A731A037-4BF2-4FBB-A73A-EDF752A61D36@oracle.com>
References: <A731A037-4BF2-4FBB-A73A-EDF752A61D36@oracle.com>
Message-ID: <CALZT+jCje4d3=R_aLnfC6XFw6YtCeDd2RD5sF-8X1USuod0h-A@mail.gmail.com>

Yes, there is a fix in build-infra that increases the limit.
http://hg.openjdk.java.net/build-infra/jdk8/rev/e20ffc02e437

//Fredrik

2012/11/7 Staffan Larsen <staffan.larsen at oracle.com>

> I'm trying out the latest in jdk8/jdk8 on OS X and get the error below.
>
> This is on OS X 10.8.2 with both closed and open repos.
>
> Any ideas?
>
> /Staffan
>
> Generating jobjc framework bridge
> Compiling 4 files for BUILD_BREAKITERATOR
> Generating HTML DTD file
> [Parsed DTD html32 in 294ms]
> CompileJavaClasses.gmk:402: warning: overriding commands for target
> `/Users/staffan/mercurial/jdk8/build/macosx-x86_64-normal-server-release/jdk/gensrc_headers/_the.headers'
> CompileJavaClasses.gmk:295: warning: ignoring old commands for target
> `/Users/staffan/mercurial/jdk8/build/macosx-x86_64-normal-server-release/jdk/gensrc_headers/_the.headers'
> CompileJavaClasses.gmk:295: *** Cannot list safely more than 10000 paths.
> BUILD_JDK_SRCS has 10070 paths!.  Stop.
> make[3]: *** Waiting for unfinished jobs....
> make[2]: *** [classes-only] Error 2
> make[1]: *** [jdk-only] Error 2
> make: *** [all] Error 2


From erik.joelsson at oracle.com  Wed Nov  7 01:03:32 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Wed, 07 Nov 2012 09:03:32 +0000
Subject: hg: build-infra/jdk8: 2 new changesets
Message-ID: <20121107090333.01658477EB@hg.openjdk.java.net>

Changeset: a60fbff8b782
Author:    erikj
Date:      2012-11-05 12:18 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/a60fbff8b782

Build deploy repo on windows.

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/autoconf/toolchain.m4
! common/bin/compare.sh

Changeset: 345dbc49f7d0
Author:    erikj
Date:      2012-11-06 09:27 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/345dbc49f7d0

Merge

! common/autoconf/spec.gmk.in



From staffan.larsen at oracle.com  Wed Nov  7 01:29:22 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 7 Nov 2012 10:29:22 +0100
Subject: Cannot list safely more than 10000 paths
In-Reply-To: <CALZT+jCje4d3=R_aLnfC6XFw6YtCeDd2RD5sF-8X1USuod0h-A@mail.gmail.com>
References: <A731A037-4BF2-4FBB-A73A-EDF752A61D36@oracle.com>
	<CALZT+jCje4d3=R_aLnfC6XFw6YtCeDd2RD5sF-8X1USuod0h-A@mail.gmail.com>
Message-ID: <2DBB7EE0-3128-48F9-89BA-B8E507D19A3B@oracle.com>

Thanks - it builds fine with that patch!

On 7 nov 2012, at 10:01, Fredrik ?hrstr?m <oehrstroem at gmail.com> wrote:

> Yes, there is a fix in build-infra that increases the limit.
> http://hg.openjdk.java.net/build-infra/jdk8/rev/e20ffc02e437
> 
> //Fredrik
> 
> 2012/11/7 Staffan Larsen <staffan.larsen at oracle.com>
> I'm trying out the latest in jdk8/jdk8 on OS X and get the error below.
> 
> This is on OS X 10.8.2 with both closed and open repos.
> 
> Any ideas?
> 
> /Staffan
> 
> Generating jobjc framework bridge
> Compiling 4 files for BUILD_BREAKITERATOR
> Generating HTML DTD file
> [Parsed DTD html32 in 294ms]
> CompileJavaClasses.gmk:402: warning: overriding commands for target `/Users/staffan/mercurial/jdk8/build/macosx-x86_64-normal-server-release/jdk/gensrc_headers/_the.headers'
> CompileJavaClasses.gmk:295: warning: ignoring old commands for target `/Users/staffan/mercurial/jdk8/build/macosx-x86_64-normal-server-release/jdk/gensrc_headers/_the.headers'
> CompileJavaClasses.gmk:295: *** Cannot list safely more than 10000 paths. BUILD_JDK_SRCS has 10070 paths!.  Stop.
> make[3]: *** Waiting for unfinished jobs....
> make[2]: *** [classes-only] Error 2
> make[1]: *** [jdk-only] Error 2
> make: *** [all] Error 2
> 



From erik.joelsson at oracle.com  Wed Nov  7 06:04:53 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Wed, 07 Nov 2012 14:04:53 +0000
Subject: hg: build-infra/jdk8/jdk: Adding -lc to native link lines for solaris
	to make build work on solaris 11.1
Message-ID: <20121107140528.8938B477F2@hg.openjdk.java.net>

Changeset: f55a9dd34bc9
Author:    erikj
Date:      2012-11-07 14:04 +0000
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/f55a9dd34bc9

Adding -lc to native link lines for solaris to make build work on solaris 11.1

! makefiles/CompileNativeLibraries.gmk



From erik.joelsson at oracle.com  Wed Nov  7 06:12:17 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Wed, 07 Nov 2012 14:12:17 +0000
Subject: hg: build-infra/jdk8: 2 new changesets
Message-ID: <20121107141217.9239F477F3@hg.openjdk.java.net>

Changeset: d8e55c9433a3
Author:    erikj
Date:      2012-11-07 12:55 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/d8e55c9433a3

Enable importing of hotspot binaries from a j2sdk image.

! common/autoconf/generated-configure.sh
! common/autoconf/source-dirs.m4
! common/autoconf/spec.gmk.in
! common/makefiles/Main.gmk

Changeset: 45f876facc58
Author:    erikj
Date:      2012-11-07 15:08 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/45f876facc58

Renaming parameter for supplying directory for hotspot import.

! common/autoconf/generated-configure.sh
! common/autoconf/source-dirs.m4



From erik.joelsson at oracle.com  Wed Nov  7 06:12:22 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Wed, 07 Nov 2012 14:12:22 +0000
Subject: hg: build-infra/jdk8/jdk: 3 new changesets
Message-ID: <20121107141256.06988477F4@hg.openjdk.java.net>

Changeset: 8d3b9f8f38bb
Author:    erikj
Date:      2012-11-07 12:42 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/8d3b9f8f38bb

Enable importing of hotspot binaries from a j2sdk image.

! makefiles/Import.gmk

Changeset: 0db961f4663c
Author:    erikj
Date:      2012-11-07 15:09 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/0db961f4663c

Enable --with-import-hotspot on windows.

! makefiles/Import.gmk

Changeset: 6a462f27bf4c
Author:    erikj
Date:      2012-11-07 15:11 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/6a462f27bf4c

Merge




From erik.joelsson at oracle.com  Wed Nov  7 07:05:58 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Wed, 07 Nov 2012 15:05:58 +0000
Subject: hg: build-infra/jdk8: Fixed mistake in param rename.
Message-ID: <20121107150558.C266A477F6@hg.openjdk.java.net>

Changeset: 9a4ed1903f39
Author:    erikj
Date:      2012-11-07 16:05 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/9a4ed1903f39

Fixed mistake in param rename.

! common/autoconf/generated-configure.sh
! common/autoconf/source-dirs.m4



From kelly.ohair at oracle.com  Wed Nov  7 09:58:38 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 7 Nov 2012 09:58:38 -0800
Subject: New builds from the build-infra team
In-Reply-To: <5099B850.1080305@oracle.com>
References: <70C78781-9057-4B6C-9F80-E39F637A9AD5@oracle.com>
	<4E118E25-D6AB-4C7E-9CF9-56495CBB5B92@oracle.com>
	<DBF14695-B54B-4092-A420-1B12D11D19A6@oracle.com>
	<A7D41D1F-A00C-4041-9609-AB987F0CEDB0@oracle.com>
	<28B38282-EFD5-46EF-B5BE-57A6110DFC51@oracle.com>
	<50942824.1000102@oracle.com>
	<7BDA9278-91CA-449D-98AD-D1520941A5E5@oracle.com>
	<7145E484-6D99-4D34-B47C-A09A9F2A5714@oracle.com>
	<FCA6CF40-49C2-4359-9ED8-E165AF47E887@oracle.com>
	<5099B850.1080305@oracle.com>
Message-ID: <88FB75C7-0DCD-4CD6-BC31-E0E927B38905@oracle.com>

Fantastic, I see Erik grabbed the patch, thank you!

Just for my own information, what kind of Solaris SPARC hardware is this, or is it a Zone?
I'm not sure I have see an OpenJDK build this fast on the SPARC Zones I have been given access to.

-kto

On Nov 6, 2012, at 5:24 PM, Vincent Ryan wrote:

> I finally have a clean build of http://hg.openjdk.java.net/build-infra/jdk8 on Solaris 11.1 Sparc and the times for a full build
> are not too shabby:
> 
> 00:00:34 corba
> 00:04:14 hotspot
> 00:00:29 jaxp
> 00:00:40 jaxws
> 00:03:19 jdk
> 00:00:38 langtools
> 00:09:54 TOTAL
> 
> The fix involves adding '-lc' to LDFLAGS for almost every native
> library in CompileNativeLibraries.gmk. There may be a more elegant fix
> but this one works for me...
> 
> 
> 
> 
> diff --git a/makefiles/CompileNativeLibraries.gmk b/makefiles/CompileNativeLibraries.gmk
> --- a/makefiles/CompileNativeLibraries.gmk
> +++ b/makefiles/CompileNativeLibraries.gmk
> @@ -300,6 +300,7 @@ endif
>                         $(call SET_SHARED_LIBRARY_ORIGIN),\
>                LDFLAGS_SUFFIX:=$(BUILD_LIBMLIB_LDLIBS) \
>                                $(LDFLAGS_JDKLIB_SUFFIX),\
> +               LDFLAGS_SUFFIX_solaris:=-lc, \
> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>                RC_FLAGS:=$(RC_FLAGS)\
>                          -D "JDK_FNAME=mlib_image.dll" \
> @@ -428,6 +429,7 @@ BUILD_LIBMLIB_V_CFLAGS := $(filter-out -
>                LDFLAGS:=$(LDFLAGS_JDKLIB) \
>                          $(BUILD_LIBMLIB_LDLIBS) -ljava -ljvm \
>                         $(call SET_SHARED_LIBRARY_ORIGIN),\
> +               LDFLAGS_SUFFIX_solaris:=-lc, \
>                OBJECT_DIR:=$(JDK_OUTPUTDIR)/objs/libmlib_image_v))
> 
> $(BUILD_LIBMLIB_IMAGE_V): $(BUILD_LIBJAVA)
> @@ -710,7 +712,7 @@ endif
>                LDFLAGS:=$(LDFLAGS_JDKLIB) $(call SET_SHARED_LIBRARY_ORIGIN),\
> LDFLAGS_solaris:=-R/usr/dt/lib$(OPENJDK_TARGET_CPU_ISADIR) -R$(OPENWIN_LIB)$(OPENJDK_TARGET_CPU_ISADIR),\
>                LDFLAGS_SUFFIX_linux:=-ljvm $(LIBM) $(LIBDL) -ljava,\
> -               LDFLAGS_SUFFIX_solaris:=-ljvm $(LIBM) $(LIBDL) -ljava,\
> +               LDFLAGS_SUFFIX_solaris:=-ljvm $(LIBM) $(LIBDL) -ljava -lc,\
>                LDFLAGS_SUFFIX_macosx:=-lmlib_image -ljvm $(LIBM) \
>                                       -framework Cocoa \
>                                       -framework OpenGL \
> @@ -966,7 +968,7 @@ endif
>                                 -export:ZIP_ReadEntry -export:ZIP_GetNextEntry jvm.lib \
>                                 $(WIN_JAVA_LIB),\
>                LDFLAGS_SUFFIX_linux:=-ljvm -ljava $(LIBZ),\
> -               LDFLAGS_SUFFIX_solaris:=-ljvm -ljava $(LIBZ),\
> +               LDFLAGS_SUFFIX_solaris:=-ljvm -ljava $(LIBZ) -lc,\
>                LDFLAGS_SUFFIX_macosx:=$(LIBZ) -ljava -ljvm,\
> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>                RC_FLAGS:=$(RC_FLAGS)\
> @@ -1144,7 +1146,7 @@ endif # OPENJDK_TARGET_OS
>                LDFLAGS:=$(LDFLAGS_JDKLIB) \
>                         $(call SET_SHARED_LIBRARY_ORIGIN),\
>                LDFLAGS_SUFFIX_linux:=$(LIBDL),\
> -               LDFLAGS_SUFFIX_solaris:=$(LIBDL),\
> +               LDFLAGS_SUFFIX_solaris:=$(LIBDL) -lc,\
>                LDFLAGS_SUFFIX_windows:=$(LDFLAGS_JDKLIB_SUFFIX),\
>                LDFLAGS_SUFFIX:=,\
> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
> @@ -1187,6 +1189,7 @@ endif
>                LDFLAGS_windows:=netapi32.lib user32.lib mpr.lib advapi32.lib,\
>                LDFLAGS_SUFFIX_windows:=$(LDFLAGS_JDKLIB_SUFFIX),\
>                LDFLAGS_SUFFIX:=,\
> +               LDFLAGS_SUFFIX_solaris:=-lc,\
>                EXCLUDE_FILES:=$(LIBJAAS_EXCLUDE_FILES),\
> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>                RC_FLAGS:=$(RC_FLAGS) \
> @@ -1217,6 +1220,7 @@ BUILD_LIBRARIES += $(BUILD_LIBJAAS)
>                LDFLAGS_SUFFIX_linux:=$(LIBDL),\
>                LDFLAGS_SUFFIX_windows:=$(LDFLAGS_JDKLIB_SUFFIX) $(LIBDL),\
>                LDFLAGS_SUFFIX_macosx:=                         $(LIBDL),\
> +               LDFLAGS_SUFFIX_solaris:=-lc,\
>                LDFLAGS_SUFFIX:=,\
> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>                RC_FLAGS:=$(RC_FLAGS)\
> @@ -1259,7 +1263,7 @@ ifdef OPENJDK
>                          $(call SET_SHARED_LIBRARY_ORIGIN), \
> LDFLAGS_solaris:=/usr/lib$(OPENJDK_TARGET_CPU_ISADIR)/libm.so.2,\
>                LDFLAGS_windows:=$(WIN_AWT_LIB) $(WIN_JAVA_LIB),\
> -               LDFLAGS_SUFFIX_solaris:=-lawt -ljava -ljvm,\
> +               LDFLAGS_SUFFIX_solaris:=-lawt -ljava -ljvm -lc,\
>                LDFLAGS_SUFFIX_macosx:=$(LIBM) -lawt -ljava -ljvm,\
>                LDFLAGS_SUFFIX_linux:=-lm -lawt -ljava -ljvm,\
> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
> @@ -1716,7 +1720,7 @@ endif
>                                -framework Cocoa -framework Security -framework ApplicationServices,\
>                LDFLAGS_SUFFIX:=$(LIBINSTRUMENT_LDFLAGS_SUFFIX),\
>                LDFLAGS_SUFFIX_macosx:=-liconv $(LIBZ),\
> -               LDFLAGS_SUFFIX_solaris:=$(LIBZ) -L $(INSTALL_LIBRARIES_HERE)/jli -ljli $(LIBDL),\
> +               LDFLAGS_SUFFIX_solaris:=$(LIBZ) -L $(INSTALL_LIBRARIES_HERE)/jli -ljli $(LIBDL) -lc,\
>                LDFLAGS_SUFFIX_linux:=$(LIBZ) -L $(INSTALL_LIBRARIES_HERE)/jli -ljli $(LIBDL),\
> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>                RC_FLAGS:=$(RC_FLAGS)\
> @@ -1858,6 +1862,7 @@ BUILD_LIBRARIES += $(BUILD_LIBHPROF)
> MAPFILE:=$(JDK_TOPDIR)/makefiles/mapfiles/libjava_crw_demo/mapfile-vers, \
>                LDFLAGS:=$(LDFLAGS_JDKLIB) \
>                         $(call SET_SHARED_LIBRARY_ORIGIN),\
> +               LDFLAGS_SUFFIX_solaris:=-lc, \
> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>                RC_FLAGS:=$(RC_FLAGS)\
>                          -D "JDK_FNAME=java_crw_demo.dll" \
> @@ -2488,7 +2493,7 @@ endif
>                LDFLAGS_linux:=$(call SET_SHARED_LIBRARY_ORIGIN,/..),\
>                LDFLAGS_solaris:=$(call SET_SHARED_LIBRARY_ORIGIN,/..) \
> -R/usr/dt/lib$(OPENJDK_TARGET_CPU_ISADIR) \
> - -R$(OPENWIN_LIB)$(OPENJDK_TARGET_CPU_ISADIR),\
> + -R$(OPENWIN_LIB)$(OPENJDK_TARGET_CPU_ISADIR) -lc,\
>                LDFLAGS_macosx:=$(call SET_SHARED_LIBRARY_ORIGIN).,\
>                REORDER:=$(LIBAWT_HEADLESS_REORDER), \
>                LDFLAGS_SUFFIX_linux:=-ljvm -lawt -lm $(LIBDL) -ljava,\
> @@ -2662,6 +2667,7 @@ endif # OPENJDK_TARGET_OS
>                LDFLAGS:=$(LDFLAGS_JDKLIB) \
>                         $(call SET_SHARED_LIBRARY_ORIGIN),\
>                LDFLAGS_SUFFIX:=$(LIBSPLASHSCREEN_LDFLAGS_SUFFIX) $(LIBZ),\
> +               LDFLAGS_SUFFIX_solaris:=-lc,\
> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>                RC_FLAGS:=$(RC_FLAGS)\
>                          -D "JDK_FNAME=splashscreen.dll" \
> @@ -2737,6 +2743,7 @@ endif
>                         $(call SET_SHARED_LIBRARY_ORIGIN),\
>                LDFLAGS_SUFFIX_posix:=$(LIBDL), \
>                LDFLAGS_SUFFIX_windows:=winscard.lib,\
> +               LDFLAGS_SUFFIX_solaris:=-lc,\
> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>                RC_FLAGS:=$(RC_FLAGS)\
>                          -D "JDK_FNAME=j2pcsc.dll" \
> @@ -2764,6 +2771,7 @@ ifneq ($(OPENJDK_TARGET_OS), windows)
>                LDFLAGS:=$(LDFLAGS_JDKLIB) \
>                         $(call SET_SHARED_LIBRARY_ORIGIN),\
>                LDFLAGS_SUFFIX:=$(LIBDL), \
> +               LDFLAGS_SUFFIX_solaris:=-lc,\
>                OBJECT_DIR:=$(JDK_OUTPUTDIR)/objs/libj2gss))
> 
> BUILD_LIBRARIES += $(BUILD_LIBJ2GSS)
> @@ -2858,6 +2866,7 @@ endif
>                LDFLAGS:=$(LDFLAGS_JDKLIB) \
>                         $(call SET_SHARED_LIBRARY_ORIGIN),\
>                LDFLAGS_SUFFIX_posix:=$(LIBDL), \
> +               LDFLAGS_SUFFIX_solaris:=-lc, \
> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>                RC_FLAGS:=$(RC_FLAGS)\
>                          -D "JDK_FNAME=j2pkcs11.dll" \
> 
> 
> 
> 
> 
> On 06/11/2012 18:10, Kelly O'Hair wrote:
>> 
>> On Nov 6, 2012, at 9:34 AM, Vincent Ryan wrote:
>> 
>>> I picked up the 2 changesets that were pushed over the weekend. The build makes more
>>> progress but it still fails due to missing C lib. I guess there are a few more corner cases.
>>> 
>>> Is there a way to activate more debugging during the build? I'd like to examine the exact
>>> compiler flags that are in use when the failure occurs.
>> 
>> Use
>> 
>>    gmake LOG=debug
>> 
>> -kto
>> 
>>> 
>>> 
>>> 
>>> On 6 Nov 2012, at 16:33, Kelly O'Hair wrote:
>>> 
>>>> If you get a chance, could you try this experiment again with the latest in jdk8/build forest?
>>>> I fixed a few more libraries that I think had a missing -lc.
>>>> 
>>>> I don't have access to a Solaris SPARC 11.1 system, and so far the issues you have run into seem to
>>>> be unique to SPARCV9 builds on 11.1, the Solaris X64 11.1 systems I have access to don't seem to reproduce this issue.
>>>> I can only assume that the compiler or the system behaves differently between SPARCV9 and X64 on 11.1. :^(
>>>> 
>>>> -kto
>>>> 
>>>> On Nov 2, 2012, at 1:08 PM, Vincent Ryan wrote:
>>>> 
>>>>> Thanks Kelly.
>>>>> 
>>>>> I re-ran the build with your patch and got better results but there
>>>>> seems to be another linker problem later in the jdk build.
>>>>> 
>>>>> Here's the tail of the build output:
>>>>> 
>>>>> :
>>>>> :
>>>>> Undefined                       first referenced
>>>>> symbol                             in file
>>>>> free /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> __iob /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> abort /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> snprintf /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> calloc /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> malloc /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> memcpy /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> memset /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> strcmp /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> strlen /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> realloc /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> strncmp /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> fprintf /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>> ld: fatal: symbol referencing errors. No output written to /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libjava_crw_demo.so
>>>>> gmake[3]: *** [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libjava_crw_demo.so] Error 1
>>>>> gmake[3]: *** Waiting for unfinished jobs....
>>>>> Undefined                       first referenced
>>>>> symbol                             in file
>>>>> exit /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>>> free /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>>> __iob /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>>> abort /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
>>>>> iconv /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>>>> __ctype /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
>>>>> iconv_open /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>>>> calloc /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>>> memcpy /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>>>> strcmp /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>>> strdup /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>>> strlen /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
>>>>> nl_langinfo /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>>>> sprintf /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
>>>>> setlocale /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>>>> iconv_close /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>>>> fprintf /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>>> ld: fatal: symbol referencing errors. No output written to /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libnpt.so
>>>>> gmake[3]: *** [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libnpt.so] Error 1
>>>>> gmake[3]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>>> gmake[2]: *** [libs-only] Error 2
>>>>> gmake[2]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>>> make[1]: *** [jdk-only] Error 2
>>>>> make[1]: Leaving directory `/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release'
>>>>> make: *** [all] Error 2
>>>>> t4%
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 02/11/2012 18:38, Kelly O'Hair wrote:
>>>>>> 
>>>>>> On Nov 2, 2012, at 11:17 AM, Vincent Ryan wrote:
>>>>>> 
>>>>>>> That attachment got dropped when I re-sent my message (previously I wasn't a member of the build-infra-dev email alias). I've attached it again in case it proves useful.
>>>>>>> 
>>>>>>> <config.status>
>>>>>>> 
>>>>>>> 
>>>>>>> I realize Solaris 11 is not an official build platform for JDK8 but I thought I'd give it a spin on a reasonably
>>>>>>> beefy server.
>>>>>> 
>>>>>> It's great that you tried this, thanks.
>>>>>> 
>>>>>> As far as I can tell, this seems to be a sparcv9 Solaris 11.1 issue, because I tried Solaris 11.1 X64 and it worked fine.
>>>>>> However, the link of libhprof.so IS missing the -lc option.
>>>>>> So why sparcv9 would complain and amd64 would not is a bit puzzling.
>>>>>> 
>>>>>> The change I think needs to be made is:
>>>>>> 
>>>>>> diff --git a/makefiles/CompileNativeLibraries.gmk b/makefiles/CompileNativeLibraries.gmk
>>>>>> --- a/makefiles/CompileNativeLibraries.gmk
>>>>>> +++ b/makefiles/CompileNativeLibraries.gmk
>>>>>> @@ -1807,7 +1807,7 @@
>>>>>> BUILD_LIBHPROF_LDFLAGS:=
>>>>>> 
>>>>>> ifeq ($(OPENJDK_TARGET_OS),solaris)
>>>>>> -     BUILD_LIBHPROF_LDFLAGS += -lsocket -lnsl
>>>>>> +     BUILD_LIBHPROF_LDFLAGS += -lsocket -lnsl -lc
>>>>>> endif
>>>>>> 
>>>>>> LIBHPROF_OPTIMIZATION:=HIGHEST
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> But I have not tested it yet.
>>>>>> Did you want to give this patch a spin?
>>>>>> 
>>>>>> -kto
>>>>>> 
>>>>>>> Thanks.
>>>>>>> 
>>>>>>> 
>>>>>>> On 2 Nov 2012, at 17:45, Kelly O'Hair wrote:
>>>>>>> 
>>>>>>>> The attachment is missing.
>>>>>>>> 
>>>>>>>> This looks like the  -lc   is missing from the creation of hprof, we should never let libc be an implicit dependency.
>>>>>>>> 
>>>>>>>> I wonder if Solaris 11.1 has tightened up the rules on implicit dependencies. We have not seen this on Solaris 10.
>>>>>>>> We just got svc6 setup as a 11.1 system, I'll see if it reproduces there.
>>>>>>>> 
>>>>>>>> And thank you for reporting this. Although Solaris 11.1 is not one of our critical systems, it's very important that this works.
>>>>>>>> 
>>>>>>>> -kto
>>>>>>>> 
>>>>>>>> On Nov 2, 2012, at 9:38 AM, Vincent Ryan wrote:
>>>>>>>> 
>>>>>>>>>> From: Vincent Ryan <vincent.x.ryan at oracle.com>
>>>>>>>>>> Subject: Re: New builds from the build-infra team
>>>>>>>>>> Date: 2 November 2012 15:48:03 GMT
>>>>>>>>>> To: build-infra-dev at openjdk.java.net
>>>>>>>>>> 
>>>>>>>>>> I tried this out on the latest Solaris 11 Update 1 (sparc) but the build encountered problems locating libc when
>>>>>>>>>> building jdk. (BTW the old build works correctly, just slower)
>>>>>>>>>> 
>>>>>>>>>> :
>>>>>>>>>> :
>>>>>>>>>> strerror                            /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>>>>>> vfprintf                            /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_error.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>>>>>> fprintf                             /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_init.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>>>>>> gethrvtime                          /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>>>>>> ld: fatal: symbol referencing errors. No output written to /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so
>>>>>>>>>> gmake[3]: *** [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so] Error 1
>>>>>>>>>> gmake[3]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>>>>>>>> gmake[2]: *** [libs-only] Error 2
>>>>>>>>>> gmake[2]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>>>>>>>> make[1]: *** [jdk-only] Error 2
>>>>>>>>>> make[1]: Leaving directory `/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release'
>>>>>>>>>> make: *** [all] Error 2
>>>>>>>>>> t4%
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> FYI I've attached the config script that was generated by configure.sh.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On 1 Nov 2012, at 18:38, Kelly O'Hair wrote:
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Pardon the wide email, but this impacts everyone building the OpenJDK jdk8/jdk8 derived forests.
>>>>>>>>>>> 
>>>>>>>>>>> Please only reply to the build-infra-dev mailing list, or just me.
>>>>>>>>>>> 
>>>>>>>>>>> With some recent integrations from the build-infra project into jdk8/jdk8 repositories, the build-infra team
>>>>>>>>>>> would like to get more exposure of the new builds. These jdk8/jdk8 changes will start showing up in various
>>>>>>>>>>> jdk8 and team forests over the next few weeks. The default is still the old builds, but both builds work in most
>>>>>>>>>>> cases for OpenJDK as far as we know.
>>>>>>>>>>> 
>>>>>>>>>>> At a very high level, the intent is that once you get a forest:
>>>>>>>>>>> hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>>>>>>>>>>> cd j8
>>>>>>>>>>> sh ./get_source.sh
>>>>>>>>>>> 
>>>>>>>>>>> You should be able to simply configure&&make (the ultimate goal is this simple anyway), e.g.
>>>>>>>>>>> sh ./configure
>>>>>>>>>>> make NEWBUILD=true     # The NEWBUILD=true will become the default when we formally switch.
>>>>>>>>>>> 
>>>>>>>>>>> Where "make" is GNU make 3.81, and your system has all the requires packages and PATH contains the
>>>>>>>>>>> needed tools. Note that on Windows, MKS unix utilities cannot be used with the new builds, just CYGWIN
>>>>>>>>>>> is recommended at this time.
>>>>>>>>>>> 
>>>>>>>>>>> Of course, we know, it's never as easy as a simple configure&&make, and often you will need to pass in
>>>>>>>>>>> configure options.
>>>>>>>>>>> 
>>>>>>>>>>> What we would like to know is where a simple configure&&make does not work, and anything people had
>>>>>>>>>>> to do to make it work.
>>>>>>>>>>> 
>>>>>>>>>>> I know many of you are quite used to the old builds, so I have a temporary  "bridgeBuild" target
>>>>>>>>>>> people can try that will attempt to map the ALT_* environment variables to an appropriate configure command
>>>>>>>>>>> and then run that configure command and do the build, e.g.
>>>>>>>>>>> 
>>>>>>>>>>> make NEWBUILD=true bridgeBuild
>>>>>>>>>>> 
>>>>>>>>>>> People willing to do comparisons between the old and new builds could:
>>>>>>>>>>> rm -f -r build
>>>>>>>>>>> time make NEWBUILD=true bridgeBuild
>>>>>>>>>>> rm -f -r build
>>>>>>>>>>> time make NO_DOCS=true     # Old builds do not generate javadocs by default
>>>>>>>>>>> 
>>>>>>>>>>> Any observations about speed of the builds would be appreciated, as will any impressions on what you see.
>>>>>>>>>>> 
>>>>>>>>>>> At this time, we think this is working pretty well with a few caveats:
>>>>>>>>>>> * GNU make with the new builds is doing much more parallel processing and this can stress out a system
>>>>>>>>>>> - Use "make JOBS=1" if you suspect a problem, then try adjusting it up slowly.
>>>>>>>>>>> * Partial builds are limited, right now full builds of the entire OpenJDK is the target
>>>>>>>>>>> - Hotspot can still be built on it's own, but everyone else needs to build hotspot at least once
>>>>>>>>>>> * Paths with multiple names can cause problems, e.g. being on system svc6, and access an exported share
>>>>>>>>>>> area as /net/svc6/export/foobar  instead of /export/foobar  will cause problems. Use local paths.
>>>>>>>>>>> 
>>>>>>>>>>> We know there are still issues and we will be focusing heavily on the critical ones in the next few weeks, but
>>>>>>>>>>> we do need the community to tell us what the critical issues really are.
>>>>>>>>>>> 
>>>>>>>>>>> Our number one priority at this time is that everyone that was able to build the old way, should be able to build
>>>>>>>>>>> with the new build-infra makefiles. Please help us verify that.
>>>>>>>>>>> 
>>>>>>>>>>> -kto
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 



From vincent.x.ryan at oracle.com  Wed Nov  7 11:13:45 2012
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Wed, 7 Nov 2012 19:13:45 +0000
Subject: New builds from the build-infra team
In-Reply-To: <88FB75C7-0DCD-4CD6-BC31-E0E927B38905@oracle.com>
References: <70C78781-9057-4B6C-9F80-E39F637A9AD5@oracle.com>
	<4E118E25-D6AB-4C7E-9CF9-56495CBB5B92@oracle.com>
	<DBF14695-B54B-4092-A420-1B12D11D19A6@oracle.com>
	<A7D41D1F-A00C-4041-9609-AB987F0CEDB0@oracle.com>
	<28B38282-EFD5-46EF-B5BE-57A6110DFC51@oracle.com>
	<50942824.1000102@oracle.com>
	<7BDA9278-91CA-449D-98AD-D1520941A5E5@oracle.com>
	<7145E484-6D99-4D34-B47C-A09A9F2A5714@oracle.com>
	<FCA6CF40-49C2-4359-9ED8-E165AF47E887@oracle.com>
	<5099B850.1080305@oracle.com>
	<88FB75C7-0DCD-4CD6-BC31-E0E927B38905@oracle.com>
Message-ID: <E73FB262-622A-46F9-8DA3-B0C66C0D597A@oracle.com>

It's a SPARC T4-1.

On 7 Nov 2012, at 17:58, Kelly O'Hair wrote:

> Fantastic, I see Erik grabbed the patch, thank you!
> 
> Just for my own information, what kind of Solaris SPARC hardware is this, or is it a Zone?
> I'm not sure I have see an OpenJDK build this fast on the SPARC Zones I have been given access to.
> 
> -kto
> 
> On Nov 6, 2012, at 5:24 PM, Vincent Ryan wrote:
> 
>> I finally have a clean build of http://hg.openjdk.java.net/build-infra/jdk8 on Solaris 11.1 Sparc and the times for a full build
>> are not too shabby:
>> 
>> 00:00:34 corba
>> 00:04:14 hotspot
>> 00:00:29 jaxp
>> 00:00:40 jaxws
>> 00:03:19 jdk
>> 00:00:38 langtools
>> 00:09:54 TOTAL
>> 
>> The fix involves adding '-lc' to LDFLAGS for almost every native
>> library in CompileNativeLibraries.gmk. There may be a more elegant fix
>> but this one works for me...
>> 
>> 
>> 
>> 
>> diff --git a/makefiles/CompileNativeLibraries.gmk b/makefiles/CompileNativeLibraries.gmk
>> --- a/makefiles/CompileNativeLibraries.gmk
>> +++ b/makefiles/CompileNativeLibraries.gmk
>> @@ -300,6 +300,7 @@ endif
>>                        $(call SET_SHARED_LIBRARY_ORIGIN),\
>>               LDFLAGS_SUFFIX:=$(BUILD_LIBMLIB_LDLIBS) \
>>                               $(LDFLAGS_JDKLIB_SUFFIX),\
>> +               LDFLAGS_SUFFIX_solaris:=-lc, \
>> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>>               RC_FLAGS:=$(RC_FLAGS)\
>>                         -D "JDK_FNAME=mlib_image.dll" \
>> @@ -428,6 +429,7 @@ BUILD_LIBMLIB_V_CFLAGS := $(filter-out -
>>               LDFLAGS:=$(LDFLAGS_JDKLIB) \
>>                         $(BUILD_LIBMLIB_LDLIBS) -ljava -ljvm \
>>                        $(call SET_SHARED_LIBRARY_ORIGIN),\
>> +               LDFLAGS_SUFFIX_solaris:=-lc, \
>>               OBJECT_DIR:=$(JDK_OUTPUTDIR)/objs/libmlib_image_v))
>> 
>> $(BUILD_LIBMLIB_IMAGE_V): $(BUILD_LIBJAVA)
>> @@ -710,7 +712,7 @@ endif
>>               LDFLAGS:=$(LDFLAGS_JDKLIB) $(call SET_SHARED_LIBRARY_ORIGIN),\
>> LDFLAGS_solaris:=-R/usr/dt/lib$(OPENJDK_TARGET_CPU_ISADIR) -R$(OPENWIN_LIB)$(OPENJDK_TARGET_CPU_ISADIR),\
>>               LDFLAGS_SUFFIX_linux:=-ljvm $(LIBM) $(LIBDL) -ljava,\
>> -               LDFLAGS_SUFFIX_solaris:=-ljvm $(LIBM) $(LIBDL) -ljava,\
>> +               LDFLAGS_SUFFIX_solaris:=-ljvm $(LIBM) $(LIBDL) -ljava -lc,\
>>               LDFLAGS_SUFFIX_macosx:=-lmlib_image -ljvm $(LIBM) \
>>                                      -framework Cocoa \
>>                                      -framework OpenGL \
>> @@ -966,7 +968,7 @@ endif
>>                                -export:ZIP_ReadEntry -export:ZIP_GetNextEntry jvm.lib \
>>                                $(WIN_JAVA_LIB),\
>>               LDFLAGS_SUFFIX_linux:=-ljvm -ljava $(LIBZ),\
>> -               LDFLAGS_SUFFIX_solaris:=-ljvm -ljava $(LIBZ),\
>> +               LDFLAGS_SUFFIX_solaris:=-ljvm -ljava $(LIBZ) -lc,\
>>               LDFLAGS_SUFFIX_macosx:=$(LIBZ) -ljava -ljvm,\
>> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>>               RC_FLAGS:=$(RC_FLAGS)\
>> @@ -1144,7 +1146,7 @@ endif # OPENJDK_TARGET_OS
>>               LDFLAGS:=$(LDFLAGS_JDKLIB) \
>>                        $(call SET_SHARED_LIBRARY_ORIGIN),\
>>               LDFLAGS_SUFFIX_linux:=$(LIBDL),\
>> -               LDFLAGS_SUFFIX_solaris:=$(LIBDL),\
>> +               LDFLAGS_SUFFIX_solaris:=$(LIBDL) -lc,\
>>               LDFLAGS_SUFFIX_windows:=$(LDFLAGS_JDKLIB_SUFFIX),\
>>               LDFLAGS_SUFFIX:=,\
>> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>> @@ -1187,6 +1189,7 @@ endif
>>               LDFLAGS_windows:=netapi32.lib user32.lib mpr.lib advapi32.lib,\
>>               LDFLAGS_SUFFIX_windows:=$(LDFLAGS_JDKLIB_SUFFIX),\
>>               LDFLAGS_SUFFIX:=,\
>> +               LDFLAGS_SUFFIX_solaris:=-lc,\
>>               EXCLUDE_FILES:=$(LIBJAAS_EXCLUDE_FILES),\
>> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>>               RC_FLAGS:=$(RC_FLAGS) \
>> @@ -1217,6 +1220,7 @@ BUILD_LIBRARIES += $(BUILD_LIBJAAS)
>>               LDFLAGS_SUFFIX_linux:=$(LIBDL),\
>>               LDFLAGS_SUFFIX_windows:=$(LDFLAGS_JDKLIB_SUFFIX) $(LIBDL),\
>>               LDFLAGS_SUFFIX_macosx:=                         $(LIBDL),\
>> +               LDFLAGS_SUFFIX_solaris:=-lc,\
>>               LDFLAGS_SUFFIX:=,\
>> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>>               RC_FLAGS:=$(RC_FLAGS)\
>> @@ -1259,7 +1263,7 @@ ifdef OPENJDK
>>                         $(call SET_SHARED_LIBRARY_ORIGIN), \
>> LDFLAGS_solaris:=/usr/lib$(OPENJDK_TARGET_CPU_ISADIR)/libm.so.2,\
>>               LDFLAGS_windows:=$(WIN_AWT_LIB) $(WIN_JAVA_LIB),\
>> -               LDFLAGS_SUFFIX_solaris:=-lawt -ljava -ljvm,\
>> +               LDFLAGS_SUFFIX_solaris:=-lawt -ljava -ljvm -lc,\
>>               LDFLAGS_SUFFIX_macosx:=$(LIBM) -lawt -ljava -ljvm,\
>>               LDFLAGS_SUFFIX_linux:=-lm -lawt -ljava -ljvm,\
>> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>> @@ -1716,7 +1720,7 @@ endif
>>                               -framework Cocoa -framework Security -framework ApplicationServices,\
>>               LDFLAGS_SUFFIX:=$(LIBINSTRUMENT_LDFLAGS_SUFFIX),\
>>               LDFLAGS_SUFFIX_macosx:=-liconv $(LIBZ),\
>> -               LDFLAGS_SUFFIX_solaris:=$(LIBZ) -L $(INSTALL_LIBRARIES_HERE)/jli -ljli $(LIBDL),\
>> +               LDFLAGS_SUFFIX_solaris:=$(LIBZ) -L $(INSTALL_LIBRARIES_HERE)/jli -ljli $(LIBDL) -lc,\
>>               LDFLAGS_SUFFIX_linux:=$(LIBZ) -L $(INSTALL_LIBRARIES_HERE)/jli -ljli $(LIBDL),\
>> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>>               RC_FLAGS:=$(RC_FLAGS)\
>> @@ -1858,6 +1862,7 @@ BUILD_LIBRARIES += $(BUILD_LIBHPROF)
>> MAPFILE:=$(JDK_TOPDIR)/makefiles/mapfiles/libjava_crw_demo/mapfile-vers, \
>>               LDFLAGS:=$(LDFLAGS_JDKLIB) \
>>                        $(call SET_SHARED_LIBRARY_ORIGIN),\
>> +               LDFLAGS_SUFFIX_solaris:=-lc, \
>> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>>               RC_FLAGS:=$(RC_FLAGS)\
>>                         -D "JDK_FNAME=java_crw_demo.dll" \
>> @@ -2488,7 +2493,7 @@ endif
>>               LDFLAGS_linux:=$(call SET_SHARED_LIBRARY_ORIGIN,/..),\
>>               LDFLAGS_solaris:=$(call SET_SHARED_LIBRARY_ORIGIN,/..) \
>> -R/usr/dt/lib$(OPENJDK_TARGET_CPU_ISADIR) \
>> - -R$(OPENWIN_LIB)$(OPENJDK_TARGET_CPU_ISADIR),\
>> + -R$(OPENWIN_LIB)$(OPENJDK_TARGET_CPU_ISADIR) -lc,\
>>               LDFLAGS_macosx:=$(call SET_SHARED_LIBRARY_ORIGIN).,\
>>               REORDER:=$(LIBAWT_HEADLESS_REORDER), \
>>               LDFLAGS_SUFFIX_linux:=-ljvm -lawt -lm $(LIBDL) -ljava,\
>> @@ -2662,6 +2667,7 @@ endif # OPENJDK_TARGET_OS
>>               LDFLAGS:=$(LDFLAGS_JDKLIB) \
>>                        $(call SET_SHARED_LIBRARY_ORIGIN),\
>>               LDFLAGS_SUFFIX:=$(LIBSPLASHSCREEN_LDFLAGS_SUFFIX) $(LIBZ),\
>> +               LDFLAGS_SUFFIX_solaris:=-lc,\
>> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>>               RC_FLAGS:=$(RC_FLAGS)\
>>                         -D "JDK_FNAME=splashscreen.dll" \
>> @@ -2737,6 +2743,7 @@ endif
>>                        $(call SET_SHARED_LIBRARY_ORIGIN),\
>>               LDFLAGS_SUFFIX_posix:=$(LIBDL), \
>>               LDFLAGS_SUFFIX_windows:=winscard.lib,\
>> +               LDFLAGS_SUFFIX_solaris:=-lc,\
>> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>>               RC_FLAGS:=$(RC_FLAGS)\
>>                         -D "JDK_FNAME=j2pcsc.dll" \
>> @@ -2764,6 +2771,7 @@ ifneq ($(OPENJDK_TARGET_OS), windows)
>>               LDFLAGS:=$(LDFLAGS_JDKLIB) \
>>                        $(call SET_SHARED_LIBRARY_ORIGIN),\
>>               LDFLAGS_SUFFIX:=$(LIBDL), \
>> +               LDFLAGS_SUFFIX_solaris:=-lc,\
>>               OBJECT_DIR:=$(JDK_OUTPUTDIR)/objs/libj2gss))
>> 
>> BUILD_LIBRARIES += $(BUILD_LIBJ2GSS)
>> @@ -2858,6 +2866,7 @@ endif
>>               LDFLAGS:=$(LDFLAGS_JDKLIB) \
>>                        $(call SET_SHARED_LIBRARY_ORIGIN),\
>>               LDFLAGS_SUFFIX_posix:=$(LIBDL), \
>> +               LDFLAGS_SUFFIX_solaris:=-lc, \
>> VERSIONINFO_RESOURCE:=$(JDK_TOPDIR)/src/windows/resource/version.rc,\
>>               RC_FLAGS:=$(RC_FLAGS)\
>>                         -D "JDK_FNAME=j2pkcs11.dll" \
>> 
>> 
>> 
>> 
>> 
>> On 06/11/2012 18:10, Kelly O'Hair wrote:
>>> 
>>> On Nov 6, 2012, at 9:34 AM, Vincent Ryan wrote:
>>> 
>>>> I picked up the 2 changesets that were pushed over the weekend. The build makes more
>>>> progress but it still fails due to missing C lib. I guess there are a few more corner cases.
>>>> 
>>>> Is there a way to activate more debugging during the build? I'd like to examine the exact
>>>> compiler flags that are in use when the failure occurs.
>>> 
>>> Use
>>> 
>>>   gmake LOG=debug
>>> 
>>> -kto
>>> 
>>>> 
>>>> 
>>>> 
>>>> On 6 Nov 2012, at 16:33, Kelly O'Hair wrote:
>>>> 
>>>>> If you get a chance, could you try this experiment again with the latest in jdk8/build forest?
>>>>> I fixed a few more libraries that I think had a missing -lc.
>>>>> 
>>>>> I don't have access to a Solaris SPARC 11.1 system, and so far the issues you have run into seem to
>>>>> be unique to SPARCV9 builds on 11.1, the Solaris X64 11.1 systems I have access to don't seem to reproduce this issue.
>>>>> I can only assume that the compiler or the system behaves differently between SPARCV9 and X64 on 11.1. :^(
>>>>> 
>>>>> -kto
>>>>> 
>>>>> On Nov 2, 2012, at 1:08 PM, Vincent Ryan wrote:
>>>>> 
>>>>>> Thanks Kelly.
>>>>>> 
>>>>>> I re-ran the build with your patch and got better results but there
>>>>>> seems to be another linker problem later in the jdk build.
>>>>>> 
>>>>>> Here's the tail of the build output:
>>>>>> 
>>>>>> :
>>>>>> :
>>>>>> Undefined                       first referenced
>>>>>> symbol                             in file
>>>>>> free /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>>> __iob /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>>> abort /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>>> snprintf /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>>> calloc /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>>> malloc /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>>> memcpy /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>>> memset /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>>> strcmp /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>>> strlen /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>>> realloc /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>>> strncmp /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>>> fprintf /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libjava_crw_demo/java_crw_demo.o
>>>>>> ld: fatal: symbol referencing errors. No output written to /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libjava_crw_demo.so
>>>>>> gmake[3]: *** [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libjava_crw_demo.so] Error 1
>>>>>> gmake[3]: *** Waiting for unfinished jobs....
>>>>>> Undefined                       first referenced
>>>>>> symbol                             in file
>>>>>> exit /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>>>> free /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>>>> __iob /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>>>> abort /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
>>>>>> iconv /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>>>>> __ctype /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
>>>>>> iconv_open /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>>>>> calloc /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>>>> memcpy /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>>>>> strcmp /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>>>> strdup /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>>>> strlen /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
>>>>>> nl_langinfo /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>>>>> sprintf /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf.o
>>>>>> setlocale /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>>>>> iconv_close /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/utf_md.o
>>>>>> fprintf /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libnpt/npt.o
>>>>>> ld: fatal: symbol referencing errors. No output written to /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libnpt.so
>>>>>> gmake[3]: *** [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libnpt.so] Error 1
>>>>>> gmake[3]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>>>> gmake[2]: *** [libs-only] Error 2
>>>>>> gmake[2]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>>>> make[1]: *** [jdk-only] Error 2
>>>>>> make[1]: Leaving directory `/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release'
>>>>>> make: *** [all] Error 2
>>>>>> t4%
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 02/11/2012 18:38, Kelly O'Hair wrote:
>>>>>>> 
>>>>>>> On Nov 2, 2012, at 11:17 AM, Vincent Ryan wrote:
>>>>>>> 
>>>>>>>> That attachment got dropped when I re-sent my message (previously I wasn't a member of the build-infra-dev email alias). I've attached it again in case it proves useful.
>>>>>>>> 
>>>>>>>> <config.status>
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I realize Solaris 11 is not an official build platform for JDK8 but I thought I'd give it a spin on a reasonably
>>>>>>>> beefy server.
>>>>>>> 
>>>>>>> It's great that you tried this, thanks.
>>>>>>> 
>>>>>>> As far as I can tell, this seems to be a sparcv9 Solaris 11.1 issue, because I tried Solaris 11.1 X64 and it worked fine.
>>>>>>> However, the link of libhprof.so IS missing the -lc option.
>>>>>>> So why sparcv9 would complain and amd64 would not is a bit puzzling.
>>>>>>> 
>>>>>>> The change I think needs to be made is:
>>>>>>> 
>>>>>>> diff --git a/makefiles/CompileNativeLibraries.gmk b/makefiles/CompileNativeLibraries.gmk
>>>>>>> --- a/makefiles/CompileNativeLibraries.gmk
>>>>>>> +++ b/makefiles/CompileNativeLibraries.gmk
>>>>>>> @@ -1807,7 +1807,7 @@
>>>>>>> BUILD_LIBHPROF_LDFLAGS:=
>>>>>>> 
>>>>>>> ifeq ($(OPENJDK_TARGET_OS),solaris)
>>>>>>> -     BUILD_LIBHPROF_LDFLAGS += -lsocket -lnsl
>>>>>>> +     BUILD_LIBHPROF_LDFLAGS += -lsocket -lnsl -lc
>>>>>>> endif
>>>>>>> 
>>>>>>> LIBHPROF_OPTIMIZATION:=HIGHEST
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> But I have not tested it yet.
>>>>>>> Did you want to give this patch a spin?
>>>>>>> 
>>>>>>> -kto
>>>>>>> 
>>>>>>>> Thanks.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 2 Nov 2012, at 17:45, Kelly O'Hair wrote:
>>>>>>>> 
>>>>>>>>> The attachment is missing.
>>>>>>>>> 
>>>>>>>>> This looks like the  -lc   is missing from the creation of hprof, we should never let libc be an implicit dependency.
>>>>>>>>> 
>>>>>>>>> I wonder if Solaris 11.1 has tightened up the rules on implicit dependencies. We have not seen this on Solaris 10.
>>>>>>>>> We just got svc6 setup as a 11.1 system, I'll see if it reproduces there.
>>>>>>>>> 
>>>>>>>>> And thank you for reporting this. Although Solaris 11.1 is not one of our critical systems, it's very important that this works.
>>>>>>>>> 
>>>>>>>>> -kto
>>>>>>>>> 
>>>>>>>>> On Nov 2, 2012, at 9:38 AM, Vincent Ryan wrote:
>>>>>>>>> 
>>>>>>>>>>> From: Vincent Ryan <vincent.x.ryan at oracle.com>
>>>>>>>>>>> Subject: Re: New builds from the build-infra team
>>>>>>>>>>> Date: 2 November 2012 15:48:03 GMT
>>>>>>>>>>> To: build-infra-dev at openjdk.java.net
>>>>>>>>>>> 
>>>>>>>>>>> I tried this out on the latest Solaris 11 Update 1 (sparc) but the build encountered problems locating libc when
>>>>>>>>>>> building jdk. (BTW the old build works correctly, just slower)
>>>>>>>>>>> 
>>>>>>>>>>> :
>>>>>>>>>>> :
>>>>>>>>>>> strerror                            /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>>>>>>> vfprintf                            /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_error.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>>>>>>> fprintf                             /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_init.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>>>>>>> gethrvtime                          /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
>>>>>>>>>>> ld: fatal: symbol referencing errors. No output written to /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so
>>>>>>>>>>> gmake[3]: *** [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so] Error 1
>>>>>>>>>>> gmake[3]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>>>>>>>>> gmake[2]: *** [libs-only] Error 2
>>>>>>>>>>> gmake[2]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
>>>>>>>>>>> make[1]: *** [jdk-only] Error 2
>>>>>>>>>>> make[1]: Leaving directory `/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release'
>>>>>>>>>>> make: *** [all] Error 2
>>>>>>>>>>> t4%
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> FYI I've attached the config script that was generated by configure.sh.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 1 Nov 2012, at 18:38, Kelly O'Hair wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Pardon the wide email, but this impacts everyone building the OpenJDK jdk8/jdk8 derived forests.
>>>>>>>>>>>> 
>>>>>>>>>>>> Please only reply to the build-infra-dev mailing list, or just me.
>>>>>>>>>>>> 
>>>>>>>>>>>> With some recent integrations from the build-infra project into jdk8/jdk8 repositories, the build-infra team
>>>>>>>>>>>> would like to get more exposure of the new builds. These jdk8/jdk8 changes will start showing up in various
>>>>>>>>>>>> jdk8 and team forests over the next few weeks. The default is still the old builds, but both builds work in most
>>>>>>>>>>>> cases for OpenJDK as far as we know.
>>>>>>>>>>>> 
>>>>>>>>>>>> At a very high level, the intent is that once you get a forest:
>>>>>>>>>>>> hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>>>>>>>>>>>> cd j8
>>>>>>>>>>>> sh ./get_source.sh
>>>>>>>>>>>> 
>>>>>>>>>>>> You should be able to simply configure&&make (the ultimate goal is this simple anyway), e.g.
>>>>>>>>>>>> sh ./configure
>>>>>>>>>>>> make NEWBUILD=true     # The NEWBUILD=true will become the default when we formally switch.
>>>>>>>>>>>> 
>>>>>>>>>>>> Where "make" is GNU make 3.81, and your system has all the requires packages and PATH contains the
>>>>>>>>>>>> needed tools. Note that on Windows, MKS unix utilities cannot be used with the new builds, just CYGWIN
>>>>>>>>>>>> is recommended at this time.
>>>>>>>>>>>> 
>>>>>>>>>>>> Of course, we know, it's never as easy as a simple configure&&make, and often you will need to pass in
>>>>>>>>>>>> configure options.
>>>>>>>>>>>> 
>>>>>>>>>>>> What we would like to know is where a simple configure&&make does not work, and anything people had
>>>>>>>>>>>> to do to make it work.
>>>>>>>>>>>> 
>>>>>>>>>>>> I know many of you are quite used to the old builds, so I have a temporary  "bridgeBuild" target
>>>>>>>>>>>> people can try that will attempt to map the ALT_* environment variables to an appropriate configure command
>>>>>>>>>>>> and then run that configure command and do the build, e.g.
>>>>>>>>>>>> 
>>>>>>>>>>>> make NEWBUILD=true bridgeBuild
>>>>>>>>>>>> 
>>>>>>>>>>>> People willing to do comparisons between the old and new builds could:
>>>>>>>>>>>> rm -f -r build
>>>>>>>>>>>> time make NEWBUILD=true bridgeBuild
>>>>>>>>>>>> rm -f -r build
>>>>>>>>>>>> time make NO_DOCS=true     # Old builds do not generate javadocs by default
>>>>>>>>>>>> 
>>>>>>>>>>>> Any observations about speed of the builds would be appreciated, as will any impressions on what you see.
>>>>>>>>>>>> 
>>>>>>>>>>>> At this time, we think this is working pretty well with a few caveats:
>>>>>>>>>>>> * GNU make with the new builds is doing much more parallel processing and this can stress out a system
>>>>>>>>>>>> - Use "make JOBS=1" if you suspect a problem, then try adjusting it up slowly.
>>>>>>>>>>>> * Partial builds are limited, right now full builds of the entire OpenJDK is the target
>>>>>>>>>>>> - Hotspot can still be built on it's own, but everyone else needs to build hotspot at least once
>>>>>>>>>>>> * Paths with multiple names can cause problems, e.g. being on system svc6, and access an exported share
>>>>>>>>>>>> area as /net/svc6/export/foobar  instead of /export/foobar  will cause problems. Use local paths.
>>>>>>>>>>>> 
>>>>>>>>>>>> We know there are still issues and we will be focusing heavily on the critical ones in the next few weeks, but
>>>>>>>>>>>> we do need the community to tell us what the critical issues really are.
>>>>>>>>>>>> 
>>>>>>>>>>>> Our number one priority at this time is that everyone that was able to build the old way, should be able to build
>>>>>>>>>>>> with the new build-infra makefiles. Please help us verify that.
>>>>>>>>>>>> 
>>>>>>>>>>>> -kto
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 



From kelly.ohair at oracle.com  Wed Nov  7 12:22:42 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 7 Nov 2012 12:22:42 -0800
Subject: New builds from the build-infra team
In-Reply-To: <509A6D34.8090507@oracle.com>
References: <DCA50F95-9C8E-45BB-86BE-6BE322E1E916@oracle.com>
	<509A6D34.8090507@oracle.com>
Message-ID: <DEF58201-75C0-4D4B-A063-7C8622C4F9D5@oracle.com>


On Nov 7, 2012, at 6:16 AM, Anthony Petrov wrote:

> Hi All,
> 
> (please keep me in CC since I'm not subscribed to this list)
> 
> (I'm building on Linux i586)

Fedora 9 x86 or something else?  The specific Linux distro and release number is always a big help.

> 
> 1. Could we add the /java/re/jdk/<version>/promoted/latest/binaries/<platform>/ directories to check for a Boot JDK to ./configure? E.g. /java/re/jdk/7u10/promoted/latest/binaries/linux-i586. I realize that this is almost useless outside of Oracle, but it would be really helpful for internal builds when one has already set up the /java directory structure properly.

I'm not sure that "... set up the /java directory structure properly." is a very well-defined thing. That's been part of the issue
with the /java/ layout, many people think they know what the layout is, but nobody has the same layout. :^(
I generally put the boot jdk java in the PATH, and that seems to work fine.
With the /java/re path being an automount NFS path, I have a very hard time making that something we will find by default.

But Magnus added a --with-java-path option that will use the /java paths, just have not used it.

We have tried hard to make the builds as fast as possible and reliable, and local installs of the tools is what
should be preferred.

> 
> 2. What is the ./build/linux-x86-normal-server-release directory, and why is it not ./build/linux-i586 ? What does 'normal' stand for? The same question about the 'server' part.
> 

The configure allows for many variations on builds, and the basic variation is put into the directory name.

I have been tempted to soft link linux-i586 to linux-x86-normal-server-release or whatever linux-x86-*name is generated
(assuming only one exists), but it gets a little complicated.


> 3. I get the following error and the build stops:
> 
>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `UnrollHalfToFloat':
>> cmspack.c:(.text+0x1f25): undefined reference to `_cmsHalf2Float'
>> cmspack.c:(.text+0x1f73): undefined reference to `_cmsHalf2Float'
>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `UnrollHalfTo16':
>> cmspack.c:(.text+0x261d): undefined reference to `_cmsHalf2Float'
>> cmspack.c:(.text+0x26bd): undefined reference to `_cmsHalf2Float'
>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `PackHalfFromFloat':
>> cmspack.c:(.text+0x36bb): undefined reference to `_cmsFloat2Half'
>> cmspack.c:(.text+0x3710): undefined reference to `_cmsFloat2Half'
>> cmspack.c:(.text+0x37af): undefined reference to `_cmsFloat2Half'
>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `PackHalfFrom16':
>> cmspack.c:(.text+0x38a8): undefined reference to `_cmsFloat2Half'
>> cmspack.c:(.text+0x3906): undefined reference to `_cmsFloat2Half'
>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o:cmspack.c:(.text+0x39a7): more undefined references to `_cmsFloat2Half' follow
>> collect2: ld returned 1 exit status
>> gmake[3]: *** [/export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/lib/i386/liblcms.so] Error 1
>> gmake[3]: *** Waiting for unfinished jobs....
>> gmake[3]: Leaving directory `/export/anthony/8-50-full-new-build/jdk/makefiles'
>> gmake[2]: *** [libs-only] Error 2
>> gmake[2]: Leaving directory `/export/anthony/8-50-full-new-build/jdk/makefiles'
>> make[1]: *** [jdk-only] Error 2
>> make[1]: Leaving directory `/export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release'
>> make: *** [all] Error 2
> 
> Is this a known issue with lcms? Note that I've almost exclusively always built JDK w/ closed repos, and this time I'm building OpenJDK repos only. I'll try to clone the closed parts and see if this eliminates the issue #3.

Never seen this problem before.

-kto

> 
> --
> best regards,
> Anthony
> 
> On 11/1/2012 10:38 PM, Kelly O'Hair wrote:
>> Pardon the wide email, but this impacts everyone building the OpenJDK jdk8/jdk8 derived forests.
>> Please only reply to the build-infra-dev mailing list, or just me.
>> With some recent integrations from the build-infra project into jdk8/jdk8 repositories, the build-infra team
>> would like to get more exposure of the new builds. These jdk8/jdk8 changes will start showing up in various
>> jdk8 and team forests over the next few weeks. The default is still the old builds, but both builds work in most
>> cases for OpenJDK as far as we know.
>> At a very high level, the intent is that once you get a forest:
>>  hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>>  cd j8
>>  sh ./get_source.sh
>> You should be able to simply configure&&make (the ultimate goal is this simple anyway), e.g.
>>   sh ./configure
>>   make NEWBUILD=true     # The NEWBUILD=true will become the default when we formally switch.
>> Where "make" is GNU make 3.81, and your system has all the requires packages and PATH contains the
>> needed tools. Note that on Windows, MKS unix utilities cannot be used with the new builds, just CYGWIN
>> is recommended at this time.
>> Of course, we know, it's never as easy as a simple configure&&make, and often you will need to pass in
>> configure options.
>> What we would like to know is where a simple configure&&make does not work, and anything people had
>> to do to make it work.
>> I know many of you are quite used to the old builds, so I have a temporary  "bridgeBuild" target
>> people can try that will attempt to map the ALT_* environment variables to an appropriate configure command
>> and then run that configure command and do the build, e.g.
>>  make NEWBUILD=true bridgeBuild
>> People willing to do comparisons between the old and new builds could:
>>  rm -f -r build
>>  time make NEWBUILD=true bridgeBuild
>>  rm -f -r build
>>  time make NO_DOCS=true     # Old builds do not generate javadocs by default
>> Any observations about speed of the builds would be appreciated, as will any impressions on what you see.
>> At this time, we think this is working pretty well with a few caveats:
>>  * GNU make with the new builds is doing much more parallel processing and this can stress out a system
>>    - Use "make JOBS=1" if you suspect a problem, then try adjusting it up slowly.
>>  * Partial builds are limited, right now full builds of the entire OpenJDK is the target
>>    - Hotspot can still be built on it's own, but everyone else needs to build hotspot at least once
>>  * Paths with multiple names can cause problems, e.g. being on system svc6, and access an exported share
>>    area as /net/svc6/export/foobar  instead of /export/foobar  will cause problems. Use local paths.
>> We know there are still issues and we will be focusing heavily on the critical ones in the next few weeks, but
>> we do need the community to tell us what the critical issues really are.
>> Our number one priority at this time is that everyone that was able to build the old way, should be able to build
>> with the new build-infra makefiles. Please help us verify that.
>> -kto



From kelly.ohair at oracle.com  Wed Nov  7 12:30:41 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 7 Nov 2012 12:30:41 -0800
Subject: New builds from the build-infra team
In-Reply-To: <509A7D7F.60608@oracle.com>
References: <DCA50F95-9C8E-45BB-86BE-6BE322E1E916@oracle.com>
	<509A6D34.8090507@oracle.com> <509A7AE4.1060805@oracle.com>
	<509A7D7F.60608@oracle.com>
Message-ID: <D06266B6-A104-4FF1-9262-62477B7FC259@oracle.com>


On Nov 7, 2012, at 7:25 AM, Anthony Petrov wrote:

> A follow up message. Generally, the new builds work fine. A couple suggestions:
> 
> 1. Can we make hotspot builds less noisy? Unless there are warnings or errors, there's no need to print out the name of each file being compiled.

It's hard to know before hand if a file has errors or warnings but the hotspot makefiles are actually
unchanged for the most part, so you are seeing the old and traditional hotspot build output.

There is a great deal of debate on this noisy vs. quiet logging issue, and Magnus at least tried to deal with
it by adding a LOG option, so you can try:
   make LOG=warn
if I remember right. But it may be a while before we can get the hotspot makefiles to obey this setting.

> 
> 2. There's a lot of warnings generated when compiling JDK native code. I think some of them can be related to the new build. After they are analyzed, can somebody from build-infra file bugs against appropriate teams to fix them up?

I don't think the new build is adding warnings, but I can't be sure. These should be the same warnings as the old
build, but may be more visible when the compile lines are not echo'd.

The last time I filed a whole bunch of bugs against warnings in the build, it was a royal pain, like herding cats
to get all the various teams to do anything about it. But at some point we will do another warning hunt fix,
just not sure the build team will be driving it or not.

-kto

> 
> --
> best regards,
> Anthony
> 
> On 11/7/2012 7:14 PM, Anthony Petrov wrote:
>> Update on issue #3: after cloning the closed repos my build succeeded. Must be an issue related to OPENJDK=true builds only. Still, I'd like to get some comments regarding #1 and #2 below. Thanks in advance.
>> -- 
>> best regards,
>> Anthony
>> On 11/7/2012 6:16 PM, Anthony Petrov wrote:
>>> Hi All,
>>> 
>>> (please keep me in CC since I'm not subscribed to this list)
>>> 
>>> (I'm building on Linux i586)
>>> 
>>> 1. Could we add the /java/re/jdk/<version>/promoted/latest/binaries/<platform>/ directories to check for a Boot JDK to ./configure? E.g. /java/re/jdk/7u10/promoted/latest/binaries/linux-i586. I realize that this is almost useless outside of Oracle, but it would be really helpful for internal builds when one has already set up the /java directory structure properly.
>>> 
>>> 2. What is the ./build/linux-x86-normal-server-release directory, and why is it not ./build/linux-i586 ? What does 'normal' stand for? The same question about the 'server' part.
>>> 
>>> 3. I get the following error and the build stops:
>>> 
>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `UnrollHalfToFloat':
>>>> cmspack.c:(.text+0x1f25): undefined reference to `_cmsHalf2Float'
>>>> cmspack.c:(.text+0x1f73): undefined reference to `_cmsHalf2Float'
>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `UnrollHalfTo16':
>>>> cmspack.c:(.text+0x261d): undefined reference to `_cmsHalf2Float'
>>>> cmspack.c:(.text+0x26bd): undefined reference to `_cmsHalf2Float'
>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `PackHalfFromFloat':
>>>> cmspack.c:(.text+0x36bb): undefined reference to `_cmsFloat2Half'
>>>> cmspack.c:(.text+0x3710): undefined reference to `_cmsFloat2Half'
>>>> cmspack.c:(.text+0x37af): undefined reference to `_cmsFloat2Half'
>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `PackHalfFrom16':
>>>> cmspack.c:(.text+0x38a8): undefined reference to `_cmsFloat2Half'
>>>> cmspack.c:(.text+0x3906): undefined reference to `_cmsFloat2Half'
>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o:cmspack.c:(.text+0x39a7): more undefined references to `_cmsFloat2Half' follow
>>>> collect2: ld returned 1 exit status
>>>> gmake[3]: *** [/export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/lib/i386/liblcms.so] Error 1
>>>> gmake[3]: *** Waiting for unfinished jobs....
>>>> gmake[3]: Leaving directory `/export/anthony/8-50-full-new-build/jdk/makefiles'
>>>> gmake[2]: *** [libs-only] Error 2
>>>> gmake[2]: Leaving directory `/export/anthony/8-50-full-new-build/jdk/makefiles'
>>>> make[1]: *** [jdk-only] Error 2
>>>> make[1]: Leaving directory `/export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release' 
>>>> make: *** [all] Error 2
>>> 
>>> Is this a known issue with lcms? Note that I've almost exclusively always built JDK w/ closed repos, and this time I'm building OpenJDK repos only. I'll try to clone the closed parts and see if this eliminates the issue #3.
>>> 
>>> -- 
>>> best regards,
>>> Anthony
>>> 
>>> On 11/1/2012 10:38 PM, Kelly O'Hair wrote:
>>>> Pardon the wide email, but this impacts everyone building the OpenJDK jdk8/jdk8 derived forests.
>>>> 
>>>> Please only reply to the build-infra-dev mailing list, or just me.
>>>> 
>>>> With some recent integrations from the build-infra project into jdk8/jdk8 repositories, the build-infra team
>>>> would like to get more exposure of the new builds. These jdk8/jdk8 changes will start showing up in various
>>>> jdk8 and team forests over the next few weeks. The default is still the old builds, but both builds work in most
>>>> cases for OpenJDK as far as we know.
>>>> 
>>>> At a very high level, the intent is that once you get a forest:
>>>>  hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>>>>  cd j8
>>>>  sh ./get_source.sh
>>>> 
>>>> You should be able to simply configure&&make (the ultimate goal is this simple anyway), e.g.
>>>>   sh ./configure
>>>>   make NEWBUILD=true     # The NEWBUILD=true will become the default when we formally switch.
>>>> 
>>>> Where "make" is GNU make 3.81, and your system has all the requires packages and PATH contains the
>>>> needed tools. Note that on Windows, MKS unix utilities cannot be used with the new builds, just CYGWIN
>>>> is recommended at this time.
>>>> 
>>>> Of course, we know, it's never as easy as a simple configure&&make, and often you will need to pass in
>>>> configure options.
>>>> 
>>>> What we would like to know is where a simple configure&&make does not work, and anything people had
>>>> to do to make it work.
>>>> 
>>>> I know many of you are quite used to the old builds, so I have a temporary  "bridgeBuild" target
>>>> people can try that will attempt to map the ALT_* environment variables to an appropriate configure command
>>>> and then run that configure command and do the build, e.g.
>>>> 
>>>>  make NEWBUILD=true bridgeBuild
>>>> 
>>>> People willing to do comparisons between the old and new builds could:
>>>>  rm -f -r build
>>>>  time make NEWBUILD=true bridgeBuild
>>>>  rm -f -r build
>>>>  time make NO_DOCS=true     # Old builds do not generate javadocs by default
>>>> 
>>>> Any observations about speed of the builds would be appreciated, as will any impressions on what you see.
>>>> 
>>>> At this time, we think this is working pretty well with a few caveats:
>>>>  * GNU make with the new builds is doing much more parallel processing and this can stress out a system
>>>>    - Use "make JOBS=1" if you suspect a problem, then try adjusting it up slowly.
>>>>  * Partial builds are limited, right now full builds of the entire OpenJDK is the target
>>>>    - Hotspot can still be built on it's own, but everyone else needs to build hotspot at least once
>>>>  * Paths with multiple names can cause problems, e.g. being on system svc6, and access an exported share
>>>>    area as /net/svc6/export/foobar  instead of /export/foobar  will cause problems. Use local paths.
>>>> 
>>>> We know there are still issues and we will be focusing heavily on the critical ones in the next few weeks, but
>>>> we do need the community to tell us what the critical issues really are.
>>>> 
>>>> Our number one priority at this time is that everyone that was able to build the old way, should be able to build
>>>> with the new build-infra makefiles. Please help us verify that.
>>>> 
>>>> -kto
>>>> 
>>> 



From david.holmes at oracle.com  Wed Nov  7 19:41:00 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 08 Nov 2012 13:41:00 +1000
Subject: New builds from the build-infra team
In-Reply-To: <DEF58201-75C0-4D4B-A063-7C8622C4F9D5@oracle.com>
References: <DCA50F95-9C8E-45BB-86BE-6BE322E1E916@oracle.com>
	<509A6D34.8090507@oracle.com>
	<DEF58201-75C0-4D4B-A063-7C8622C4F9D5@oracle.com>
Message-ID: <509B29CC.2050409@oracle.com>

On 8/11/2012 6:22 AM, Kelly O'Hair wrote:
> On Nov 7, 2012, at 6:16 AM, Anthony Petrov wrote:
>> 2. What is the ./build/linux-x86-normal-server-release directory, and why is it not ./build/linux-i586 ? What does 'normal' stand for? The same question about the 'server' part.
>>
>
> The configure allows for many variations on builds, and the basic variation is put into the directory name.
>
> I have been tempted to soft link linux-i586 to linux-x86-normal-server-release or whatever linux-x86-*name is generated
> (assuming only one exists), but it gets a little complicated.

A couple of comments on this. As Kelly says a "configuration" can be set 
up to build a range of different, well, configurations, and the default 
output name reflects what you have chosen (directly or implicitly).

The "normal" is in contrast to "embedded" (which of course is not 
applicable to OpenJDK builds). When the conversion was first started the 
embedded build support was in the open and so two JDK variants were 
defined. Now that the embedded build support is in the closed repo we 
still need two variants but people only using open repos can't see there 
is any alternative to "normal".

The "server" part is important as it indicates what flavor(s) of hotspot 
this configuration will build. By default (why?) only the server VM is 
built - whereas in the old build both client and server are built. So 
you need to add --with-jvm-variant=client,server if you want both.

The "release" indicates a product build as opposed to fastdebug, for 
example.

Personally I never let configure define or name the output directory. My 
preferred approach is (via scripts) to do:

mkdir <output-dir>
cd <output-dir>
bash <path-to-configure> configure.sh <options>

There may also be a configure option to name the output directory 
explicitly.

>> 3. I get the following error and the build stops:

This might not be relevant but you need to be careful if you are 
building 32-bit on an x64 machine. If you do that you need to pass 
--with-target-bits=32. Otherwise the default build on x64 is 64-bit.

David
------


From erik.joelsson at oracle.com  Thu Nov  8 05:32:16 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 08 Nov 2012 13:32:16 +0000
Subject: hg: build-infra/jdk8: 7 new changesets
Message-ID: <20121108133217.C19154784E@hg.openjdk.java.net>

Changeset: cababb9dfce7
Author:    katleman
Date:      2012-11-01 14:10 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/cababb9dfce7

Added tag jdk8-b63 for changeset 3229597524ca

! .hgtags

Changeset: dd1a80efa7cf
Author:    anthony
Date:      2012-10-30 15:04 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/dd1a80efa7cf

8001764: vsvars.sh should support VS2012
Summary: Update the vsvars.sh script to support VS2012
Reviewed-by: ohair, tbell

! make/scripts/vsvars.sh

Changeset: fc61be4ff6ae
Author:    lana
Date:      2012-10-31 09:12 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/fc61be4ff6ae

Merge

! make/scripts/vsvars.sh

Changeset: 65dca75b2a26
Author:    lana
Date:      2012-11-02 17:32 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/65dca75b2a26

Merge


Changeset: 1c8370a55b30
Author:    katleman
Date:      2012-11-07 15:32 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/1c8370a55b30

Merge


Changeset: 8bbc72864a41
Author:    ohrstrom
Date:      2012-11-08 12:24 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/8bbc72864a41

8003161: small fixes to re-enable new build system
Reviewed-by: dholmes, alanb, erikj

! common/makefiles/JavaCompilation.gmk

Changeset: 056f66c57a53
Author:    erikj
Date:      2012-11-08 13:56 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/056f66c57a53

Merge

! common/makefiles/JavaCompilation.gmk



From erik.joelsson at oracle.com  Thu Nov  8 05:32:16 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 08 Nov 2012 13:32:16 +0000
Subject: hg: build-infra/jdk8/corba: 5 new changesets
Message-ID: <20121108133220.54AEC4784F@hg.openjdk.java.net>

Changeset: b450c07849ab
Author:    katleman
Date:      2012-11-01 14:11 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/corba/rev/b450c07849ab

Added tag jdk8-b63 for changeset 6ccbf67b68bf

! .hgtags

Changeset: 643e7612cf6d
Author:    ohrstrom
Date:      2012-10-29 14:10 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/corba/rev/643e7612cf6d

8000970: break out auxiliary classes that will prevent multi-core compilation of the JDK.
Reviewed-by: alanb, wetmore

! src/share/classes/com/sun/corba/se/impl/util/IdentityHashtable.java
+ src/share/classes/com/sun/corba/se/impl/util/IdentityHashtableEntry.java

Changeset: aac74d377a03
Author:    lana
Date:      2012-10-30 23:26 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/corba/rev/aac74d377a03

Merge


Changeset: 54d599a5b4aa
Author:    lana
Date:      2012-11-02 17:54 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/corba/rev/54d599a5b4aa

Merge


Changeset: 69ba60e5d89d
Author:    erikj
Date:      2012-11-08 13:56 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/corba/rev/69ba60e5d89d

Merge




From erik.joelsson at oracle.com  Thu Nov  8 05:32:17 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 08 Nov 2012 13:32:17 +0000
Subject: hg: build-infra/jdk8/jaxp: 2 new changesets
Message-ID: <20121108133223.3179C47851@hg.openjdk.java.net>

Changeset: 27ab79568c34
Author:    katleman
Date:      2012-11-01 14:11 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jaxp/rev/27ab79568c34

Added tag jdk8-b63 for changeset 192d8a244bc3

! .hgtags

Changeset: 142281d5310a
Author:    erikj
Date:      2012-11-08 13:56 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jaxp/rev/142281d5310a

Merge




From erik.joelsson at oracle.com  Thu Nov  8 05:32:17 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 08 Nov 2012 13:32:17 +0000
Subject: hg: build-infra/jdk8/jaxws: 2 new changesets
Message-ID: <20121108133222.896F347850@hg.openjdk.java.net>

Changeset: 5ded18a14bcc
Author:    katleman
Date:      2012-11-01 14:11 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jaxws/rev/5ded18a14bcc

Added tag jdk8-b63 for changeset 86989f702267

! .hgtags

Changeset: a8a8752baca5
Author:    erikj
Date:      2012-11-08 13:56 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jaxws/rev/a8a8752baca5

Merge




From erik.joelsson at oracle.com  Thu Nov  8 05:41:09 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 08 Nov 2012 13:41:09 +0000
Subject: hg: build-infra/jdk8/hotspot: 17 new changesets
Message-ID: <20121108134143.D92CB47852@hg.openjdk.java.net>

Changeset: 4d37eb50b9b1
Author:    katleman
Date:      2012-11-01 14:11 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/4d37eb50b9b1

Added tag jdk8-b63 for changeset acabb5c282f5

! .hgtags

Changeset: a516debe2cee
Author:    amurillo
Date:      2012-10-26 14:18 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/a516debe2cee

8001663: new hotspot build - hs25-b08
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 5ec0c42da025
Author:    coleenp
Date:      2012-10-25 16:33 -0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/5ec0c42da025

7188234: Deprecate VM command line options
Summary: Remove support for the UseVectoredExceptions flag
Reviewed-by: jcoomes, kamg
Contributed-by: harold.seigel at oracle.com

! src/os/windows/vm/os_windows.cpp
! src/os_cpu/bsd_x86/vm/globals_bsd_x86.hpp
! src/os_cpu/bsd_zero/vm/globals_bsd_zero.hpp
! src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp
! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp
! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp
! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp
! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp
! src/os_cpu/windows_x86/vm/globals_windows_x86.hpp
! src/os_cpu/windows_x86/vm/os_windows_x86.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: e81fbc04a942
Author:    coleenp
Date:      2012-10-25 16:33 -0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/e81fbc04a942

7191817: -XX:+UseSerialGC -XX:+UseLargePages crashes with SIGFPE on MacOS X
Summary: Disable -XX:+UseLargePages for MacOS X
Reviewed-by: dholmes, coleenp, sla
Contributed-by: harold.seigel at oracle.com

! src/share/vm/runtime/arguments.cpp

Changeset: 0af5da0c9d9d
Author:    sla
Date:      2012-10-29 21:04 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/0af5da0c9d9d

8001619: Remove usage of _ALLBSD_SOURCE in bsd files
Reviewed-by: coleenp, dholmes

! src/os/bsd/vm/attachListener_bsd.cpp
! src/os/bsd/vm/osThread_bsd.hpp
! src/os/bsd/vm/os_bsd.cpp
! src/os/bsd/vm/os_bsd.hpp
! src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp
! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp
! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp

Changeset: 39556eae08af
Author:    sspitsyn
Date:      2012-10-29 11:35 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/39556eae08af

6533010: SPEC: A few broken links in jvmti.html
Summary: Fix the incorrect links in jvmti.html reported by the LinkCheck tool
Reviewed-by: jjh, dholmes
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/prims/jvmti.xml
! src/share/vm/prims/jvmtiEnvBase.hpp

Changeset: 845129b692f6
Author:    minqi
Date:      2012-10-29 16:39 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/845129b692f6

Merge


Changeset: a1b8cf9cf970
Author:    sla
Date:      2012-11-01 13:05 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/a1b8cf9cf970

8002078: hs_err_pid file should report full JDK version string
Reviewed-by: dholmes, sspitsyn, kmo

! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/java.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/utilities/vmError.cpp

Changeset: cae17c597196
Author:    coleenp
Date:      2012-11-01 11:57 -0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/cae17c597196

Merge

! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/runtime/globals.hpp

Changeset: 3fadc0e8cffe
Author:    jmasa
Date:      2012-10-30 10:23 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/3fadc0e8cffe

8000988: VM deadlock when running btree006 on windows-i586
Reviewed-by: johnc, jcoomes, ysr

! src/share/vm/memory/collectorPolicy.cpp

Changeset: 3dfffc8b9722
Author:    brutisso
Date:      2012-10-30 20:26 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/3dfffc8b9722

8001564: The load balancing function steal_1_random in taskqueue is not random
Summary: Removes the two unused functions GenericTaskQueueSet::steal_1_random and GenericTaskQueueSet::steal_best_of_all
Reviewed-by: brutisso, stefank
Contributed-by: erik.x.helin at oracle.com

! src/share/vm/utilities/taskqueue.hpp

Changeset: ca6d147ed881
Author:    jcoomes
Date:      2012-11-01 23:08 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/ca6d147ed881

Merge


Changeset: a3e2f723f2a5
Author:    twisti
Date:      2012-10-29 11:08 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/a3e2f723f2a5

8000780: make Zero build and run with JDK8
Reviewed-by: coleenp, dholmes, twisti
Contributed-by: Roman Kennke <rkennke at redhat.com>

! make/Makefile
! src/cpu/zero/vm/cppInterpreterGenerator_zero.hpp
! src/cpu/zero/vm/cppInterpreter_zero.cpp
! src/cpu/zero/vm/cppInterpreter_zero.hpp
! src/cpu/zero/vm/frame_zero.cpp
! src/cpu/zero/vm/frame_zero.inline.hpp
! src/cpu/zero/vm/icBuffer_zero.cpp
! src/cpu/zero/vm/methodHandles_zero.cpp
! src/cpu/zero/vm/methodHandles_zero.hpp
! src/cpu/zero/vm/register_zero.hpp
! src/cpu/zero/vm/relocInfo_zero.cpp
! src/cpu/zero/vm/sharedRuntime_zero.cpp
! src/share/vm/asm/codeBuffer.cpp
! src/share/vm/interpreter/abstractInterpreter.hpp
! src/share/vm/interpreter/bytecodeInterpreter.cpp
! src/share/vm/interpreter/bytecodeInterpreter.hpp
! src/share/vm/interpreter/cppInterpreter.cpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/templateInterpreter.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/utilities/macros.hpp

Changeset: d8f9034920f6
Author:    amurillo
Date:      2012-11-02 04:06 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/d8f9034920f6

Merge


Changeset: 8cb93eadfb6d
Author:    amurillo
Date:      2012-11-02 07:35 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/8cb93eadfb6d

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: 5920f72e799c
Author:    amurillo
Date:      2012-11-02 07:35 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/5920f72e799c

Added tag hs25-b08 for changeset 8cb93eadfb6d

! .hgtags

Changeset: 74aa27719c1b
Author:    erikj
Date:      2012-11-08 13:56 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/74aa27719c1b

Merge

! make/Makefile



From erik.joelsson at oracle.com  Thu Nov  8 05:37:53 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 08 Nov 2012 13:37:53 +0000
Subject: hg: build-infra/jdk8/jdk: 49 new changesets
Message-ID: <20121108134718.9EDED47853@hg.openjdk.java.net>

Changeset: 7ac292e57b5a
Author:    katleman
Date:      2012-11-01 14:12 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/7ac292e57b5a

Added tag jdk8-b63 for changeset f117a3e06f78

! .hgtags

Changeset: cc998992dc32
Author:    bae
Date:      2012-10-24 05:30 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/cc998992dc32

7053526: Upgrade JDK 8 to use Little CMS 2.4
Reviewed-by: prr, jgodinez

! make/sun/cmm/lcms/FILES_c_unix.gmk
! make/sun/cmm/lcms/FILES_c_windows.gmk
! src/share/native/sun/java2d/cmm/lcms/cmscam02.c
! src/share/native/sun/java2d/cmm/lcms/cmscgats.c
! src/share/native/sun/java2d/cmm/lcms/cmscnvrt.c
! src/share/native/sun/java2d/cmm/lcms/cmserr.c
! src/share/native/sun/java2d/cmm/lcms/cmsgamma.c
! src/share/native/sun/java2d/cmm/lcms/cmsgmt.c
+ src/share/native/sun/java2d/cmm/lcms/cmshalf.c
! src/share/native/sun/java2d/cmm/lcms/cmsintrp.c
! src/share/native/sun/java2d/cmm/lcms/cmsio0.c
! src/share/native/sun/java2d/cmm/lcms/cmsio1.c
! src/share/native/sun/java2d/cmm/lcms/cmslut.c
! src/share/native/sun/java2d/cmm/lcms/cmsmd5.c
! src/share/native/sun/java2d/cmm/lcms/cmsmtrx.c
! src/share/native/sun/java2d/cmm/lcms/cmsnamed.c
! src/share/native/sun/java2d/cmm/lcms/cmsopt.c
! src/share/native/sun/java2d/cmm/lcms/cmspack.c
! src/share/native/sun/java2d/cmm/lcms/cmspcs.c
! src/share/native/sun/java2d/cmm/lcms/cmsplugin.c
! src/share/native/sun/java2d/cmm/lcms/cmsps2.c
! src/share/native/sun/java2d/cmm/lcms/cmssamp.c
! src/share/native/sun/java2d/cmm/lcms/cmssm.c
! src/share/native/sun/java2d/cmm/lcms/cmstypes.c
! src/share/native/sun/java2d/cmm/lcms/cmsvirt.c
! src/share/native/sun/java2d/cmm/lcms/cmswtpnt.c
! src/share/native/sun/java2d/cmm/lcms/cmsxform.c
! src/share/native/sun/java2d/cmm/lcms/lcms2.h
! src/share/native/sun/java2d/cmm/lcms/lcms2_internal.h
! src/share/native/sun/java2d/cmm/lcms/lcms2_plugin.h

Changeset: 00c8ea9ef1cf
Author:    lana
Date:      2012-10-31 09:49 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/00c8ea9ef1cf

Merge

- src/share/classes/sun/net/www/protocol/gopher/GopherClient.java
- src/share/classes/sun/net/www/protocol/gopher/Handler.java
- src/share/classes/sun/security/tools/CertAndKeyGen.java
- src/share/classes/sun/security/tools/JarSigner.java
- src/share/classes/sun/security/tools/JarSignerResources.java
- src/share/classes/sun/security/tools/JarSignerResources_ja.java
- src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java
- src/share/classes/sun/security/tools/KeyTool.java
- src/share/classes/sun/security/tools/TimestampedSigner.java
- src/windows/classes/java/io/Win32FileSystem.java
- src/windows/native/java/io/Win32FileSystem_md.c
- test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java
- test/com/sun/jndi/ldap/ReadTimeoutTest.java

Changeset: c9523d220bc3
Author:    lana
Date:      2012-11-02 17:32 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/c9523d220bc3

Merge


Changeset: 3b889d1218f5
Author:    alitvinov
Date:      2012-10-24 18:27 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/3b889d1218f5

7193219: JComboBox serialization fails in JDK 1.7
Reviewed-by: rupashka, anthony

! src/share/classes/javax/swing/AncestorNotifier.java
+ test/javax/swing/AncestorNotifier/7193219/bug7193219.java

Changeset: c27efe7615f8
Author:    bagiras
Date:      2012-10-25 09:55 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/c27efe7615f8

8000486: REGRESSION: Three java2d tests fail since jdk8b58 on Windows 7 with NullPointerException
Reviewed-by: flar, art

! src/windows/classes/sun/java2d/ScreenUpdateManager.java

Changeset: 9fb5db444365
Author:    bagiras
Date:      2012-10-25 19:50 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/9fb5db444365

7082294: nsk/regression/b4265661 crashes on windows
Reviewed-by: art, anthony

! src/windows/native/sun/windows/awt_Font.cpp
! src/windows/native/sun/windows/awt_Toolkit.cpp

Changeset: 7ead109417f0
Author:    serb
Date:      2012-10-29 23:10 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/7ead109417f0

7198229: Painting during resizing of the frame should be more smooth
Reviewed-by: anthony, denis, skovatch

! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
! src/macosx/native/sun/awt/AWTView.m
! src/macosx/native/sun/java2d/opengl/CGLLayer.m

Changeset: 884402437aad
Author:    kshefov
Date:      2012-10-30 12:47 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/884402437aad

7072120: No mac os x support in several regression tests
Reviewed-by: anthony, serb

! test/java/awt/Toolkit/AutoShutdown/ShowExitTest/ShowExitTest.sh
! test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh
! test/javax/imageio/stream/StreamCloserLeak/run_test.sh

Changeset: 6652efb69459
Author:    lana
Date:      2012-10-31 09:25 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/6652efb69459

Merge

- src/share/classes/sun/net/www/protocol/gopher/GopherClient.java
- src/share/classes/sun/net/www/protocol/gopher/Handler.java
- src/share/classes/sun/security/tools/CertAndKeyGen.java
- src/share/classes/sun/security/tools/JarSigner.java
- src/share/classes/sun/security/tools/JarSignerResources.java
- src/share/classes/sun/security/tools/JarSignerResources_ja.java
- src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java
- src/share/classes/sun/security/tools/KeyTool.java
- src/share/classes/sun/security/tools/TimestampedSigner.java
- src/windows/classes/java/io/Win32FileSystem.java
- src/windows/native/java/io/Win32FileSystem_md.c
- test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java
- test/com/sun/jndi/ldap/ReadTimeoutTest.java

Changeset: 9b5c596a2920
Author:    VKARNAUK
Date:      2012-11-02 15:57 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/9b5c596a2920

2229575: Swing HTML parser can't properly decode codepoints outside the Unicode Plane 0 into a surrogate pair
Reviewed-by: rupashka

! src/share/classes/javax/swing/text/html/parser/Parser.java
+ test/javax/swing/text/html/parser/Parser/6836089/bug6836089.java

Changeset: 3d22bd7d6678
Author:    alexp
Date:      2012-11-02 16:14 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/3d22bd7d6678

8001633: Wrong alt processing during switching between windows.
Reviewed-by: ant, leonidr
Contributed-by: Mikhail Cherkasov <mikhail.cherkasov at oracle.com>

! src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java
! src/share/classes/java/awt/event/KeyEvent.java
! src/share/classes/sun/awt/AWTAccessor.java
+ test/javax/swing/plaf/windows/WindowsRootPaneUI/WrongAltProcessing/WrongAltProcessing.java

Changeset: 094c963dca1b
Author:    leonidr
Date:      2012-11-02 19:20 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/094c963dca1b

7124310: [macosx] "opposite" seems always null in focus events
Reviewed-by: anthony

! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/awt/AWTWindow.h
! src/macosx/native/sun/awt/AWTWindow.m

Changeset: f4a11601680b
Author:    leonidr
Date:      2012-11-02 19:47 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/f4a11601680b

8002114: fix failed for JDK-7160951: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar
Reviewed-by: serb

! src/macosx/native/sun/awt/CMenuItem.m

Changeset: 509b3b4910ef
Author:    kshefov
Date:      2012-11-02 17:05 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/509b3b4910ef

8001808: Create a test for 8000327
Reviewed-by: alexsch, serb

+ test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java

Changeset: 706056a4a6d9
Author:    kshefov
Date:      2012-11-02 17:07 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/706056a4a6d9

8001876: Create regtest for 8000283
Reviewed-by: alexsch, serb

+ test/javax/swing/JMenuItem/ShortcutNotDiplayed/ShortcutNotDisplayedTest.java

Changeset: ebd8f16bae1b
Author:    lana
Date:      2012-11-02 17:34 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/ebd8f16bae1b

Merge


Changeset: 940c8cc5a5c4
Author:    wetmore
Date:      2012-10-23 12:36 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/940c8cc5a5c4

7197071: Makefiles for various security providers aren't including the default manifest
Reviewed-by: valeriep, mullan, katleman

! make/com/oracle/security/ucrypto/Makefile
! make/javax/crypto/Defs-jce.gmk
! make/sun/security/ec/Makefile
! make/sun/security/mscapi/Makefile
! make/sun/security/pkcs11/Makefile
+ test/javax/crypto/sanity/CheckManifestForRelease.java

Changeset: 13b46e8eda33
Author:    ohrstrom
Date:      2012-10-23 15:51 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/13b46e8eda33

8001419: Build the JCE portion of JDK-8000970
Summary: Original code done by Fredrik Ohrstrom, separated/pushed by wetmore
Reviewed-by: wetmore

! src/share/classes/com/sun/crypto/provider/KeyProtector.java
+ src/share/classes/com/sun/crypto/provider/SealedObjectForKeyProtector.java

Changeset: e782f3c383fe
Author:    xuelei
Date:      2012-10-24 08:25 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/e782f3c383fe

8001466: Nightly regression test failure of SSLSocketSNISensitive.java
Reviewed-by: weijun

! test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java

Changeset: 8e8fcd44b963
Author:    jbachorik
Date:      2012-10-24 20:44 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/8e8fcd44b963

6976971: TEST: javax/management/remote/mandatory/URLTest.java should be re-integrated
Reviewed-by: alanb

! test/javax/management/remote/mandatory/URLTest.java

Changeset: 909676adaefd
Author:    chegar
Date:      2012-10-24 21:20 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/909676adaefd

8000203: File descriptor leak in src/solaris/native/java/net/net_util_md.c
Reviewed-by: dsamersoff, khazra, chegar
Contributed-by: John Zavgren <john.zavgren at oracle.com>

! src/solaris/native/java/net/net_util_md.c

Changeset: 37a4b4892e8e
Author:    jgish
Date:      2012-10-25 15:04 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/37a4b4892e8e

7159567: inconsistent configuration of MemoryHandler
Reviewed-by: mchung, alanb

! src/share/classes/java/util/logging/ConsoleHandler.java
! src/share/classes/java/util/logging/FileHandler.java
! src/share/classes/java/util/logging/MemoryHandler.java
! src/share/classes/java/util/logging/SocketHandler.java
! src/share/classes/java/util/logging/StreamHandler.java
+ test/java/util/logging/MemoryHandlerTest.java
+ test/java/util/logging/MemoryHandlerTest.props

Changeset: 27677928a937
Author:    dxu
Date:      2012-10-25 15:42 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/27677928a937

8001565: (fs) Typo Path.endsWith(String) javadoc
Reviewed-by: mchung, jgish, lancea

! src/share/classes/java/nio/file/Path.java

Changeset: 6302932b7380
Author:    rfield
Date:      2012-10-25 17:34 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/6302932b7380

8000806: Implement runtime lambda metafactory
Summary: Implement lambda invokedynamic bootstrap by generating at runtime an inner class that implements the functional interface
Reviewed-by: twisti

+ src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
+ src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
+ src/share/classes/java/lang/invoke/LambdaConversionException.java
+ src/share/classes/java/lang/invoke/LambdaMetafactory.java
+ src/share/classes/java/lang/invoke/MagicLambdaImpl.java
+ src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java

Changeset: 0b52c87c39da
Author:    dxu
Date:      2012-10-26 11:21 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/0b52c87c39da

4239752: FileSystem should be a platform-specific class to avoid native code
Reviewed-by: alanb, dholmes, erikj, jgish

! make/java/java/Exportedfiles.gmk
! make/java/java/FILES_c.gmk
! make/java/java/FILES_java.gmk
! make/java/java/mapfile-vers
! makefiles/CompileJavaClasses.gmk
! makefiles/mapfiles/libjava/mapfile-vers
! src/share/classes/java/io/File.java
! src/share/classes/java/io/FileSystem.java
+ src/solaris/classes/java/io/DefaultFileSystem.java
- src/solaris/native/java/io/FileSystem_md.c
+ src/windows/classes/java/io/DefaultFileSystem.java
- src/windows/native/java/io/FileSystem_md.c

Changeset: 3fc5457cf779
Author:    dl
Date:      2012-10-26 21:34 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/3fc5457cf779

8001575: Minor/sync/cleanup j.u.c with Dougs CVS - Oct 2012
Reviewed-by: chegar, dholmes

! src/share/classes/java/util/concurrent/AbstractExecutorService.java
! src/share/classes/java/util/concurrent/BlockingQueue.java
! src/share/classes/java/util/concurrent/BrokenBarrierException.java
! src/share/classes/java/util/concurrent/CompletionService.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
! src/share/classes/java/util/concurrent/ConcurrentMap.java
! src/share/classes/java/util/concurrent/ConcurrentNavigableMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java
! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
! src/share/classes/java/util/concurrent/CountDownLatch.java
! src/share/classes/java/util/concurrent/CyclicBarrier.java
! src/share/classes/java/util/concurrent/Delayed.java
! src/share/classes/java/util/concurrent/ExecutionException.java
! src/share/classes/java/util/concurrent/Executor.java
! src/share/classes/java/util/concurrent/ExecutorService.java
! src/share/classes/java/util/concurrent/Executors.java
! src/share/classes/java/util/concurrent/Future.java
! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java
! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java
! src/share/classes/java/util/concurrent/LinkedTransferQueue.java
! src/share/classes/java/util/concurrent/RecursiveAction.java
! src/share/classes/java/util/concurrent/RejectedExecutionException.java
! src/share/classes/java/util/concurrent/ScheduledExecutorService.java
! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java
! src/share/classes/java/util/concurrent/Semaphore.java
! src/share/classes/java/util/concurrent/SynchronousQueue.java
! src/share/classes/java/util/concurrent/ThreadFactory.java
! src/share/classes/java/util/concurrent/TimeUnit.java
! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java
! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicLong.java
! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicReference.java
! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java
! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/package-info.java
! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java
! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java
! src/share/classes/java/util/concurrent/locks/Condition.java
! src/share/classes/java/util/concurrent/locks/Lock.java
! src/share/classes/java/util/concurrent/locks/LockSupport.java
! src/share/classes/java/util/concurrent/locks/ReentrantLock.java
! src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
! src/share/classes/java/util/concurrent/package-info.java

Changeset: 615af31cfccc
Author:    alanb
Date:      2012-10-27 09:18 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/615af31cfccc

7176225: Remove JDBC-ODBC Bridge
Reviewed-by: lancea, ohair, tbell

! make/common/Sanity.gmk
! make/common/shared/Defs-solaris.gmk
! make/common/shared/Sanity.gmk
! make/sun/Makefile
- make/sun/jdbc/Makefile
! makefiles/CompileNativeLibraries.gmk
! makefiles/CopyIntoClasses.gmk
! makefiles/CreateJars.gmk
! makefiles/GensrcMisc.gmk

Changeset: 33e29fbc3e5b
Author:    weijun
Date:      2012-10-29 14:14 +0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/33e29fbc3e5b

7184246: Simplify Config.get() of krb5
Reviewed-by: xuelei

! src/share/classes/sun/security/krb5/Checksum.java
! src/share/classes/sun/security/krb5/Config.java
! src/share/classes/sun/security/krb5/KdcComm.java
! src/share/classes/sun/security/krb5/PrincipalName.java
! src/share/classes/sun/security/krb5/Realm.java
! src/share/classes/sun/security/krb5/SCDynamicStoreConfig.java
! src/share/classes/sun/security/krb5/internal/KDCOptions.java
! src/share/classes/sun/security/krb5/internal/KerberosTime.java
! src/share/classes/sun/security/krb5/internal/crypto/CksumType.java
! src/share/classes/sun/security/krb5/internal/crypto/EType.java
! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java
! test/sun/security/krb5/ConfPlusProp.java
! test/sun/security/krb5/DnsFallback.java
! test/sun/security/krb5/ParseConfig.java
! test/sun/security/krb5/auto/BasicKrb5Test.java
! test/sun/security/krb5/auto/MaxRetries.java
+ test/sun/security/krb5/config/Duplicates.java
+ test/sun/security/krb5/config/SCDynamicConfigTest.java
+ test/sun/security/krb5/config/k1.conf

Changeset: cb70077c6370
Author:    weijun
Date:      2012-10-29 14:14 +0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/cb70077c6370

7195426: kdc_default_options not supported correctly
Reviewed-by: xuelei

! src/share/classes/sun/security/krb5/internal/KDCOptions.java
+ test/sun/security/krb5/config/KdcDefaultOptions.java
+ test/sun/security/krb5/config/kdc_default_options.conf

Changeset: d1ffbdf7e3c6
Author:    sla
Date:      2012-10-29 09:23 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/d1ffbdf7e3c6

8001621: Update awk scripts that check output from jps/jcmd
Reviewed-by: alanb

! test/sun/tools/jcmd/jcmd_Output1.awk
! test/sun/tools/jps/jps-l_Output1.awk
! test/sun/tools/jps/jps_Output1.awk

Changeset: 17384fc6b31f
Author:    ohrstrom
Date:      2012-10-29 14:12 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/17384fc6b31f

8000970: break out auxiliary classes that will prevent multi-core compilation of the JDK
Reviewed-by: alanb, wetmore

+ make/tools/src/build/tools/generatenimbus/AbstractGradient.java
+ make/tools/src/build/tools/generatenimbus/Border.java
+ make/tools/src/build/tools/generatenimbus/Canvas.java
+ make/tools/src/build/tools/generatenimbus/ComponentColor.java
+ make/tools/src/build/tools/generatenimbus/Dimension.java
+ make/tools/src/build/tools/generatenimbus/Ellipse.java
+ make/tools/src/build/tools/generatenimbus/Gradient.java
+ make/tools/src/build/tools/generatenimbus/GradientStop.java
+ make/tools/src/build/tools/generatenimbus/Insets.java
+ make/tools/src/build/tools/generatenimbus/Layer.java
+ make/tools/src/build/tools/generatenimbus/Matte.java
! make/tools/src/build/tools/generatenimbus/Paint.java
+ make/tools/src/build/tools/generatenimbus/Path.java
+ make/tools/src/build/tools/generatenimbus/Point.java
+ make/tools/src/build/tools/generatenimbus/RadialGradient.java
+ make/tools/src/build/tools/generatenimbus/Rectangle.java
! make/tools/src/build/tools/generatenimbus/Shape.java
! make/tools/src/build/tools/generatenimbus/SynthModel.java
+ make/tools/src/build/tools/generatenimbus/Typeface.java
+ make/tools/src/build/tools/generatenimbus/UIColor.java
+ make/tools/src/build/tools/generatenimbus/UIComponent.java
! make/tools/src/build/tools/generatenimbus/UIDefault.java
+ make/tools/src/build/tools/generatenimbus/UIFont.java
+ make/tools/src/build/tools/generatenimbus/UIIconRegion.java
+ make/tools/src/build/tools/generatenimbus/UIProperty.java
+ make/tools/src/build/tools/generatenimbus/UIRegion.java
+ make/tools/src/build/tools/generatenimbus/UIState.java
+ make/tools/src/build/tools/generatenimbus/UIStateType.java
! make/tools/src/build/tools/generatenimbus/UIStyle.java
! src/share/classes/javax/management/timer/Timer.java
+ src/share/classes/javax/management/timer/TimerAlarmClock.java
+ src/share/classes/sun/awt/im/ExecutableInputMethodManager.java
! src/share/classes/sun/awt/im/InputMethodManager.java
+ src/share/classes/sun/misc/FDBigInt.java
! src/share/classes/sun/misc/FloatingDecimal.java
! src/share/classes/sun/net/httpserver/Event.java
+ src/share/classes/sun/net/httpserver/WriteFinishedEvent.java
+ src/share/classes/sun/net/www/http/KeepAliveCleanerEntry.java
! src/share/classes/sun/net/www/http/KeepAliveStream.java
+ src/share/classes/sun/security/ssl/ExtensionType.java
+ src/share/classes/sun/security/ssl/HelloExtension.java
! src/share/classes/sun/security/ssl/HelloExtensions.java
+ src/share/classes/sun/security/ssl/RenegotiationInfoExtension.java
+ src/share/classes/sun/security/ssl/ServerNameExtension.java
+ src/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java
+ src/share/classes/sun/security/ssl/SupportedEllipticCurvesExtension.java
+ src/share/classes/sun/security/ssl/SupportedEllipticPointFormatsExtension.java
+ src/share/classes/sun/security/ssl/UnknownExtension.java
! src/solaris/classes/sun/awt/X11/XChoicePeer.java
+ src/solaris/classes/sun/awt/X11/XChoicePeerListener.java
+ src/solaris/classes/sun/font/DelegateStrike.java
! src/solaris/classes/sun/font/NativeStrike.java
! src/solaris/classes/sun/java2d/jules/JulesAATileGenerator.java
+ src/solaris/classes/sun/java2d/jules/TileTrapContainer.java

Changeset: 7fa45c455034
Author:    naoto
Date:      2012-10-29 10:42 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/7fa45c455034

8000997: Multiple locale sensitive services cannot be loaded
Reviewed-by: okutsu

! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java
! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java
! test/java/util/PluggableLocale/CurrencyNameProviderTest.java
! test/java/util/PluggableLocale/CurrencyNameProviderTest.sh
! test/java/util/PluggableLocale/GenericTest.java
! test/java/util/PluggableLocale/barprovider.jar
+ test/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl2.java
! test/java/util/PluggableLocale/providersrc/Makefile
! test/java/util/PluggableLocale/providersrc/java.util.spi.CurrencyNameProvider

Changeset: e2f976a73afb
Author:    jgish
Date:      2012-10-29 16:51 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/e2f976a73afb

6206780: (str) Forwarding append methods in String{Buffer,Builder} are inconsistent
Summary: update StringBuilder & StringBuffer to consistently handle forwarding to AbstractStringBuilder. Some additional cleanup (removal of refs to sub-classes from AbstractStringBuilder)
Reviewed-by: chegar, alanb, mduigou

! src/share/classes/java/lang/AbstractStringBuilder.java
! src/share/classes/java/lang/StringBuffer.java
! src/share/classes/java/lang/StringBuilder.java
+ test/java/lang/StringBuffer/AppendStringBuilder.java
+ test/java/lang/StringBuffer/BufferForwarding.java
+ test/java/lang/StringBuffer/TestSynchronization.java
+ test/java/lang/StringBuilder/AppendStringBuffer.java
+ test/java/lang/StringBuilder/BuilderForwarding.java

Changeset: ac97b1cfc0ea
Author:    lana
Date:      2012-10-31 08:29 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/ac97b1cfc0ea

Merge

! make/common/shared/Sanity.gmk
! src/share/classes/java/util/concurrent/Executors.java
! src/share/classes/java/util/logging/FileHandler.java
! src/share/classes/java/util/logging/MemoryHandler.java
! src/share/classes/java/util/logging/StreamHandler.java
- src/share/classes/sun/net/www/protocol/gopher/GopherClient.java
- src/share/classes/sun/net/www/protocol/gopher/Handler.java

Changeset: 178618fb4300
Author:    naoto
Date:      2012-10-31 11:33 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/178618fb4300

8001231: Move locale data out of rt.jar (except the US locale)
Reviewed-by: alanb, erikj

! make/java/java/genlocales.gmk
! make/java/java/localegen.sh
! make/java/text/base/FILES_java.gmk
! make/java/util/FILES_java.gmk
! make/java/util/FILES_properties.gmk
! make/sun/text/FILES_java.gmk
! make/sun/text/FILES_properties.gmk
! makefiles/CreateJars.gmk
! makefiles/GensrcLocaleDataMetaInfo.gmk
! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/LocaleDataMetaInfo-XLocales.java.template

Changeset: 8b944ebef8a7
Author:    ohrstrom
Date:      2012-11-01 10:33 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/8b944ebef8a7

8002101: break out auxiliary classes that will prevent multi-core compilation of the JDK
Reviewed-by: alanb, sla

+ src/share/classes/com/sun/jmx/snmp/agent/AcmChecker.java
+ src/share/classes/com/sun/jmx/snmp/agent/LongList.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java

Changeset: 6420fcd61c10
Author:    naoto
Date:      2012-11-01 13:28 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/6420fcd61c10

8001440: CLDR adapter: Invalid number extension in language tag causes exception in NumberFormat.format()
Reviewed-by: okutsu

! src/share/classes/java/text/DecimalFormatSymbols.java
! test/java/util/Locale/LocaleProviders.java
! test/java/util/Locale/LocaleProviders.sh

Changeset: 8748331f63cf
Author:    lancea
Date:      2012-11-01 17:35 -0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/8748331f63cf

8001536: Added readObject,writeObject,clone, equals, hashcode to SerialXLob
Reviewed-by: alanb, forax

! src/share/classes/javax/sql/rowset/serial/SerialBlob.java
! src/share/classes/javax/sql/rowset/serial/SerialClob.java

Changeset: 79774104a1f4
Author:    alanb
Date:      2012-11-01 21:59 +0000
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/79774104a1f4

8002120: ProblemList.txt updates (11/2012)
Reviewed-by: lancea

! test/ProblemList.txt
! test/TEST.ROOT

Changeset: 9b3867244eec
Author:    dholmes
Date:      2012-11-01 18:09 -0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/9b3867244eec

7198815: Add the minimal VM as "known" in jvm.cfg
Reviewed-by: alanb, forax, mchung

! src/solaris/bin/arm/jvm.cfg
! src/solaris/bin/i586/jvm.cfg
! src/solaris/bin/ppc/jvm.cfg
! src/solaris/bin/sparc/jvm.cfg

Changeset: 36f962518499
Author:    weijun
Date:      2012-11-02 10:48 +0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/36f962518499

7110803: SASL service for multiple hostnames
Reviewed-by: mullan

! src/share/classes/com/sun/security/ntlm/Server.java
! src/share/classes/com/sun/security/sasl/CramMD5Server.java
! src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java
! src/share/classes/com/sun/security/sasl/digest/DigestMD5Server.java
! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java
! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java
! src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java
! src/share/classes/javax/security/sasl/Sasl.java
! src/share/classes/javax/security/sasl/SaslServerFactory.java
+ test/com/sun/security/sasl/digest/Unbound.java
+ test/sun/security/krb5/auto/SaslBasic.java

Changeset: 98a47dc23296
Author:    peytoia
Date:      2012-11-02 23:17 +0900
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/98a47dc23296

8001209: Evaluate findbugs reprot for java.text.ChoiceFormat
Reviewed-by: okutsu

! src/share/classes/java/text/ChoiceFormat.java
+ test/java/text/Format/ChoiceFormat/Bug8001209.java

Changeset: cea72c2bf071
Author:    alanb
Date:      2012-11-02 15:50 +0000
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/cea72c2bf071

7197491: update copyright year to match last edit in jdk8 jdk repository
Reviewed-by: chegar, ksrini

! make/apple/Makefile
! make/apple/applescript/Makefile
! make/com/Makefile
! make/com/apple/Makefile
! make/com/apple/osx/Makefile
! make/com/apple/osxui/Makefile
! make/com/oracle/jfr/Makefile
! make/com/sun/Makefile
! make/com/sun/demo/jvmti/hprof/Makefile
! make/com/sun/java/browser/net/Makefile
! make/com/sun/java/pack/Makefile
! make/com/sun/net/ssl/Makefile
! make/com/sun/nio/Makefile
! make/com/sun/nio/sctp/Exportedfiles.gmk
! make/com/sun/nio/sctp/FILES_java.gmk
! make/com/sun/nio/sctp/Makefile
! make/com/sun/nio/sctp/mapfile-vers
! make/com/sun/security/auth/module/Makefile
! make/com/sun/tools/Makefile
! make/com/sun/tools/attach/Exportedfiles.gmk
! make/com/sun/tools/attach/FILES_c.gmk
! make/com/sun/tools/attach/FILES_java.gmk
! make/com/sun/tools/attach/mapfile-bsd
! make/com/sun/tracing/Makefile
! make/com/sun/tracing/dtrace/Makefile
! make/common/Demo.gmk
! make/common/Mapfile-vers.gmk
! make/common/Release-macosx.gmk
! make/common/Rules.gmk
! make/common/Sanity.gmk
! make/common/internal/Defs-jaxws.gmk
! make/common/internal/NativeCompileRules.gmk
! make/common/internal/Resources.gmk
! make/common/shared/Compiler-gcc.gmk
! make/common/shared/Compiler-llvm.gmk
! make/common/shared/Compiler-sun.gmk
! make/common/shared/Defs-linux.gmk
! make/common/shared/Defs-macosx.gmk
! make/common/shared/Defs-solaris.gmk
! make/common/shared/Defs-utils.gmk
! make/common/shared/Defs-versions.gmk
! make/common/shared/Defs-windows.gmk
! make/common/shared/Defs.gmk
! make/common/shared/Sanity-Settings.gmk
! make/docs/CORE_PKGS.gmk
! make/java/Makefile
! make/java/awt/Makefile
! make/java/fdlibm/FILES_c.gmk
! make/java/java/genlocales.gmk
! make/java/java/reflect/Makefile
! make/java/jobjc/Makefile
! make/java/jvm/Makefile
! make/java/management/mapfile-vers
! make/java/net/FILES_c.gmk
! make/java/net/Makefile
! make/java/nio/FILES_java.gmk
! make/java/nio/Makefile
! make/java/nio/mapfile-bsd
! make/java/nio/mapfile-linux
! make/java/nio/mapfile-solaris
! make/java/rmi/Makefile
! make/java/security/Makefile
! make/java/sun_nio/FILES_java.gmk
! make/java/text/bidi/Makefile
! make/java/zip/FILES_c.gmk
! make/java/zip/Makefile
! make/java/zip/mapfile-vers
! make/javax/accessibility/Makefile
! make/javax/crypto/Makefile
! make/javax/sound/FILES_c.gmk
! make/javax/sound/SoundDefs.gmk
! make/javax/sound/jsoundalsa/Makefile
! make/jdk_generic_profile.sh
! make/jpda/back/Makefile
! make/jpda/jdwp/jdwp.spec
! make/jprt.properties
! make/mksample/Makefile
! make/netbeans/common/architectures/name-Bsd.properties
! make/netbeans/common/closed-share-view.ent
! make/netbeans/common/jtreg-view.ent
! make/netbeans/common/sample-view.ent
! make/netbeans/common/share-view.ent
! make/netbeans/common/unix-view.ent
! make/netbeans/common/windows-view.ent
! make/netbeans/jconsole/build.xml
! make/org/ietf/jgss/Makefile
! make/sun/Makefile
! make/sun/awt/FILES_c_macosx.gmk
! make/sun/awt/FILES_c_unix.gmk
! make/sun/awt/FILES_export_macosx.gmk
! make/sun/awt/FILES_export_unix.gmk
! make/sun/awt/mapfile-vers-bsd
! make/sun/awt/mawt.gmk
! make/sun/cmm/lcms/Makefile
! make/sun/font/Makefile
! make/sun/font/t2k/Makefile
! make/sun/headless/Makefile
! make/sun/image/generic/Makefile
! make/sun/image/vis/Makefile
! make/sun/jawt/Makefile
! make/sun/jconsole/FILES.gmk
! make/sun/jconsole/Makefile
! make/sun/jdga/Makefile
! make/sun/lwawt/FILES_c_macosx.gmk
! make/sun/lwawt/FILES_export_macosx.gmk
! make/sun/lwawt/Makefile
! make/sun/net/FILES_java.gmk
! make/sun/net/spi/Makefile
! make/sun/nio/cs/FILES_java.gmk
! make/sun/osxapp/Makefile
! make/sun/rmi/cgi/Makefile
! make/sun/rmi/registry/Makefile
! make/sun/rmi/rmi/Makefile
! make/sun/rmi/rmi/mapfile-vers
! make/sun/rmi/rmid/Makefile
! make/sun/security/jgss/wrapper/Makefile
! make/sun/security/krb5/Makefile
! make/sun/security/other/Makefile
! make/sun/security/smartcardio/Makefile
! make/sun/splashscreen/FILES_c.gmk
! make/sun/splashscreen/Makefile
! make/sun/tools/Makefile
! make/sun/util/Makefile
! make/tools/CharsetMapping/DoubleByte-X.java.template
! make/tools/CharsetMapping/SingleByte-X.java.template
! make/tools/GenerateCharacter/CharacterData01.java.template
! make/tools/GenerateCharacter/CharacterData02.java.template
! make/tools/GenerateCharacter/CharacterData0E.java.template
! make/tools/GenerateCharacter/CharacterDataLatin1.java.template
! make/tools/freetypecheck/Makefile
! make/tools/reorder/Makefile
! make/tools/src/build/tools/charsetmapping/DBCS.java
! make/tools/src/build/tools/charsetmapping/SBCS.java
! make/tools/src/build/tools/compileproperties/CompileProperties.java
! make/tools/src/build/tools/generatenimbus/AbstractGradient.java
! make/tools/src/build/tools/generatenimbus/Border.java
! make/tools/src/build/tools/generatenimbus/Canvas.java
! make/tools/src/build/tools/generatenimbus/ComponentColor.java
! make/tools/src/build/tools/generatenimbus/Dimension.java
! make/tools/src/build/tools/generatenimbus/Ellipse.java
! make/tools/src/build/tools/generatenimbus/Gradient.java
! make/tools/src/build/tools/generatenimbus/GradientStop.java
! make/tools/src/build/tools/generatenimbus/Insets.java
! make/tools/src/build/tools/generatenimbus/Layer.java
! make/tools/src/build/tools/generatenimbus/Matte.java
! make/tools/src/build/tools/generatenimbus/Paint.java
! make/tools/src/build/tools/generatenimbus/Path.java
! make/tools/src/build/tools/generatenimbus/Point.java
! make/tools/src/build/tools/generatenimbus/RadialGradient.java
! make/tools/src/build/tools/generatenimbus/Rectangle.java
! make/tools/src/build/tools/generatenimbus/Shape.java
! make/tools/src/build/tools/generatenimbus/SynthModel.java
! make/tools/src/build/tools/generatenimbus/Typeface.java
! make/tools/src/build/tools/generatenimbus/UIColor.java
! make/tools/src/build/tools/generatenimbus/UIComponent.java
! make/tools/src/build/tools/generatenimbus/UIDefault.java
! make/tools/src/build/tools/generatenimbus/UIFont.java
! make/tools/src/build/tools/generatenimbus/UIIconRegion.java
! make/tools/src/build/tools/generatenimbus/UIProperty.java
! make/tools/src/build/tools/generatenimbus/UIRegion.java
! make/tools/src/build/tools/generatenimbus/UIState.java
! make/tools/src/build/tools/generatenimbus/UIStateType.java
! make/tools/src/build/tools/generatenimbus/UIStyle.java
! make/tools/src/build/tools/jdwpgen/ArrayRegionTypeNode.java
! make/tools/src/build/tools/stripproperties/StripProperties.java
! makefiles/GendataBreakIterator.gmk
! makefiles/GendataTimeZone.gmk
! makefiles/GensrcSwing.gmk
! makefiles/docs/CORE_PKGS.gmk
! makefiles/jpda/jdwp/jdwp.spec
! makefiles/jprt.gmk
! makefiles/jprt.properties
! makefiles/mapfiles/launchers/mapfile-amd64
! makefiles/mapfiles/launchers/mapfile-i586
! makefiles/mapfiles/launchers/mapfile-sparc
! makefiles/mapfiles/launchers/mapfile-sparcv9
! makefiles/mapfiles/launchers/mapfile-x86
! makefiles/mapfiles/launchers/mapfile-x86_64
! makefiles/mapfiles/libattach/mapfile-linux
! makefiles/mapfiles/libattach/mapfile-solaris
! makefiles/mapfiles/libawt/mapfile-mawt-vers
! makefiles/mapfiles/libawt/mapfile-vers
! makefiles/mapfiles/libawt/mapfile-vers-linux
! makefiles/mapfiles/libawt_headless/mapfile-vers
! makefiles/mapfiles/libawt_xawt/mapfile-vers
! makefiles/mapfiles/libdcpr/mapfile-vers
! makefiles/mapfiles/libdt_socket/mapfile-vers
! makefiles/mapfiles/libfontmanager/mapfile-vers
! makefiles/mapfiles/libfontmanager/mapfile-vers.openjdk
! makefiles/mapfiles/libhprof/mapfile-vers
! makefiles/mapfiles/libinstrument/mapfile-vers
! makefiles/mapfiles/libj2gss/mapfile-vers
! makefiles/mapfiles/libj2pcsc/mapfile-vers
! makefiles/mapfiles/libjaas/mapfile-vers
! makefiles/mapfiles/libjava_crw_demo/mapfile-vers
! makefiles/mapfiles/libjawt/mapfile-vers
! makefiles/mapfiles/libjdga/mapfile-vers
! makefiles/mapfiles/libjdwp/mapfile-vers
! makefiles/mapfiles/libjli/mapfile-vers
! makefiles/mapfiles/libjpeg/mapfile-vers
! makefiles/mapfiles/libjpeg/mapfile-vers-closed
! makefiles/mapfiles/libjsdt/mapfile-vers
! makefiles/mapfiles/libjsound/mapfile-vers
! makefiles/mapfiles/libjsoundalsa/mapfile-vers
! makefiles/mapfiles/libkcms/mapfile-vers
! makefiles/mapfiles/liblcms/mapfile-vers
! makefiles/mapfiles/libmanagement/mapfile-vers
! makefiles/mapfiles/libmlib_image/mapfile-vers
! makefiles/mapfiles/libnet/mapfile-vers
! makefiles/mapfiles/libnio/mapfile-bsd
! makefiles/mapfiles/libnio/mapfile-linux
! makefiles/mapfiles/libnio/mapfile-macosx
! makefiles/mapfiles/libnio/mapfile-solaris
! makefiles/mapfiles/libnpt/mapfile-vers
! makefiles/mapfiles/libsctp/mapfile-vers
! makefiles/mapfiles/libsplashscreen/mapfile-vers
! makefiles/mapfiles/libsunec/mapfile-vers
! makefiles/mapfiles/libt2k/mapfile-vers
! makefiles/mapfiles/libunpack/mapfile-vers
! makefiles/mapfiles/libunpack/mapfile-vers-unpack200
! makefiles/mapfiles/libverify/mapfile-vers
! makefiles/mapfiles/libzip/mapfile-vers
! makefiles/scripts/addNotices.sh
! makefiles/scripts/genCharsetProvider.sh
! makefiles/scripts/genExceptions.sh
! makefiles/scripts/localelist.sh
! makefiles/sun/xawt/ToBin.java
! src/bsd/doc/man/appletviewer.1
! src/bsd/doc/man/apt.1
! src/bsd/doc/man/extcheck.1
! src/bsd/doc/man/idlj.1
! src/bsd/doc/man/ja/appletviewer.1
! src/bsd/doc/man/ja/apt.1
! src/bsd/doc/man/ja/extcheck.1
! src/bsd/doc/man/ja/idlj.1
! src/bsd/doc/man/ja/jar.1
! src/bsd/doc/man/ja/jarsigner.1
! src/bsd/doc/man/ja/java.1
! src/bsd/doc/man/ja/javac.1
! src/bsd/doc/man/ja/javadoc.1
! src/bsd/doc/man/ja/javah.1
! src/bsd/doc/man/ja/javap.1
! src/bsd/doc/man/ja/javaws.1
! src/bsd/doc/man/ja/jconsole.1
! src/bsd/doc/man/ja/jdb.1
! src/bsd/doc/man/ja/jhat.1
! src/bsd/doc/man/ja/jinfo.1
! src/bsd/doc/man/ja/jmap.1
! src/bsd/doc/man/ja/jps.1
! src/bsd/doc/man/ja/jrunscript.1
! src/bsd/doc/man/ja/jsadebugd.1
! src/bsd/doc/man/ja/jstack.1
! src/bsd/doc/man/ja/jstat.1
! src/bsd/doc/man/ja/jstatd.1
! src/bsd/doc/man/ja/keytool.1
! src/bsd/doc/man/ja/native2ascii.1
! src/bsd/doc/man/ja/orbd.1
! src/bsd/doc/man/ja/pack200.1
! src/bsd/doc/man/ja/policytool.1
! src/bsd/doc/man/ja/rmic.1
! src/bsd/doc/man/ja/rmid.1
! src/bsd/doc/man/ja/rmiregistry.1
! src/bsd/doc/man/ja/schemagen.1
! src/bsd/doc/man/ja/serialver.1
! src/bsd/doc/man/ja/servertool.1
! src/bsd/doc/man/ja/tnameserv.1
! src/bsd/doc/man/ja/unpack200.1
! src/bsd/doc/man/ja/wsgen.1
! src/bsd/doc/man/ja/wsimport.1
! src/bsd/doc/man/ja/xjc.1
! src/bsd/doc/man/jar.1
! src/bsd/doc/man/java.1
! src/bsd/doc/man/javac.1
! src/bsd/doc/man/javah.1
! src/bsd/doc/man/javap.1
! src/bsd/doc/man/javaws.1
! src/bsd/doc/man/jconsole.1
! src/bsd/doc/man/jdb.1
! src/bsd/doc/man/jhat.1
! src/bsd/doc/man/jinfo.1
! src/bsd/doc/man/jmap.1
! src/bsd/doc/man/jps.1
! src/bsd/doc/man/jrunscript.1
! src/bsd/doc/man/jsadebugd.1
! src/bsd/doc/man/jstack.1
! src/bsd/doc/man/jstatd.1
! src/bsd/doc/man/native2ascii.1
! src/bsd/doc/man/orbd.1
! src/bsd/doc/man/pack200.1
! src/bsd/doc/man/policytool.1
! src/bsd/doc/man/rmic.1
! src/bsd/doc/man/rmid.1
! src/bsd/doc/man/rmiregistry.1
! src/bsd/doc/man/schemagen.1
! src/bsd/doc/man/serialver.1
! src/bsd/doc/man/servertool.1
! src/bsd/doc/man/tnameserv.1
! src/bsd/doc/man/unpack200.1
! src/bsd/doc/man/xjc.1
! src/linux/doc/man/jcmd.1
! src/macosx/bundle/JavaAppLauncher/src/JVMArgs.h
! src/macosx/bundle/JavaAppLauncher/src/JVMArgs.m
! src/macosx/bundle/JavaAppLauncher/src/JavaAppLauncher.h
! src/macosx/bundle/JavaAppLauncher/src/JavaAppLauncher.m
! src/macosx/bundle/JavaAppLauncher/src/JavaAppLauncher_Prefix.pch
! src/macosx/bundle/JavaAppLauncher/src/main.m
! src/macosx/classes/apple/applescript/AppleScriptEngineFactory.java
! src/macosx/classes/apple/launcher/JavaAppLauncher.java
! src/macosx/classes/apple/security/AppleProvider.java
! src/macosx/classes/apple/security/KeychainStore.java
! src/macosx/classes/com/apple/concurrent/Dispatch.java
! src/macosx/classes/com/apple/concurrent/LibDispatchConcurrentQueue.java
! src/macosx/classes/com/apple/concurrent/LibDispatchMainQueue.java
! src/macosx/classes/com/apple/concurrent/LibDispatchNative.java
! src/macosx/classes/com/apple/concurrent/LibDispatchQueue.java
! src/macosx/classes/com/apple/concurrent/LibDispatchRetainedResource.java
! src/macosx/classes/com/apple/concurrent/LibDispatchSerialQueue.java
! src/macosx/classes/com/apple/eio/FileManager.java
! src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java
! src/macosx/classes/java/net/DefaultInterface.java
! src/macosx/classes/java/util/prefs/MacOSXPreferences.java
! src/macosx/classes/java/util/prefs/MacOSXPreferencesFactory.java
! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java
! src/macosx/classes/sun/nio/ch/DefaultSelectorProvider.java
! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java
! src/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java
! src/macosx/classes/sun/nio/ch/KQueueSelectorProvider.java
! src/macosx/native/apple/applescript/AS_NS_ConversionUtils.h
! src/macosx/native/apple/applescript/AS_NS_ConversionUtils.m
! src/macosx/native/apple/applescript/AppleScriptEngine.m
! src/macosx/native/apple/applescript/AppleScriptExecutionContext.h
! src/macosx/native/apple/applescript/AppleScriptExecutionContext.m
! src/macosx/native/apple/applescript/NS_Java_ConversionUtils.h
! src/macosx/native/apple/applescript/NS_Java_ConversionUtils.m
! src/macosx/native/apple/launcher/JavaAppLauncher.m
! src/macosx/native/com/apple/concurrent/Dispatch.m
! src/macosx/native/com/apple/eio/CFileManager.m
! src/macosx/native/com/apple/resources/MacOSXResourceBundle.m
! src/macosx/native/java/util/MacOSXPreferencesFile.m
! src/macosx/native/java/util/SCDynamicStoreConfig.m
! src/macosx/native/jobjc/JObjC.xcodeproj/default.pbxuser
! src/macosx/native/jobjc/README.txt
! src/macosx/native/jobjc/TODOS
! src/macosx/native/jobjc/bridgesupport.gmk
! src/macosx/native/jobjc/build.xml
! src/macosx/native/jobjc/extract_classes.pl
! src/macosx/native/jobjc/run-and-write-if-okay
! src/macosx/native/jobjc/rungen
! src/macosx/native/jobjc/runjava
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/CFType.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/CIF.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/FFIType.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Function.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/ID.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Invoke.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/MacOSXFramework.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NSClass.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeArgumentBuffer.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeBuffer.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeObjectLifecycleManager.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Opaque.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Pointer.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/SEL.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Struct.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Subclassing.java
! src/macosx/native/jobjc/src/core/native/CIF.m
! src/macosx/native/jobjc/src/core/native/Coder.m
! src/macosx/native/jobjc/src/core/native/FFIType.m
! src/macosx/native/jobjc/src/core/native/Function.m
! src/macosx/native/jobjc/src/core/native/ID.m
! src/macosx/native/jobjc/src/core/native/Invoke.m
! src/macosx/native/jobjc/src/core/native/JObjCRuntime.m
! src/macosx/native/jobjc/src/core/native/MacOSXFramework.m
! src/macosx/native/jobjc/src/core/native/NSClass.m
! src/macosx/native/jobjc/src/core/native/NativeBuffer.h
! src/macosx/native/jobjc/src/core/native/NativeBuffer.m
! src/macosx/native/jobjc/src/core/native/NativeObjectLifecycleManager.m
! src/macosx/native/jobjc/src/core/native/SEL.m
! src/macosx/native/jobjc/src/core/native/Subclassing.m
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/BootClassPathMinus.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/ClassConsolidator.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/ClassGenerator.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/FileCopier.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/FrameworkGenerator.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/FunctionGenerator.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/Generator.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/MethodDisambiguator.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/RestrictedKeywords.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/Utils.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/AbstractObjCClassFile.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/CFTypeClassFile.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/CategoryClassClassFile.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/CategoryClassFile.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/CopiedFile.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/FrameworkClassFile.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/GeneratedClassFile.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/JObjCClassClassFile.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/JObjCClassFile.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/MixedPrimitiveCoderClassFile.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/OpaqueClassFile.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/OutputFile.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/RootJObjCClass.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/StructClassFile.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Arg.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/CFType.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Category.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Clazz.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Constant.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Element.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/ElementWType.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Framework.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Function.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/FunctionAlias.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/InformalProtocol.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Method.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/NativeEnum.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Opaque.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/OutputFileGenerator.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Protocol.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/ReturnValue.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/StringConstant.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Struct.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/TypeElement.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/coders/CoderDescriptor.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/coders/ComplexCoderDescriptor.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/coders/PrimitiveCoderDescriptor.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/JType.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/NType.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/Type.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/TypeCache.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/TypeToJType.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/Fp.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/JavaLang.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/NTypeMerger.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/NTypeParser.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/NTypePrinter.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/ObjectInspector.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/QA.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/StringStream.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/StructOffsetResolver.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/StructOffsetResolverBigBang.java
! src/macosx/native/jobjc/src/generator/java/com/apple/jobjc/SuperClassExtractor.java
! src/macosx/native/jobjc/src/generator/java/com/apple/jobjc/UnsafeRuntimeAccess.java
! src/macosx/native/jobjc/src/runtime-additions/java/com/apple/jobjc/Utils.java
! src/macosx/native/jobjc/src/runtime-additions/native/NativeNumber.m
! src/macosx/native/jobjc/src/runtime-additions/native/NativeString.m
! src/macosx/native/jobjc/src/runtime-additions/native/NativeThread.m
! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BaseBench.java
! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BenchFunCall.java
! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BenchIDPop.java
! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BenchStructCoding.java
! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BenchUnsafe.java
! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/CategoryTest.java
! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/FunctionTest.java
! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/GUIDemo.java
! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/IBDemo.java
! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/IntroTest.java
! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/NSClassTest.java
! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/NativeBufferTest.java
! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/NativeTypeTest.java
! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/PooledTestCase.java
! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/SELTest.java
! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/StructTest.java
! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/SubclassingTest.java
! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/TestUtils.java
! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/UtilsTest.java
! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/VarArgsTest.java
! src/macosx/native/jobjc/src/tests/native/FunCallBench.m
! src/macosx/native/sun/nio/ch/KQueueArrayWrapper.c
! src/macosx/native/sun/osxapp/AWT_debug.h
! src/macosx/native/sun/osxapp/NSApplicationAWT.h
! src/macosx/native/sun/osxapp/NSApplicationAWT.m
! src/macosx/native/sun/osxapp/PropertiesUtilities.h
! src/macosx/native/sun/osxapp/PropertiesUtilities.m
! src/macosx/native/sun/osxapp/QueuingApplicationDelegate.h
! src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m
! src/macosx/native/sun/osxapp/ThreadUtilities.h
! src/macosx/native/sun/osxapp/ThreadUtilities.m
! src/share/back/commonRef.c
! src/share/back/error_messages.h
! src/share/back/log_messages.h
! src/share/bin/emessages.h
! src/share/classes/com/sun/crypto/provider/PBEKey.java
! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java
! src/share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java
! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java
! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java
! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java
! src/share/classes/com/sun/java/util/jar/pack/package.html
! src/share/classes/com/sun/jdi/AbsentInformationException.java
! src/share/classes/com/sun/jdi/Accessible.java
! src/share/classes/com/sun/jdi/ArrayType.java
! src/share/classes/com/sun/jdi/ClassLoaderReference.java
! src/share/classes/com/sun/jdi/ClassNotLoadedException.java
! src/share/classes/com/sun/jdi/ClassNotPreparedException.java
! src/share/classes/com/sun/jdi/ClassType.java
! src/share/classes/com/sun/jdi/IncompatibleThreadStateException.java
! src/share/classes/com/sun/jdi/InconsistentDebugInfoException.java
! src/share/classes/com/sun/jdi/InternalException.java
! src/share/classes/com/sun/jdi/InvalidCodeIndexException.java
! src/share/classes/com/sun/jdi/InvalidLineNumberException.java
! src/share/classes/com/sun/jdi/InvalidStackFrameException.java
! src/share/classes/com/sun/jdi/InvalidTypeException.java
! src/share/classes/com/sun/jdi/InvocationException.java
! src/share/classes/com/sun/jdi/JDIPermission.java
! src/share/classes/com/sun/jdi/LocalVariable.java
! src/share/classes/com/sun/jdi/Method.java
! src/share/classes/com/sun/jdi/NativeMethodException.java
! src/share/classes/com/sun/jdi/ObjectCollectedException.java
! src/share/classes/com/sun/jdi/ObjectReference.java
! src/share/classes/com/sun/jdi/ReferenceType.java
! src/share/classes/com/sun/jdi/TypeComponent.java
! src/share/classes/com/sun/jdi/VMCannotBeModifiedException.java
! src/share/classes/com/sun/jdi/VMDisconnectedException.java
! src/share/classes/com/sun/jdi/VMMismatchException.java
! src/share/classes/com/sun/jdi/VMOutOfMemoryException.java
! src/share/classes/com/sun/jdi/connect/IllegalConnectorArgumentsException.java
! src/share/classes/com/sun/jdi/connect/TransportTimeoutException.java
! src/share/classes/com/sun/jdi/connect/VMStartException.java
! src/share/classes/com/sun/jdi/connect/spi/ClosedConnectionException.java
! src/share/classes/com/sun/jdi/request/DuplicateRequestException.java
! src/share/classes/com/sun/jdi/request/InvalidRequestStateException.java
! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java
! src/share/classes/com/sun/jmx/mbeanserver/MXBeanMapping.java
! src/share/classes/com/sun/jmx/remote/internal/IIOPHelper.java
! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java
! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java
! src/share/classes/com/sun/jmx/snmp/SnmpCounter64.java
! src/share/classes/com/sun/jmx/snmp/SnmpInt.java
! src/share/classes/com/sun/jmx/snmp/SnmpNull.java
! src/share/classes/com/sun/jmx/snmp/SnmpString.java
! src/share/classes/com/sun/jmx/snmp/agent/AcmChecker.java
! src/share/classes/com/sun/jmx/snmp/agent/LongList.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java
! src/share/classes/com/sun/jndi/toolkit/url/UrlUtil.java
! src/share/classes/com/sun/management/OperatingSystemMXBean.java
! src/share/classes/com/sun/management/VMOption.java
! src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java
! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/DelegateHttpsURLConnection.java
! src/share/classes/com/sun/nio/sctp/MessageInfo.java
! src/share/classes/com/sun/nio/sctp/SctpChannel.java
! src/share/classes/com/sun/nio/sctp/SctpMultiChannel.java
! src/share/classes/com/sun/nio/sctp/SctpServerChannel.java
! src/share/classes/com/sun/nio/sctp/SctpSocketOption.java
! src/share/classes/com/sun/nio/sctp/SctpStandardSocketOptions.java
! src/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java
! src/share/classes/com/sun/rmi/rmid/ExecPermission.java
! src/share/classes/com/sun/rowset/JdbcRowSetResourceBundle.java
! src/share/classes/com/sun/rowset/JoinRowSetImpl.java
! src/share/classes/com/sun/rowset/internal/CachedRowSetReader.java
! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java
! src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java
! src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java
! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java
! src/share/classes/com/sun/security/ntlm/Client.java
! src/share/classes/com/sun/security/ntlm/NTLM.java
! src/share/classes/com/sun/security/ntlm/Server.java
! src/share/classes/com/sun/security/sasl/CramMD5Server.java
! src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java
! src/share/classes/com/sun/security/sasl/digest/DigestMD5Server.java
! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java
! src/share/classes/com/sun/security/sasl/ntlm/FactoryImpl.java
! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java
! src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java
! src/share/classes/com/sun/servicetag/BrowserSupport.java
! src/share/classes/com/sun/servicetag/Installer.java
! src/share/classes/com/sun/servicetag/RegistrationDocument.java
! src/share/classes/com/sun/servicetag/SunConnection.java
! src/share/classes/com/sun/tools/example/debug/bdi/AccessWatchpointSpec.java
! src/share/classes/com/sun/tools/example/debug/bdi/AmbiguousMethodException.java
! src/share/classes/com/sun/tools/example/debug/bdi/BreakpointSpec.java
! src/share/classes/com/sun/tools/example/debug/bdi/ChildSession.java
! src/share/classes/com/sun/tools/example/debug/bdi/EvaluationException.java
! src/share/classes/com/sun/tools/example/debug/bdi/EventRequestSpec.java
! src/share/classes/com/sun/tools/example/debug/bdi/EventRequestSpecList.java
! src/share/classes/com/sun/tools/example/debug/bdi/ExceptionSpec.java
! src/share/classes/com/sun/tools/example/debug/bdi/ExecutionManager.java
! src/share/classes/com/sun/tools/example/debug/bdi/FrameIndexOutOfBoundsException.java
! src/share/classes/com/sun/tools/example/debug/bdi/InputListener.java
! src/share/classes/com/sun/tools/example/debug/bdi/JDIEventSource.java
! src/share/classes/com/sun/tools/example/debug/bdi/LineBreakpointSpec.java
! src/share/classes/com/sun/tools/example/debug/bdi/LineNotFoundException.java
! src/share/classes/com/sun/tools/example/debug/bdi/MalformedMemberNameException.java
! src/share/classes/com/sun/tools/example/debug/bdi/MethodBreakpointSpec.java
! src/share/classes/com/sun/tools/example/debug/bdi/MethodNotFoundException.java
! src/share/classes/com/sun/tools/example/debug/bdi/ModificationWatchpointSpec.java
! src/share/classes/com/sun/tools/example/debug/bdi/NoSessionException.java
! src/share/classes/com/sun/tools/example/debug/bdi/NoThreadException.java
! src/share/classes/com/sun/tools/example/debug/bdi/OutputListener.java
! src/share/classes/com/sun/tools/example/debug/bdi/ParseException.java
! src/share/classes/com/sun/tools/example/debug/bdi/PatternReferenceTypeSpec.java
! src/share/classes/com/sun/tools/example/debug/bdi/ReferenceTypeSpec.java
! src/share/classes/com/sun/tools/example/debug/bdi/Session.java
! src/share/classes/com/sun/tools/example/debug/bdi/SessionListener.java
! src/share/classes/com/sun/tools/example/debug/bdi/SourceNameReferenceTypeSpec.java
! src/share/classes/com/sun/tools/example/debug/bdi/SpecErrorEvent.java
! src/share/classes/com/sun/tools/example/debug/bdi/SpecEvent.java
! src/share/classes/com/sun/tools/example/debug/bdi/SpecListener.java
! src/share/classes/com/sun/tools/example/debug/bdi/ThreadGroupIterator.java
! src/share/classes/com/sun/tools/example/debug/bdi/ThreadInfo.java
! src/share/classes/com/sun/tools/example/debug/bdi/ThreadIterator.java
! src/share/classes/com/sun/tools/example/debug/bdi/Utils.java
! src/share/classes/com/sun/tools/example/debug/bdi/VMLaunchFailureException.java
! src/share/classes/com/sun/tools/example/debug/bdi/VMNotInterruptedException.java
! src/share/classes/com/sun/tools/example/debug/bdi/WatchpointSpec.java
! src/share/classes/com/sun/tools/example/debug/event/AbstractEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/AccessWatchpointEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/ClassPrepareEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/ClassUnloadEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/ExceptionEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/JDIAdapter.java
! src/share/classes/com/sun/tools/example/debug/event/JDIListener.java
! src/share/classes/com/sun/tools/example/debug/event/LocatableEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/LocationTriggerEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/ModificationWatchpointEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/ThreadDeathEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/ThreadStartEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/VMDeathEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/VMDisconnectEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/VMStartEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/WatchpointEventSet.java
! src/share/classes/com/sun/tools/example/debug/expr/ASCII_UCodeESC_CharStream.java
! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java
! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParserConstants.java
! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParserTokenManager.java
! src/share/classes/com/sun/tools/example/debug/expr/LValue.java
! src/share/classes/com/sun/tools/example/debug/expr/ParseException.java
! src/share/classes/com/sun/tools/example/debug/expr/Token.java
! src/share/classes/com/sun/tools/example/debug/expr/TokenMgrError.java
! src/share/classes/com/sun/tools/example/debug/gui/ApplicationTool.java
! src/share/classes/com/sun/tools/example/debug/gui/ClassManager.java
! src/share/classes/com/sun/tools/example/debug/gui/ClassTreeTool.java
! src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java
! src/share/classes/com/sun/tools/example/debug/gui/CommandTool.java
! src/share/classes/com/sun/tools/example/debug/gui/ContextListener.java
! src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java
! src/share/classes/com/sun/tools/example/debug/gui/CurrentFrameChangedEvent.java
! src/share/classes/com/sun/tools/example/debug/gui/Environment.java
! src/share/classes/com/sun/tools/example/debug/gui/GUI.java
! src/share/classes/com/sun/tools/example/debug/gui/Icons.java
! src/share/classes/com/sun/tools/example/debug/gui/JDBFileFilter.java
! src/share/classes/com/sun/tools/example/debug/gui/JDBMenuBar.java
! src/share/classes/com/sun/tools/example/debug/gui/JDBToolBar.java
! src/share/classes/com/sun/tools/example/debug/gui/LaunchTool.java
! src/share/classes/com/sun/tools/example/debug/gui/MonitorListModel.java
! src/share/classes/com/sun/tools/example/debug/gui/MonitorTool.java
! src/share/classes/com/sun/tools/example/debug/gui/OutputSink.java
! src/share/classes/com/sun/tools/example/debug/gui/SearchPath.java
! src/share/classes/com/sun/tools/example/debug/gui/SingleLeafTreeSelectionModel.java
! src/share/classes/com/sun/tools/example/debug/gui/SourceListener.java
! src/share/classes/com/sun/tools/example/debug/gui/SourceManager.java
! src/share/classes/com/sun/tools/example/debug/gui/SourceModel.java
! src/share/classes/com/sun/tools/example/debug/gui/SourceTool.java
! src/share/classes/com/sun/tools/example/debug/gui/SourceTreeTool.java
! src/share/classes/com/sun/tools/example/debug/gui/SourcepathChangedEvent.java
! src/share/classes/com/sun/tools/example/debug/gui/StackTraceTool.java
! src/share/classes/com/sun/tools/example/debug/gui/ThreadTreeTool.java
! src/share/classes/com/sun/tools/example/debug/gui/TypeScript.java
! src/share/classes/com/sun/tools/example/debug/gui/TypeScriptOutputListener.java
! src/share/classes/com/sun/tools/example/debug/gui/TypeScriptWriter.java
! src/share/classes/com/sun/tools/example/debug/tty/AccessWatchpointSpec.java
! src/share/classes/com/sun/tools/example/debug/tty/AmbiguousMethodException.java
! src/share/classes/com/sun/tools/example/debug/tty/BreakpointSpec.java
! src/share/classes/com/sun/tools/example/debug/tty/Commands.java
! src/share/classes/com/sun/tools/example/debug/tty/Env.java
! src/share/classes/com/sun/tools/example/debug/tty/EventHandler.java
! src/share/classes/com/sun/tools/example/debug/tty/EventNotifier.java
! src/share/classes/com/sun/tools/example/debug/tty/EventRequestSpec.java
! src/share/classes/com/sun/tools/example/debug/tty/EventRequestSpecList.java
! src/share/classes/com/sun/tools/example/debug/tty/ExceptionSpec.java
! src/share/classes/com/sun/tools/example/debug/tty/LineNotFoundException.java
! src/share/classes/com/sun/tools/example/debug/tty/MalformedMemberNameException.java
! src/share/classes/com/sun/tools/example/debug/tty/MessageOutput.java
! src/share/classes/com/sun/tools/example/debug/tty/ModificationWatchpointSpec.java
! src/share/classes/com/sun/tools/example/debug/tty/PatternReferenceTypeSpec.java
! src/share/classes/com/sun/tools/example/debug/tty/ReferenceTypeSpec.java
! src/share/classes/com/sun/tools/example/debug/tty/SourceMapper.java
! src/share/classes/com/sun/tools/example/debug/tty/TTY.java
! src/share/classes/com/sun/tools/example/debug/tty/TTYResources.java
! src/share/classes/com/sun/tools/example/debug/tty/ThreadGroupIterator.java
! src/share/classes/com/sun/tools/example/debug/tty/ThreadInfo.java
! src/share/classes/com/sun/tools/example/debug/tty/ThreadIterator.java
! src/share/classes/com/sun/tools/example/debug/tty/VMConnection.java
! src/share/classes/com/sun/tools/example/debug/tty/VMNotConnectedException.java
! src/share/classes/com/sun/tools/example/debug/tty/WatchpointSpec.java
! src/share/classes/com/sun/tools/example/trace/EventThread.java
! src/share/classes/com/sun/tools/example/trace/StreamRedirectThread.java
! src/share/classes/com/sun/tools/example/trace/Trace.java
! src/share/classes/com/sun/tools/jdi/ArrayReferenceImpl.java
! src/share/classes/com/sun/tools/jdi/ArrayTypeImpl.java
! src/share/classes/com/sun/tools/jdi/BooleanValueImpl.java
! src/share/classes/com/sun/tools/jdi/CharValueImpl.java
! src/share/classes/com/sun/tools/jdi/ClassLoaderReferenceImpl.java
! src/share/classes/com/sun/tools/jdi/ClassTypeImpl.java
! src/share/classes/com/sun/tools/jdi/ConcreteMethodImpl.java
! src/share/classes/com/sun/tools/jdi/ConnectorImpl.java
! src/share/classes/com/sun/tools/jdi/DoubleValueImpl.java
! src/share/classes/com/sun/tools/jdi/EventRequestManagerImpl.java
! src/share/classes/com/sun/tools/jdi/EventSetImpl.java
! src/share/classes/com/sun/tools/jdi/FloatValueImpl.java
! src/share/classes/com/sun/tools/jdi/GenericAttachingConnector.java
! src/share/classes/com/sun/tools/jdi/IntegerValueImpl.java
! src/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java
! src/share/classes/com/sun/tools/jdi/InternalEventHandler.java
! src/share/classes/com/sun/tools/jdi/JDWPException.java
! src/share/classes/com/sun/tools/jdi/LongValueImpl.java
! src/share/classes/com/sun/tools/jdi/MethodImpl.java
! src/share/classes/com/sun/tools/jdi/MirrorImpl.java
! src/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java
! src/share/classes/com/sun/tools/jdi/ProcessAttachingConnector.java
! src/share/classes/com/sun/tools/jdi/RawCommandLineLauncher.java
! src/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java
! src/share/classes/com/sun/tools/jdi/ShortValueImpl.java
! src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java
! src/share/classes/com/sun/tools/jdi/TargetVM.java
! src/share/classes/com/sun/tools/jdi/ThreadAction.java
! src/share/classes/com/sun/tools/jdi/ThreadGroupReferenceImpl.java
! src/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java
! src/share/classes/com/sun/tools/jdi/VMAction.java
! src/share/classes/com/sun/tools/jdi/VMState.java
! src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java
! src/share/classes/java/applet/Applet.java
! src/share/classes/java/io/Closeable.java
! src/share/classes/java/io/ExpiringCache.java
! src/share/classes/java/io/InputStream.java
! src/share/classes/java/io/LineNumberReader.java
! src/share/classes/java/io/ObjectInputStream.java
! src/share/classes/java/io/PrintWriter.java
! src/share/classes/java/io/Reader.java
! src/share/classes/java/io/SequenceInputStream.java
! src/share/classes/java/io/Writer.java
! src/share/classes/java/lang/AssertionError.java
! src/share/classes/java/lang/CharSequence.java
! src/share/classes/java/lang/CharacterData.java
! src/share/classes/java/lang/CharacterName.java
! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/ClassValue.java
! src/share/classes/java/lang/ConditionalSpecialCasing.java
! src/share/classes/java/lang/Enum.java
! src/share/classes/java/lang/EnumConstantNotPresentException.java
! src/share/classes/java/lang/InheritableThreadLocal.java
! src/share/classes/java/lang/Math.java
! src/share/classes/java/lang/Object.java
! src/share/classes/java/lang/Override.java
! src/share/classes/java/lang/Package.java
! src/share/classes/java/lang/ProcessBuilder.java
! src/share/classes/java/lang/Runtime.java
! src/share/classes/java/lang/SecurityManager.java
! src/share/classes/java/lang/StrictMath.java
! src/share/classes/java/lang/StringBuilder.java
! src/share/classes/java/lang/StringCoding.java
! src/share/classes/java/lang/System.java
! src/share/classes/java/lang/Thread.java
! src/share/classes/java/lang/ThreadGroup.java
! src/share/classes/java/lang/ThreadLocal.java
! src/share/classes/java/lang/Throwable.java
! src/share/classes/java/lang/Void.java
! src/share/classes/java/lang/annotation/Annotation.java
! src/share/classes/java/lang/instrument/ClassDefinition.java
! src/share/classes/java/lang/instrument/ClassFileTransformer.java
! src/share/classes/java/lang/instrument/Instrumentation.java
! src/share/classes/java/lang/invoke/CallSite.java
! src/share/classes/java/lang/invoke/DirectMethodHandle.java
! src/share/classes/java/lang/invoke/Invokers.java
! src/share/classes/java/lang/invoke/MemberName.java
! src/share/classes/java/lang/invoke/MethodHandle.java
! src/share/classes/java/lang/invoke/MethodHandleProxies.java
! src/share/classes/java/lang/invoke/MethodTypeForm.java
! src/share/classes/java/lang/invoke/SimpleMethodHandle.java
! src/share/classes/java/lang/invoke/WrongMethodTypeException.java
! src/share/classes/java/lang/invoke/package-info.java
! src/share/classes/java/lang/management/BufferPoolMXBean.java
! src/share/classes/java/lang/management/LockInfo.java
! src/share/classes/java/lang/management/ManagementPermission.java
! src/share/classes/java/lang/management/PlatformComponent.java
! src/share/classes/java/lang/management/PlatformLoggingMXBean.java
! src/share/classes/java/lang/management/PlatformManagedObject.java
! src/share/classes/java/lang/management/ThreadInfo.java
! src/share/classes/java/lang/management/package.html
! src/share/classes/java/lang/ref/Reference.java
! src/share/classes/java/lang/reflect/AccessibleObject.java
! src/share/classes/java/lang/reflect/Array.java
! src/share/classes/java/lang/reflect/Constructor.java
! src/share/classes/java/lang/reflect/Executable.java
! src/share/classes/java/lang/reflect/Field.java
! src/share/classes/java/lang/reflect/GenericDeclaration.java
! src/share/classes/java/lang/reflect/Method.java
! src/share/classes/java/lang/reflect/Modifier.java
! src/share/classes/java/lang/reflect/Proxy.java
! src/share/classes/java/lang/reflect/TypeVariable.java
! src/share/classes/java/net/AbstractPlainSocketImpl.java
! src/share/classes/java/net/ContentHandler.java
! src/share/classes/java/net/CookieManager.java
! src/share/classes/java/net/DatagramPacket.java
! src/share/classes/java/net/DatagramSocket.java
! src/share/classes/java/net/InMemoryCookieStore.java
! src/share/classes/java/net/Inet4Address.java
! src/share/classes/java/net/InetAddress.java
! src/share/classes/java/net/MulticastSocket.java
! src/share/classes/java/net/NetworkInterface.java
! src/share/classes/java/net/ProxySelector.java
! src/share/classes/java/net/ServerSocket.java
! src/share/classes/java/net/SocketImpl.java
! src/share/classes/java/net/SocketInputStream.java
! src/share/classes/java/net/SocketOption.java
! src/share/classes/java/net/SocketPermission.java
! src/share/classes/java/net/SocksSocketImpl.java
! src/share/classes/java/net/StandardSocketOptions.java
! src/share/classes/java/net/URL.java
! src/share/classes/java/net/URLConnection.java
! src/share/classes/java/net/URLStreamHandler.java
! src/share/classes/java/net/package.html
! src/share/classes/java/nio/MappedByteBuffer.java
! src/share/classes/java/nio/X-Buffer.java.template
! src/share/classes/java/nio/channels/AsynchronousFileChannel.java
! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java
! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java
! src/share/classes/java/nio/channels/Channels.java
! src/share/classes/java/nio/channels/DatagramChannel.java
! src/share/classes/java/nio/channels/FileChannel.java
! src/share/classes/java/nio/channels/MulticastChannel.java
! src/share/classes/java/nio/channels/NetworkChannel.java
! src/share/classes/java/nio/channels/ServerSocketChannel.java
! src/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java
! src/share/classes/java/nio/file/FileSystem.java
! src/share/classes/java/nio/file/FileTreeWalker.java
! src/share/classes/java/nio/file/Files.java
! src/share/classes/java/nio/file/StandardWatchEventKinds.java
! src/share/classes/java/nio/file/Watchable.java
! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java
! src/share/classes/java/nio/file/attribute/FileTime.java
! src/share/classes/java/rmi/MarshalledObject.java
! src/share/classes/java/rmi/dgc/VMID.java
! src/share/classes/java/rmi/server/LogStream.java
! src/share/classes/java/rmi/server/RemoteObject.java
! src/share/classes/java/security/AllPermission.java
! src/share/classes/java/security/BasicPermission.java
! src/share/classes/java/security/KeyRep.java
! src/share/classes/java/security/KeyStore.java
! src/share/classes/java/security/cert/Certificate.java
! src/share/classes/java/security/cert/CollectionCertStoreParameters.java
! src/share/classes/java/security/cert/LDAPCertStoreParameters.java
! src/share/classes/java/security/cert/PKIXCertPathValidatorResult.java
! src/share/classes/java/security/cert/PKIXParameters.java
! src/share/classes/java/security/cert/X509CRL.java
! src/share/classes/java/security/cert/X509Certificate.java
! src/share/classes/java/sql/CallableStatement.java
! src/share/classes/java/sql/Date.java
! src/share/classes/java/sql/PreparedStatement.java
! src/share/classes/java/sql/ResultSet.java
! src/share/classes/java/sql/SQLPermission.java
! src/share/classes/java/sql/Statement.java
! src/share/classes/java/sql/Time.java
! src/share/classes/java/text/AttributedCharacterIterator.java
! src/share/classes/java/text/AttributedString.java
! src/share/classes/java/text/BreakIterator.java
! src/share/classes/java/text/CharacterIteratorFieldDelegate.java
! src/share/classes/java/text/ChoiceFormat.java
! src/share/classes/java/text/CollationElementIterator.java
! src/share/classes/java/text/DateFormat.java
! src/share/classes/java/text/DigitList.java
! src/share/classes/java/text/Format.java
! src/share/classes/java/text/MergeCollation.java
! src/share/classes/java/text/MessageFormat.java
! src/share/classes/java/text/ParseException.java
! src/share/classes/java/text/RBCollationTables.java
! src/share/classes/java/text/RBTableBuilder.java
! src/share/classes/java/text/StringCharacterIterator.java
! src/share/classes/java/util/AbstractCollection.java
! src/share/classes/java/util/AbstractList.java
! src/share/classes/java/util/AbstractMap.java
! src/share/classes/java/util/AbstractSet.java
! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/BitSet.java
! src/share/classes/java/util/Calendar.java
! src/share/classes/java/util/Collection.java
! src/share/classes/java/util/EnumMap.java
! src/share/classes/java/util/EnumSet.java
! src/share/classes/java/util/Formatter.java
! src/share/classes/java/util/HashSet.java
! src/share/classes/java/util/Hashtable.java
! src/share/classes/java/util/IdentityHashMap.java
! src/share/classes/java/util/IllegalFormatConversionException.java
! src/share/classes/java/util/InvalidPropertiesFormatException.java
! src/share/classes/java/util/LinkedHashMap.java
! src/share/classes/java/util/List.java
! src/share/classes/java/util/ListIterator.java
! src/share/classes/java/util/Map.java
! src/share/classes/java/util/Observable.java
! src/share/classes/java/util/PropertyPermission.java
! src/share/classes/java/util/Random.java
! src/share/classes/java/util/RegularEnumSet.java
! src/share/classes/java/util/Scanner.java
! src/share/classes/java/util/Set.java
! src/share/classes/java/util/SortedMap.java
! src/share/classes/java/util/TreeMap.java
! src/share/classes/java/util/TreeSet.java
! src/share/classes/java/util/UUID.java
! src/share/classes/java/util/WeakHashMap.java
! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
! src/share/classes/java/util/jar/Attributes.java
! src/share/classes/java/util/logging/Handler.java
! src/share/classes/java/util/logging/LogManager.java
! src/share/classes/java/util/logging/Logger.java
! src/share/classes/java/util/logging/Logging.java
! src/share/classes/java/util/logging/LoggingMXBean.java
! src/share/classes/java/util/logging/LoggingProxyImpl.java
! src/share/classes/java/util/logging/SimpleFormatter.java
! src/share/classes/java/util/prefs/AbstractPreferences.java
! src/share/classes/java/util/prefs/XmlSupport.java
! src/share/classes/java/util/regex/Matcher.java
! src/share/classes/java/util/regex/Pattern.java
! src/share/classes/java/util/spi/CurrencyNameProvider.java
! src/share/classes/java/util/zip/Adler32.java
! src/share/classes/java/util/zip/CRC32.java
! src/share/classes/java/util/zip/Deflater.java
! src/share/classes/java/util/zip/DeflaterOutputStream.java
! src/share/classes/java/util/zip/GZIPInputStream.java
! src/share/classes/java/util/zip/Inflater.java
! src/share/classes/java/util/zip/ZipCoder.java
! src/share/classes/java/util/zip/ZipOutputStream.java
! src/share/classes/javax/accessibility/AccessibleContext.java
! src/share/classes/javax/crypto/CryptoAllPermission.java
! src/share/classes/javax/crypto/CryptoPermission.java
! src/share/classes/javax/crypto/CryptoPolicyParser.java
! src/share/classes/javax/crypto/NullCipherSpi.java
! src/share/classes/javax/imageio/metadata/IIOMetadataNode.java
! src/share/classes/javax/imageio/metadata/doc-files/jpeg_metadata.html
! src/share/classes/javax/management/modelmbean/DescriptorSupport.java
! src/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java
! src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java
! src/share/classes/javax/management/openmbean/TabularDataSupport.java
! src/share/classes/javax/management/remote/rmi/RMIConnector.java
! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java
! src/share/classes/javax/management/timer/Timer.java
! src/share/classes/javax/management/timer/TimerAlarmClock.java
! src/share/classes/javax/naming/spi/NamingManager.java
! src/share/classes/javax/net/ssl/SSLContext.java
! src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java
! src/share/classes/javax/print/attribute/standard/ReferenceUriSchemesSupported.java
! src/share/classes/javax/script/ScriptEngineManager.java
! src/share/classes/javax/script/ScriptException.java
! src/share/classes/javax/security/auth/Subject.java
! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java
! src/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java
! src/share/classes/javax/security/auth/kerberos/ServicePermission.java
! src/share/classes/javax/security/auth/login/LoginContext.java
! src/share/classes/javax/security/cert/CertificateEncodingException.java
! src/share/classes/javax/security/cert/CertificateException.java
! src/share/classes/javax/security/cert/CertificateExpiredException.java
! src/share/classes/javax/security/cert/CertificateNotYetValidException.java
! src/share/classes/javax/security/cert/X509Certificate.java
! src/share/classes/javax/security/sasl/Sasl.java
! src/share/classes/javax/security/sasl/SaslServerFactory.java
! src/share/classes/javax/smartcardio/TerminalFactory.java
! src/share/classes/javax/sql/ConnectionPoolDataSource.java
! src/share/classes/javax/sql/PooledConnection.java
! src/share/classes/javax/sql/StatementEvent.java
! src/share/classes/javax/sql/rowset/RowSetMetaDataImpl.java
! src/share/classes/javax/sql/rowset/RowSetProvider.java
! src/share/classes/javax/sql/rowset/package.html
! src/share/classes/javax/sql/rowset/serial/SerialArray.java
! src/share/classes/javax/sql/rowset/serial/SerialRef.java
! src/share/classes/javax/sql/rowset/spi/SyncProvider.java
! src/share/classes/javax/xml/crypto/NodeSetData.java
! src/share/classes/javax/xml/crypto/dom/DOMCryptoContext.java
! src/share/classes/javax/xml/crypto/dsig/Manifest.java
! src/share/classes/javax/xml/crypto/dsig/Reference.java
! src/share/classes/javax/xml/crypto/dsig/SignatureProperties.java
! src/share/classes/javax/xml/crypto/dsig/SignatureProperty.java
! src/share/classes/javax/xml/crypto/dsig/SignedInfo.java
! src/share/classes/javax/xml/crypto/dsig/TransformService.java
! src/share/classes/javax/xml/crypto/dsig/XMLObject.java
! src/share/classes/javax/xml/crypto/dsig/XMLSignature.java
! src/share/classes/javax/xml/crypto/dsig/XMLSignatureFactory.java
! src/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfo.java
! src/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfoFactory.java
! src/share/classes/javax/xml/crypto/dsig/keyinfo/PGPData.java
! src/share/classes/javax/xml/crypto/dsig/keyinfo/RetrievalMethod.java
! src/share/classes/javax/xml/crypto/dsig/keyinfo/X509Data.java
! src/share/classes/javax/xml/crypto/dsig/spec/ExcC14NParameterSpec.java
! src/share/classes/javax/xml/crypto/dsig/spec/XPathFilter2ParameterSpec.java
! src/share/classes/javax/xml/crypto/dsig/spec/XPathFilterParameterSpec.java
! src/share/classes/javax/xml/crypto/dsig/spec/XPathType.java
! src/share/classes/org/ietf/jgss/Oid.java
! src/share/classes/sun/dc/DuctusRenderingEngine.java
! src/share/classes/sun/instrument/InstrumentationImpl.java
! src/share/classes/sun/instrument/TransformerManager.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/launcher/resources/launcher.properties
! src/share/classes/sun/management/ConnectorAddressLink.java
! src/share/classes/sun/management/Flag.java
! src/share/classes/sun/management/GarbageCollectionNotifInfoCompositeData.java
! src/share/classes/sun/management/GarbageCollectorImpl.java
! src/share/classes/sun/management/GcInfoBuilder.java
! src/share/classes/sun/management/GcInfoCompositeData.java
! src/share/classes/sun/management/HotspotCompilation.java
! src/share/classes/sun/management/HotspotThread.java
! src/share/classes/sun/management/LazyCompositeData.java
! src/share/classes/sun/management/ManagementFactoryHelper.java
! src/share/classes/sun/management/MappedMXBeanType.java
! src/share/classes/sun/management/MonitorInfoCompositeData.java
! src/share/classes/sun/management/NotificationEmitterSupport.java
! src/share/classes/sun/management/RuntimeImpl.java
! src/share/classes/sun/management/ThreadInfoCompositeData.java
! src/share/classes/sun/management/counter/perf/PerfDataEntry.java
! src/share/classes/sun/management/counter/perf/PerfDataType.java
! src/share/classes/sun/management/counter/perf/PerfInstrumentation.java
! src/share/classes/sun/management/snmp/AdaptorBootstrap.java
! src/share/classes/sun/management/snmp/jvminstr/JVM_MANAGEMENT_MIB_IMPL.java
! src/share/classes/sun/management/snmp/jvminstr/JvmMemGCTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmMemManagerTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmMemMgrPoolRelTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmMemPoolTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmOSImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathEntryImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathEntryImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsEntryImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathEntryImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRuntimeMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmThreadingMetaImpl.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmClassesVerboseLevel.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmJITCompilerTimeMonitoring.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemManagerState.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolCollectThreshdSupport.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolState.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolThreshdSupport.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolType.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCCall.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCVerboseLevel.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmRTBootClassPathSupport.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadContentionMonitoring.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadCpuTimeMonitoring.java
! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIB.java
! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIBOidTable.java
! src/share/classes/sun/management/snmp/jvmmib/JvmClassLoadingMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmCompilationMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmOSMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRuntimeMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmThreadingMeta.java
! src/share/classes/sun/management/snmp/util/MibLogger.java
! src/share/classes/sun/management/snmp/util/SnmpListTableCache.java
! src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java
! src/share/classes/sun/management/snmp/util/SnmpTableCache.java
! src/share/classes/sun/misc/BASE64Decoder.java
! src/share/classes/sun/misc/CEFormatException.java
! src/share/classes/sun/misc/CEStreamExhausted.java
! src/share/classes/sun/misc/ClassLoaderUtil.java
! src/share/classes/sun/misc/CompoundEnumeration.java
! src/share/classes/sun/misc/ExtensionDependency.java
! src/share/classes/sun/misc/ExtensionInstallationException.java
! src/share/classes/sun/misc/FDBigInt.java
! src/share/classes/sun/misc/FloatingDecimal.java
! src/share/classes/sun/misc/InvalidJarIndexException.java
! src/share/classes/sun/misc/JarIndex.java
! src/share/classes/sun/misc/JavaLangAccess.java
! src/share/classes/sun/misc/LRUCache.java
! src/share/classes/sun/misc/MetaIndex.java
! src/share/classes/sun/misc/ProxyGenerator.java
! src/share/classes/sun/misc/Queue.java
! src/share/classes/sun/misc/REException.java
! src/share/classes/sun/misc/RequestProcessor.java
! src/share/classes/sun/misc/Service.java
! src/share/classes/sun/misc/ServiceConfigurationError.java
! src/share/classes/sun/misc/Signal.java
! src/share/classes/sun/misc/Unsafe.java
! src/share/classes/sun/misc/VM.java
! src/share/classes/sun/net/NetworkClient.java
! src/share/classes/sun/net/NetworkServer.java
! src/share/classes/sun/net/ftp/impl/FtpClient.java
! src/share/classes/sun/net/httpserver/Event.java
! src/share/classes/sun/net/httpserver/Request.java
! src/share/classes/sun/net/httpserver/WriteFinishedEvent.java
! src/share/classes/sun/net/sdp/SdpSupport.java
! src/share/classes/sun/net/smtp/SmtpClient.java
! src/share/classes/sun/net/spi/DefaultProxySelector.java
! src/share/classes/sun/net/www/content/image/gif.java
! src/share/classes/sun/net/www/content/image/jpeg.java
! src/share/classes/sun/net/www/content/image/png.java
! src/share/classes/sun/net/www/content/image/x_xbitmap.java
! src/share/classes/sun/net/www/content/image/x_xpixmap.java
! src/share/classes/sun/net/www/http/ChunkedOutputStream.java
! src/share/classes/sun/net/www/http/KeepAliveCleanerEntry.java
! src/share/classes/sun/net/www/http/KeepAliveStream.java
! src/share/classes/sun/net/www/protocol/https/HttpsClient.java
! src/share/classes/sun/net/www/protocol/mailto/Handler.java
! src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java
! src/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java
! src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java
! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java
! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java
! src/share/classes/sun/nio/ch/ExtendedSocketOption.java
! src/share/classes/sun/nio/ch/IOStatus.java
! src/share/classes/sun/nio/ch/IOUtil.java
! src/share/classes/sun/nio/ch/NativeThreadSet.java
! src/share/classes/sun/nio/ch/Net.java
! src/share/classes/sun/nio/ch/SelChImpl.java
! src/share/classes/sun/nio/ch/SelectionKeyImpl.java
! src/share/classes/sun/nio/ch/SelectorImpl.java
! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java
! src/share/classes/sun/nio/ch/SocketAdaptor.java
! src/share/classes/sun/nio/ch/Util.java
! src/share/classes/sun/nio/ch/sctp/MessageInfoImpl.java
! src/share/classes/sun/nio/ch/sctp/SctpStdSocketOption.java
! src/share/classes/sun/nio/cs/AbstractCharsetProvider.java
! src/share/classes/sun/nio/cs/SingleByte.java
! src/share/classes/sun/nio/cs/UTF_8.java
! src/share/classes/sun/nio/cs/ext/DoubleByte.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/GB18030.java
! src/share/classes/sun/nio/cs/ext/HKSCS.java
! src/share/classes/sun/nio/cs/ext/IBM33722.java
! src/share/classes/sun/nio/cs/ext/IBM834.java
! src/share/classes/sun/nio/cs/ext/IBM964.java
! src/share/classes/sun/nio/cs/ext/ISCII91.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/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/standard-charsets
! src/share/classes/sun/print/RasterPrinterJob.java
! src/share/classes/sun/print/ServiceDialog.java
! src/share/classes/sun/reflect/AccessorGenerator.java
! src/share/classes/sun/reflect/BootstrapConstructorAccessorImpl.java
! src/share/classes/sun/reflect/ClassDefiner.java
! src/share/classes/sun/reflect/ConstantPool.java
! src/share/classes/sun/reflect/Label.java
! src/share/classes/sun/reflect/MethodAccessorGenerator.java
! src/share/classes/sun/reflect/NativeConstructorAccessorImpl.java
! src/share/classes/sun/reflect/Reflection.java
! src/share/classes/sun/reflect/ReflectionFactory.java
! src/share/classes/sun/reflect/UTF8.java
! src/share/classes/sun/reflect/UnsafeFieldAccessorFactory.java
! src/share/classes/sun/reflect/UnsafeFieldAccessorImpl.java
! src/share/classes/sun/reflect/annotation/AnnotationParser.java
! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java
! src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java
! src/share/classes/sun/reflect/generics/scope/AbstractScope.java
! src/share/classes/sun/reflect/generics/scope/ConstructorScope.java
! src/share/classes/sun/reflect/generics/tree/ClassSignature.java
! src/share/classes/sun/reflect/generics/tree/MethodTypeSignature.java
! src/share/classes/sun/reflect/misc/ReflectUtil.java
! src/share/classes/sun/rmi/log/ReliableLog.java
! src/share/classes/sun/rmi/registry/RegistryImpl.java
! src/share/classes/sun/rmi/rmic/BatchEnvironment.java
! src/share/classes/sun/rmi/rmic/Main.java
! src/share/classes/sun/rmi/rmic/RMIGenerator.java
! src/share/classes/sun/rmi/rmic/newrmic/Main.java
! src/share/classes/sun/rmi/rmic/newrmic/Resources.java
! src/share/classes/sun/rmi/server/ActivatableRef.java
! src/share/classes/sun/rmi/server/ActivationGroupImpl.java
! src/share/classes/sun/rmi/server/LoaderHandler.java
! src/share/classes/sun/rmi/server/MarshalInputStream.java
! src/share/classes/sun/rmi/server/UnicastRef.java
! src/share/classes/sun/rmi/server/UnicastRef2.java
! src/share/classes/sun/rmi/server/UnicastServerRef.java
! src/share/classes/sun/rmi/server/Util.java
! src/share/classes/sun/rmi/server/WeakClassHashMap.java
! src/share/classes/sun/rmi/transport/ConnectionInputStream.java
! src/share/classes/sun/rmi/transport/DGCAckHandler.java
! src/share/classes/sun/rmi/transport/DGCClient.java
! src/share/classes/sun/rmi/transport/DGCImpl.java
! src/share/classes/sun/rmi/transport/LiveRef.java
! src/share/classes/sun/rmi/transport/ObjectTable.java
! src/share/classes/sun/rmi/transport/StreamRemoteCall.java
! src/share/classes/sun/rmi/transport/Target.java
! src/share/classes/sun/rmi/transport/Transport.java
! src/share/classes/sun/rmi/transport/WeakRef.java
! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java
! src/share/classes/sun/rmi/transport/proxy/HttpInputStream.java
! src/share/classes/sun/rmi/transport/proxy/HttpSendSocket.java
! src/share/classes/sun/rmi/transport/proxy/RMIMasterSocketFactory.java
! src/share/classes/sun/rmi/transport/tcp/ConnectionMultiplexer.java
! src/share/classes/sun/rmi/transport/tcp/TCPChannel.java
! src/share/classes/sun/rmi/transport/tcp/TCPEndpoint.java
! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java
! src/share/classes/sun/security/ec/ECPublicKeyImpl.java
! src/share/classes/sun/security/jgss/GSSCredentialImpl.java
! src/share/classes/sun/security/jgss/krb5/AcceptSecContextToken.java
! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java
! src/share/classes/sun/security/jgss/krb5/MessageToken_v2.java
! src/share/classes/sun/security/jgss/spi/GSSContextSpi.java
! src/share/classes/sun/security/krb5/Checksum.java
! src/share/classes/sun/security/krb5/KdcComm.java
! src/share/classes/sun/security/krb5/KrbApReq.java
! src/share/classes/sun/security/krb5/KrbAsRep.java
! src/share/classes/sun/security/krb5/KrbAsReq.java
! src/share/classes/sun/security/krb5/KrbAsReqBuilder.java
! src/share/classes/sun/security/krb5/KrbCred.java
! src/share/classes/sun/security/krb5/KrbException.java
! src/share/classes/sun/security/krb5/KrbPriv.java
! src/share/classes/sun/security/krb5/KrbSafe.java
! src/share/classes/sun/security/krb5/KrbTgsRep.java
! src/share/classes/sun/security/krb5/KrbTgsReq.java
! src/share/classes/sun/security/krb5/PrincipalName.java
! src/share/classes/sun/security/krb5/Realm.java
! src/share/classes/sun/security/krb5/RealmException.java
! src/share/classes/sun/security/krb5/SCDynamicStoreConfig.java
! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java
! src/share/classes/sun/security/krb5/internal/KRBError.java
! src/share/classes/sun/security/krb5/internal/NetClient.java
! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java
! src/share/classes/sun/security/krb5/internal/crypto/CksumType.java
! src/share/classes/sun/security/krb5/internal/crypto/EType.java
! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java
! src/share/classes/sun/security/krb5/internal/ktab/KeyTabInputStream.java
! src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java
! src/share/classes/sun/security/pkcs11/Config.java
! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java
! src/share/classes/sun/security/provider/DigestBase.java
! src/share/classes/sun/security/provider/JavaKeyStore.java
! src/share/classes/sun/security/provider/MD2.java
! src/share/classes/sun/security/provider/MD4.java
! src/share/classes/sun/security/provider/MD5.java
! src/share/classes/sun/security/provider/PolicyFile.java
! src/share/classes/sun/security/provider/SHA.java
! src/share/classes/sun/security/provider/SHA5.java
! src/share/classes/sun/security/smartcardio/PCSC.java
! src/share/classes/sun/security/smartcardio/TerminalImpl.java
! src/share/classes/sun/security/ssl/ExtensionType.java
! src/share/classes/sun/security/ssl/HelloExtension.java
! src/share/classes/sun/security/ssl/RenegotiationInfoExtension.java
! src/share/classes/sun/security/ssl/ServerNameExtension.java
! src/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java
! src/share/classes/sun/security/ssl/SupportedEllipticCurvesExtension.java
! src/share/classes/sun/security/ssl/SupportedEllipticPointFormatsExtension.java
! src/share/classes/sun/security/ssl/UnknownExtension.java
! src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java
! src/share/classes/sun/security/util/Debug.java
! src/share/classes/sun/security/util/HostnameChecker.java
! src/share/classes/sun/security/util/SecurityConstants.java
! src/share/classes/sun/security/validator/PKIXValidator.java
! src/share/classes/sun/security/x509/CRLExtensions.java
! src/share/classes/sun/security/x509/CertificateExtensions.java
! src/share/classes/sun/security/x509/DNSName.java
! src/share/classes/sun/security/x509/RFC822Name.java
! src/share/classes/sun/security/x509/URIName.java
! src/share/classes/sun/security/x509/X509CRLEntryImpl.java
! src/share/classes/sun/security/x509/X509CRLImpl.java
! src/share/classes/sun/security/x509/X509CertImpl.java
! src/share/classes/sun/security/x509/X509CertInfo.java
! src/share/classes/sun/text/CompactByteArray.java
! src/share/classes/sun/text/IntHashtable.java
! src/share/classes/sun/text/bidi/BidiBase.java
! src/share/classes/sun/text/normalizer/ICUData.java
! src/share/classes/sun/text/normalizer/NormalizerBase.java
! src/share/classes/sun/text/normalizer/NormalizerImpl.java
! src/share/classes/sun/text/normalizer/SymbolTable.java
! src/share/classes/sun/text/normalizer/UnicodeSet.java
! src/share/classes/sun/text/normalizer/UnicodeSetIterator.java
! src/share/classes/sun/text/normalizer/VersionInfo.java
! src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java
! src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider
! src/share/classes/sun/tools/jar/CommandLine.java
! src/share/classes/sun/tools/jar/Manifest.java
! src/share/classes/sun/tools/jar/SignatureFile.java
! src/share/classes/sun/tools/javac/resources/javac.properties
! src/share/classes/sun/tools/jcmd/Arguments.java
! src/share/classes/sun/tools/jconsole/AboutDialog.java
! src/share/classes/sun/tools/jconsole/BorderedComponent.java
! src/share/classes/sun/tools/jconsole/ClassTab.java
! src/share/classes/sun/tools/jconsole/ConnectDialog.java
! src/share/classes/sun/tools/jconsole/CreateMBeanDialog.java
! src/share/classes/sun/tools/jconsole/Formatter.java
! src/share/classes/sun/tools/jconsole/HTMLPane.java
! src/share/classes/sun/tools/jconsole/InternalDialog.java
! src/share/classes/sun/tools/jconsole/JConsole.java
! src/share/classes/sun/tools/jconsole/LabeledComponent.java
! src/share/classes/sun/tools/jconsole/LocalVirtualMachine.java
! src/share/classes/sun/tools/jconsole/MBeansTab.java
! src/share/classes/sun/tools/jconsole/MaximizableInternalFrame.java
! src/share/classes/sun/tools/jconsole/MemoryPoolProxy.java
! src/share/classes/sun/tools/jconsole/MemoryPoolStat.java
! src/share/classes/sun/tools/jconsole/MemoryTab.java
! src/share/classes/sun/tools/jconsole/OverviewPanel.java
! src/share/classes/sun/tools/jconsole/OverviewTab.java
! src/share/classes/sun/tools/jconsole/Plotter.java
! src/share/classes/sun/tools/jconsole/PlotterPanel.java
! src/share/classes/sun/tools/jconsole/ProxyClient.java
! src/share/classes/sun/tools/jconsole/Resources.java
! src/share/classes/sun/tools/jconsole/SummaryTab.java
! src/share/classes/sun/tools/jconsole/Tab.java
! src/share/classes/sun/tools/jconsole/ThreadTab.java
! src/share/classes/sun/tools/jconsole/VMInternalFrame.java
! src/share/classes/sun/tools/jconsole/VMPanel.java
! src/share/classes/sun/tools/jconsole/VariableGridLayout.java
! src/share/classes/sun/tools/jconsole/Version.java.template
! src/share/classes/sun/tools/jconsole/inspector/OperationEntry.java
! src/share/classes/sun/tools/jconsole/inspector/TableSorter.java
! src/share/classes/sun/tools/jconsole/inspector/ThreadDialog.java
! src/share/classes/sun/tools/jconsole/inspector/Utils.java
! src/share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java
! src/share/classes/sun/tools/jconsole/inspector/XDataViewer.java
! src/share/classes/sun/tools/jconsole/inspector/XMBeanAttributes.java
! src/share/classes/sun/tools/jconsole/inspector/XMBeanInfo.java
! src/share/classes/sun/tools/jconsole/inspector/XMBeanNotifications.java
! src/share/classes/sun/tools/jconsole/inspector/XObject.java
! src/share/classes/sun/tools/jconsole/inspector/XOpenTypeViewer.java
! src/share/classes/sun/tools/jconsole/inspector/XOperations.java
! src/share/classes/sun/tools/jconsole/inspector/XPlotter.java
! src/share/classes/sun/tools/jconsole/inspector/XPlottingViewer.java
! src/share/classes/sun/tools/jconsole/inspector/XSheet.java
! src/share/classes/sun/tools/jconsole/inspector/XTable.java
! src/share/classes/sun/tools/jconsole/inspector/XTextField.java
! src/share/classes/sun/tools/jconsole/inspector/XTree.java
! src/share/classes/sun/tools/jconsole/inspector/XTreeRenderer.java
! src/share/classes/sun/tools/jinfo/JInfo.java
! src/share/classes/sun/tools/jmap/JMap.java
! src/share/classes/sun/tools/jstack/JStack.java
! src/share/classes/sun/tools/serialver/SerialVer.java
! src/share/classes/sun/tools/tree/Node.java
! src/share/classes/sun/tracing/dtrace/DTraceProvider.java
! src/share/classes/sun/tracing/dtrace/JVM.java
! src/share/classes/sun/util/PreHashedMap.java
! src/share/classes/sun/util/calendar/CalendarDate.java
! src/share/classes/sun/util/locale/LocaleUtils.java
! src/share/classes/sun/util/logging/LoggingProxy.java
! src/share/classes/sun/util/logging/LoggingSupport.java
! src/share/classes/sun/util/logging/PlatformLogger.java
! src/share/classes/sun/util/resources/OpenListResourceBundle.java
! src/share/classes/sun/util/resources/TimeZoneNames.java
! src/share/classes/sun/util/resources/ar/CalendarData_ar.properties
! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_AE.properties
! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_BH.properties
! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_DZ.properties
! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_EG.properties
! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_IQ.properties
! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_JO.properties
! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_KW.properties
! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_LB.properties
! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_LY.properties
! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_MA.properties
! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_OM.properties
! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_QA.properties
! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SA.properties
! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SD.properties
! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SY.properties
! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_TN.properties
! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_YE.properties
! src/share/classes/sun/util/resources/ar/LocaleNames_ar.properties
! src/share/classes/sun/util/resources/be/CalendarData_be.properties
! src/share/classes/sun/util/resources/be/CurrencyNames_be_BY.properties
! src/share/classes/sun/util/resources/be/LocaleNames_be.properties
! src/share/classes/sun/util/resources/bg/CalendarData_bg.properties
! src/share/classes/sun/util/resources/bg/CurrencyNames_bg_BG.properties
! src/share/classes/sun/util/resources/bg/LocaleNames_bg.properties
! src/share/classes/sun/util/resources/ca/CalendarData_ca.properties
! src/share/classes/sun/util/resources/ca/CurrencyNames_ca_ES.properties
! src/share/classes/sun/util/resources/ca/LocaleNames_ca.properties
! src/share/classes/sun/util/resources/cs/CalendarData_cs.properties
! src/share/classes/sun/util/resources/cs/CurrencyNames_cs_CZ.properties
! src/share/classes/sun/util/resources/cs/LocaleNames_cs.properties
! src/share/classes/sun/util/resources/da/CalendarData_da.properties
! src/share/classes/sun/util/resources/da/CurrencyNames_da_DK.properties
! src/share/classes/sun/util/resources/da/LocaleNames_da.properties
! src/share/classes/sun/util/resources/de/CalendarData_de.properties
! src/share/classes/sun/util/resources/de/CurrencyNames_de.properties
! src/share/classes/sun/util/resources/de/CurrencyNames_de_AT.properties
! src/share/classes/sun/util/resources/de/CurrencyNames_de_CH.properties
! src/share/classes/sun/util/resources/de/CurrencyNames_de_DE.properties
! src/share/classes/sun/util/resources/de/CurrencyNames_de_GR.properties
! src/share/classes/sun/util/resources/de/CurrencyNames_de_LU.properties
! src/share/classes/sun/util/resources/de/LocaleNames_de.properties
! src/share/classes/sun/util/resources/el/CalendarData_el.properties
! src/share/classes/sun/util/resources/el/CalendarData_el_CY.properties
! src/share/classes/sun/util/resources/el/CurrencyNames_el_CY.properties
! src/share/classes/sun/util/resources/el/CurrencyNames_el_GR.properties
! src/share/classes/sun/util/resources/el/LocaleNames_el.properties
! src/share/classes/sun/util/resources/el/LocaleNames_el_CY.properties
! src/share/classes/sun/util/resources/en/CalendarData_en.properties
! src/share/classes/sun/util/resources/en/CalendarData_en_GB.properties
! src/share/classes/sun/util/resources/en/CalendarData_en_IE.properties
! src/share/classes/sun/util/resources/en/CalendarData_en_MT.properties
! src/share/classes/sun/util/resources/en/CurrencyNames_en_AU.properties
! src/share/classes/sun/util/resources/en/CurrencyNames_en_CA.properties
! src/share/classes/sun/util/resources/en/CurrencyNames_en_GB.properties
! src/share/classes/sun/util/resources/en/CurrencyNames_en_IE.properties
! src/share/classes/sun/util/resources/en/CurrencyNames_en_IN.properties
! src/share/classes/sun/util/resources/en/CurrencyNames_en_MT.properties
! src/share/classes/sun/util/resources/en/CurrencyNames_en_NZ.properties
! src/share/classes/sun/util/resources/en/CurrencyNames_en_PH.properties
! src/share/classes/sun/util/resources/en/CurrencyNames_en_SG.properties
! src/share/classes/sun/util/resources/en/CurrencyNames_en_US.properties
! src/share/classes/sun/util/resources/en/CurrencyNames_en_ZA.properties
! src/share/classes/sun/util/resources/en/LocaleNames_en.properties
! src/share/classes/sun/util/resources/en/LocaleNames_en_MT.properties
! src/share/classes/sun/util/resources/en/LocaleNames_en_PH.properties
! src/share/classes/sun/util/resources/en/LocaleNames_en_SG.properties
! src/share/classes/sun/util/resources/es/CalendarData_es.properties
! src/share/classes/sun/util/resources/es/CalendarData_es_ES.properties
! src/share/classes/sun/util/resources/es/CalendarData_es_US.properties
! src/share/classes/sun/util/resources/es/CurrencyNames_es.properties
! src/share/classes/sun/util/resources/es/CurrencyNames_es_AR.properties
! src/share/classes/sun/util/resources/es/CurrencyNames_es_BO.properties
! src/share/classes/sun/util/resources/es/CurrencyNames_es_CL.properties
! src/share/classes/sun/util/resources/es/CurrencyNames_es_CO.properties
! src/share/classes/sun/util/resources/es/CurrencyNames_es_CR.properties
! src/share/classes/sun/util/resources/es/CurrencyNames_es_CU.properties
! src/share/classes/sun/util/resources/es/CurrencyNames_es_DO.properties
! src/share/classes/sun/util/resources/es/CurrencyNames_es_EC.properties
! src/share/classes/sun/util/resources/es/CurrencyNames_es_ES.properties
! src/share/classes/sun/util/resources/es/CurrencyNames_es_GT.properties
! src/share/classes/sun/util/resources/es/CurrencyNames_es_HN.properties
! src/share/classes/sun/util/resources/es/CurrencyNames_es_MX.properties
! src/share/classes/sun/util/resources/es/CurrencyNames_es_NI.properties
! src/share/classes/sun/util/resources/es/CurrencyNames_es_PA.properties
! src/share/classes/sun/util/resources/es/CurrencyNames_es_PR.properties
! src/share/classes/sun/util/resources/es/CurrencyNames_es_PY.properties
! src/share/classes/sun/util/resources/es/CurrencyNames_es_SV.properties
! src/share/classes/sun/util/resources/es/CurrencyNames_es_US.properties
! src/share/classes/sun/util/resources/es/CurrencyNames_es_UY.properties
! src/share/classes/sun/util/resources/es/CurrencyNames_es_VE.properties
! src/share/classes/sun/util/resources/es/LocaleNames_es.properties
! src/share/classes/sun/util/resources/es/LocaleNames_es_US.properties
! src/share/classes/sun/util/resources/et/CalendarData_et.properties
! src/share/classes/sun/util/resources/et/CurrencyNames_et_EE.properties
! src/share/classes/sun/util/resources/et/LocaleNames_et.properties
! src/share/classes/sun/util/resources/fi/CalendarData_fi.properties
! src/share/classes/sun/util/resources/fi/CurrencyNames_fi_FI.properties
! src/share/classes/sun/util/resources/fi/LocaleNames_fi.properties
! src/share/classes/sun/util/resources/fr/CalendarData_fr.properties
! src/share/classes/sun/util/resources/fr/CalendarData_fr_CA.properties
! src/share/classes/sun/util/resources/fr/CurrencyNames_fr.properties
! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_BE.properties
! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_CA.properties
! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_CH.properties
! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_FR.properties
! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_LU.properties
! src/share/classes/sun/util/resources/fr/LocaleNames_fr.properties
! src/share/classes/sun/util/resources/ga/CurrencyNames_ga_IE.properties
! src/share/classes/sun/util/resources/ga/LocaleNames_ga.properties
! src/share/classes/sun/util/resources/hi/CalendarData_hi.properties
! src/share/classes/sun/util/resources/hi/CurrencyNames_hi_IN.properties
! src/share/classes/sun/util/resources/hi/LocaleNames_hi.properties
! src/share/classes/sun/util/resources/hr/CalendarData_hr.properties
! src/share/classes/sun/util/resources/hr/CurrencyNames_hr_HR.properties
! src/share/classes/sun/util/resources/hr/LocaleNames_hr.properties
! src/share/classes/sun/util/resources/hu/CalendarData_hu.properties
! src/share/classes/sun/util/resources/hu/CurrencyNames_hu_HU.properties
! src/share/classes/sun/util/resources/hu/LocaleNames_hu.properties
! src/share/classes/sun/util/resources/in/CalendarData_in_ID.properties
! src/share/classes/sun/util/resources/in/CurrencyNames_in_ID.properties
! src/share/classes/sun/util/resources/in/LocaleNames_in.properties
! src/share/classes/sun/util/resources/is/CalendarData_is.properties
! src/share/classes/sun/util/resources/is/CurrencyNames_is_IS.properties
! src/share/classes/sun/util/resources/is/LocaleNames_is.properties
! src/share/classes/sun/util/resources/it/CalendarData_it.properties
! src/share/classes/sun/util/resources/it/CurrencyNames_it.properties
! src/share/classes/sun/util/resources/it/CurrencyNames_it_CH.properties
! src/share/classes/sun/util/resources/it/CurrencyNames_it_IT.properties
! src/share/classes/sun/util/resources/it/LocaleNames_it.properties
! src/share/classes/sun/util/resources/iw/CalendarData_iw.properties
! src/share/classes/sun/util/resources/iw/CurrencyNames_iw_IL.properties
! src/share/classes/sun/util/resources/iw/LocaleNames_iw.properties
! src/share/classes/sun/util/resources/ja/CalendarData_ja.properties
! src/share/classes/sun/util/resources/ja/CurrencyNames_ja.properties
! src/share/classes/sun/util/resources/ja/CurrencyNames_ja_JP.properties
! src/share/classes/sun/util/resources/ja/LocaleNames_ja.properties
! src/share/classes/sun/util/resources/ko/CalendarData_ko.properties
! src/share/classes/sun/util/resources/ko/CurrencyNames_ko.properties
! src/share/classes/sun/util/resources/ko/CurrencyNames_ko_KR.properties
! src/share/classes/sun/util/resources/ko/LocaleNames_ko.properties
! src/share/classes/sun/util/resources/lt/CalendarData_lt.properties
! src/share/classes/sun/util/resources/lt/CurrencyNames_lt_LT.properties
! src/share/classes/sun/util/resources/lt/LocaleNames_lt.properties
! src/share/classes/sun/util/resources/lv/CalendarData_lv.properties
! src/share/classes/sun/util/resources/lv/CurrencyNames_lv_LV.properties
! src/share/classes/sun/util/resources/lv/LocaleNames_lv.properties
! src/share/classes/sun/util/resources/mk/CalendarData_mk.properties
! src/share/classes/sun/util/resources/mk/CurrencyNames_mk_MK.properties
! src/share/classes/sun/util/resources/mk/LocaleNames_mk.properties
! src/share/classes/sun/util/resources/ms/CalendarData_ms_MY.properties
! src/share/classes/sun/util/resources/ms/CurrencyNames_ms_MY.properties
! src/share/classes/sun/util/resources/ms/LocaleNames_ms.properties
! src/share/classes/sun/util/resources/mt/CalendarData_mt.properties
! src/share/classes/sun/util/resources/mt/CalendarData_mt_MT.properties
! src/share/classes/sun/util/resources/mt/CurrencyNames_mt_MT.properties
! src/share/classes/sun/util/resources/mt/LocaleNames_mt.properties
! src/share/classes/sun/util/resources/nl/CalendarData_nl.properties
! src/share/classes/sun/util/resources/nl/CurrencyNames_nl_BE.properties
! src/share/classes/sun/util/resources/nl/CurrencyNames_nl_NL.properties
! src/share/classes/sun/util/resources/nl/LocaleNames_nl.properties
! src/share/classes/sun/util/resources/no/CalendarData_no.properties
! src/share/classes/sun/util/resources/no/CurrencyNames_no_NO.properties
! src/share/classes/sun/util/resources/no/LocaleNames_no.properties
! src/share/classes/sun/util/resources/no/LocaleNames_no_NO_NY.properties
! src/share/classes/sun/util/resources/pl/CalendarData_pl.properties
! src/share/classes/sun/util/resources/pl/CurrencyNames_pl_PL.properties
! src/share/classes/sun/util/resources/pl/LocaleNames_pl.properties
! src/share/classes/sun/util/resources/pt/CalendarData_pt.properties
! src/share/classes/sun/util/resources/pt/CalendarData_pt_PT.properties
! src/share/classes/sun/util/resources/pt/CurrencyNames_pt.properties
! src/share/classes/sun/util/resources/pt/CurrencyNames_pt_BR.properties
! src/share/classes/sun/util/resources/pt/CurrencyNames_pt_PT.properties
! src/share/classes/sun/util/resources/pt/LocaleNames_pt.properties
! src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties
! src/share/classes/sun/util/resources/pt/LocaleNames_pt_PT.properties
! src/share/classes/sun/util/resources/ro/CalendarData_ro.properties
! src/share/classes/sun/util/resources/ro/CurrencyNames_ro_RO.properties
! src/share/classes/sun/util/resources/ro/LocaleNames_ro.properties
! src/share/classes/sun/util/resources/ru/CalendarData_ru.properties
! src/share/classes/sun/util/resources/ru/CurrencyNames_ru_RU.properties
! src/share/classes/sun/util/resources/ru/LocaleNames_ru.properties
! src/share/classes/sun/util/resources/sk/CalendarData_sk.properties
! src/share/classes/sun/util/resources/sk/CurrencyNames_sk_SK.properties
! src/share/classes/sun/util/resources/sk/LocaleNames_sk.properties
! src/share/classes/sun/util/resources/sl/CalendarData_sl.properties
! src/share/classes/sun/util/resources/sl/CurrencyNames_sl_SI.properties
! src/share/classes/sun/util/resources/sl/LocaleNames_sl.properties
! src/share/classes/sun/util/resources/sq/CalendarData_sq.properties
! src/share/classes/sun/util/resources/sq/CurrencyNames_sq_AL.properties
! src/share/classes/sun/util/resources/sq/LocaleNames_sq.properties
! src/share/classes/sun/util/resources/sr/CalendarData_sr.properties
! src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_BA.properties
! src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_ME.properties
! src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_RS.properties
! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_BA.properties
! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_CS.properties
! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_BA.properties
! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_ME.properties
! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_RS.properties
! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_ME.properties
! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_RS.properties
! src/share/classes/sun/util/resources/sr/LocaleNames_sr.properties
! src/share/classes/sun/util/resources/sr/LocaleNames_sr_Latn.properties
! src/share/classes/sun/util/resources/sv/CalendarData_sv.properties
! src/share/classes/sun/util/resources/sv/CurrencyNames_sv.properties
! src/share/classes/sun/util/resources/sv/CurrencyNames_sv_SE.properties
! src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties
! src/share/classes/sun/util/resources/th/CalendarData_th.properties
! src/share/classes/sun/util/resources/th/CurrencyNames_th_TH.properties
! src/share/classes/sun/util/resources/th/LocaleNames_th.properties
! src/share/classes/sun/util/resources/tr/CalendarData_tr.properties
! src/share/classes/sun/util/resources/tr/CurrencyNames_tr_TR.properties
! src/share/classes/sun/util/resources/tr/LocaleNames_tr.properties
! src/share/classes/sun/util/resources/uk/CalendarData_uk.properties
! src/share/classes/sun/util/resources/uk/CurrencyNames_uk_UA.properties
! src/share/classes/sun/util/resources/uk/LocaleNames_uk.properties
! src/share/classes/sun/util/resources/vi/CalendarData_vi.properties
! src/share/classes/sun/util/resources/vi/CurrencyNames_vi_VN.properties
! src/share/classes/sun/util/resources/vi/LocaleNames_vi.properties
! src/share/classes/sun/util/resources/zh/CalendarData_zh.properties
! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_CN.properties
! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_TW.properties
! src/share/classes/sun/util/resources/zh/LocaleNames_zh.properties
! src/share/classes/sun/util/resources/zh/LocaleNames_zh_SG.properties
! src/share/classes/sun/util/resources/zh/LocaleNames_zh_TW.properties
! src/share/classes/sun/util/xml/PlatformXmlPropertiesProvider.java
! src/share/demo/jfc/Font2DTest/Font2DTest.java
! src/share/demo/jfc/Font2DTest/Font2DTestApplet.java
! src/share/demo/jfc/Font2DTest/FontPanel.java
! src/share/demo/jfc/Notepad/Notepad.java
! src/share/demo/jvmti/agent_util/agent_util.c
! src/share/demo/jvmti/agent_util/agent_util.h
! src/share/demo/jvmti/compiledMethodLoad/compiledMethodLoad.c
! src/share/demo/jvmti/compiledMethodLoad/sample.makefile.txt
! src/share/demo/jvmti/gctest/gctest.c
! src/share/demo/jvmti/gctest/sample.makefile.txt
! src/share/demo/jvmti/heapTracker/HeapTracker.java
! src/share/demo/jvmti/heapTracker/heapTracker.c
! src/share/demo/jvmti/heapTracker/heapTracker.h
! src/share/demo/jvmti/heapTracker/sample.makefile.txt
! src/share/demo/jvmti/heapViewer/heapViewer.c
! src/share/demo/jvmti/heapViewer/sample.makefile.txt
! src/share/demo/jvmti/hprof/debug_malloc.c
! src/share/demo/jvmti/hprof/debug_malloc.h
! src/share/demo/jvmti/hprof/hprof.h
! src/share/demo/jvmti/hprof/hprof_blocks.c
! src/share/demo/jvmti/hprof/hprof_blocks.h
! src/share/demo/jvmti/hprof/hprof_check.c
! src/share/demo/jvmti/hprof/hprof_check.h
! src/share/demo/jvmti/hprof/hprof_class.c
! src/share/demo/jvmti/hprof/hprof_class.h
! src/share/demo/jvmti/hprof/hprof_cpu.c
! src/share/demo/jvmti/hprof/hprof_cpu.h
! src/share/demo/jvmti/hprof/hprof_error.c
! src/share/demo/jvmti/hprof/hprof_error.h
! src/share/demo/jvmti/hprof/hprof_event.c
! src/share/demo/jvmti/hprof/hprof_event.h
! src/share/demo/jvmti/hprof/hprof_frame.c
! src/share/demo/jvmti/hprof/hprof_frame.h
! src/share/demo/jvmti/hprof/hprof_init.c
! src/share/demo/jvmti/hprof/hprof_init.h
! src/share/demo/jvmti/hprof/hprof_io.c
! src/share/demo/jvmti/hprof/hprof_io.h
! src/share/demo/jvmti/hprof/hprof_ioname.c
! src/share/demo/jvmti/hprof/hprof_ioname.h
! src/share/demo/jvmti/hprof/hprof_listener.c
! src/share/demo/jvmti/hprof/hprof_listener.h
! src/share/demo/jvmti/hprof/hprof_loader.c
! src/share/demo/jvmti/hprof/hprof_loader.h
! src/share/demo/jvmti/hprof/hprof_md.h
! src/share/demo/jvmti/hprof/hprof_monitor.c
! src/share/demo/jvmti/hprof/hprof_monitor.h
! src/share/demo/jvmti/hprof/hprof_object.c
! src/share/demo/jvmti/hprof/hprof_object.h
! src/share/demo/jvmti/hprof/hprof_reference.c
! src/share/demo/jvmti/hprof/hprof_reference.h
! src/share/demo/jvmti/hprof/hprof_site.c
! src/share/demo/jvmti/hprof/hprof_site.h
! src/share/demo/jvmti/hprof/hprof_stack.c
! src/share/demo/jvmti/hprof/hprof_stack.h
! src/share/demo/jvmti/hprof/hprof_string.c
! src/share/demo/jvmti/hprof/hprof_string.h
! src/share/demo/jvmti/hprof/hprof_table.c
! src/share/demo/jvmti/hprof/hprof_table.h
! src/share/demo/jvmti/hprof/hprof_tag.c
! src/share/demo/jvmti/hprof/hprof_tag.h
! src/share/demo/jvmti/hprof/hprof_tls.c
! src/share/demo/jvmti/hprof/hprof_tls.h
! src/share/demo/jvmti/hprof/hprof_trace.c
! src/share/demo/jvmti/hprof/hprof_trace.h
! src/share/demo/jvmti/hprof/hprof_tracker.c
! src/share/demo/jvmti/hprof/hprof_tracker.h
! src/share/demo/jvmti/hprof/hprof_util.c
! src/share/demo/jvmti/hprof/hprof_util.h
! src/share/demo/jvmti/hprof/sample.makefile.txt
! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c
! src/share/demo/jvmti/java_crw_demo/java_crw_demo.h
! src/share/demo/jvmti/java_crw_demo/sample.makefile.txt
! src/share/demo/jvmti/minst/Minst.java
! src/share/demo/jvmti/minst/minst.c
! src/share/demo/jvmti/minst/minst.h
! src/share/demo/jvmti/minst/sample.makefile.txt
! src/share/demo/jvmti/mtrace/Mtrace.java
! src/share/demo/jvmti/mtrace/mtrace.c
! src/share/demo/jvmti/mtrace/mtrace.h
! src/share/demo/jvmti/mtrace/sample.makefile.txt
! src/share/demo/jvmti/versionCheck/sample.makefile.txt
! src/share/demo/jvmti/versionCheck/versionCheck.c
! src/share/demo/jvmti/waiters/Agent.cpp
! src/share/demo/jvmti/waiters/Agent.hpp
! src/share/demo/jvmti/waiters/Monitor.cpp
! src/share/demo/jvmti/waiters/Monitor.hpp
! src/share/demo/jvmti/waiters/Thread.cpp
! src/share/demo/jvmti/waiters/Thread.hpp
! src/share/demo/jvmti/waiters/sample.makefile.txt
! src/share/demo/jvmti/waiters/waiters.cpp
! src/share/demo/management/FullThreadDump/Deadlock.java
! src/share/demo/management/FullThreadDump/FullThreadDump.java
! src/share/demo/management/FullThreadDump/ThreadMonitor.java
! src/share/demo/management/JTop/JTop.java
! src/share/demo/management/JTop/JTopPlugin.java
! src/share/demo/management/MemoryMonitor/MemoryMonitor.java
! src/share/demo/management/MemoryMonitor/README.txt
! src/share/demo/management/VerboseGC/PrintGCStat.java
! src/share/demo/management/VerboseGC/VerboseGC.java
! src/share/demo/nbproject/project.xml
! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/JarFileSystemProvider.java
! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipCoder.java
! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java
! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileAttributes.java
! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileStore.java
! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java
! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java
! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java
! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipUtils.java
! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/EditableAtEndDocument.java
! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptJConsolePlugin.java
! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptShellPanel.java
! src/share/demo/scripting/jconsole-plugin/src/resources/jconsole.js
! src/share/demo/scripting/jconsole-plugin/src/scripts/heapdump.js
! src/share/demo/scripting/jconsole-plugin/src/scripts/hello.js
! src/share/demo/scripting/jconsole-plugin/src/scripts/invoke.js
! src/share/demo/scripting/jconsole-plugin/src/scripts/jstack.js
! src/share/demo/scripting/jconsole-plugin/src/scripts/jtop.js
! src/share/demo/scripting/jconsole-plugin/src/scripts/sysprops.js
! src/share/demo/scripting/jconsole-plugin/src/scripts/verbose.js
! src/share/instrument/JPLISAssert.h
! src/share/javavm/export/classfile_constants.h
! src/share/javavm/export/jawt.h
! src/share/javavm/export/jmm.h
! src/share/javavm/export/jvm.h
! src/share/native/com/sun/java/util/jar/pack/main.cpp
! src/share/native/common/check_code.c
! src/share/native/common/jdk_util.h
! src/share/native/java/io/ObjectInputStream.c
! src/share/native/java/io/io_util.h
! src/share/native/java/lang/System.c
! src/share/native/java/lang/Thread.c
! src/share/native/java/lang/fdlibm/include/fdlibm.h
! src/share/native/java/lang/fdlibm/include/jfdlibm.h
! src/share/native/java/lang/java_props.h
! src/share/native/java/util/zip/Adler32.c
! src/share/native/java/util/zip/CRC32.c
! src/share/native/java/util/zip/Deflater.c
! src/share/native/java/util/zip/Inflater.c
! src/share/native/java/util/zip/ZipFile.c
! src/share/native/java/util/zip/zip_util.c
! src/share/native/sun/misc/VM.c
! src/share/native/sun/nio/ch/genSocketOptionRegistry.c
! src/share/native/sun/security/ec/impl/ecc_impl.h
! src/share/native/sun/security/ec/impl/ecdecode.c
! src/share/native/sun/security/ec/impl/oid.c
! src/share/native/sun/security/ec/impl/secitem.c
! src/share/native/sun/security/krb5/nativeccache.c
! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c
! src/share/native/sun/security/pkcs11/wrapper/p11_dual.c
! src/share/native/sun/security/pkcs11/wrapper/p11_general.c
! src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c
! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c
! src/share/native/sun/security/pkcs11/wrapper/p11_objmgmt.c
! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c
! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c
! src/share/native/sun/security/pkcs11/wrapper/p11_util.c
! src/share/npt/utf.h
! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/DirectoryScanner.java
! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/DirectoryScannerMXBean.java
! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ResultLogManager.java
! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ResultLogManagerMXBean.java
! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirAgent.java
! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirClient.java
! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirConfig.java
! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirConfigMXBean.java
! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanManager.java
! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanManagerMXBean.java
! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/DirectoryScannerConfig.java
! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/FileMatch.java
! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/ResultLogConfig.java
! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/ResultRecord.java
! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/ScanManagerConfig.java
! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/XmlConfigUtils.java
! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/DirectoryScannerTest.java
! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/ScanDirConfigTest.java
! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/ScanManagerTest.java
! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/TestUtils.java
! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/config/XmlConfigUtilsTest.java
! src/share/sample/nio/multicast/MulticastAddress.java
! src/share/sample/nio/multicast/Reader.java
! src/share/sample/nio/multicast/Sender.java
! src/share/sample/nio/server/AcceptHandler.java
! src/share/sample/nio/server/Acceptor.java
! src/share/sample/nio/server/B1.java
! src/share/sample/nio/server/BN.java
! src/share/sample/nio/server/BP.java
! src/share/sample/nio/server/ChannelIO.java
! src/share/sample/nio/server/ChannelIOSecure.java
! src/share/sample/nio/server/Content.java
! src/share/sample/nio/server/Dispatcher.java
! src/share/sample/nio/server/Dispatcher1.java
! src/share/sample/nio/server/DispatcherN.java
! src/share/sample/nio/server/FileContent.java
! src/share/sample/nio/server/Handler.java
! src/share/sample/nio/server/MalformedRequestException.java
! src/share/sample/nio/server/N1.java
! src/share/sample/nio/server/N2.java
! src/share/sample/nio/server/Reply.java
! src/share/sample/nio/server/Request.java
! src/share/sample/nio/server/RequestHandler.java
! src/share/sample/nio/server/RequestServicer.java
! src/share/sample/nio/server/Sendable.java
! src/share/sample/nio/server/Server.java
! src/share/sample/nio/server/StringContent.java
! src/share/sample/nio/server/URLDumper.java
! src/share/sample/scripting/scriptpad/src/com/sun/sample/scriptpad/Main.java
! src/share/sample/scripting/scriptpad/src/resources/Main.js
! src/share/sample/scripting/scriptpad/src/resources/conc.js
! src/share/sample/scripting/scriptpad/src/resources/gui.js
! src/share/sample/scripting/scriptpad/src/resources/mm.js
! src/share/sample/scripting/scriptpad/src/resources/scriptpad.js
! src/share/sample/scripting/scriptpad/src/scripts/browse.js
! src/share/sample/scripting/scriptpad/src/scripts/insertfile.js
! src/share/sample/scripting/scriptpad/src/scripts/linewrap.js
! src/share/sample/scripting/scriptpad/src/scripts/mail.js
! src/share/sample/scripting/scriptpad/src/scripts/memmonitor.js
! src/share/sample/scripting/scriptpad/src/scripts/memory.js
! src/share/sample/scripting/scriptpad/src/scripts/textcolor.js
! src/share/sample/vm/clr-jvm/invoked.java
! src/share/sample/vm/clr-jvm/jinvoker.cpp
! src/share/sample/vm/clr-jvm/jinvokerExp.h
! src/share/sample/vm/jvm-clr/invoker.cpp
! src/share/sample/vm/jvm-clr/invoker.h
! src/share/sample/vm/jvm-clr/invoker.java
! src/share/sample/vm/jvm-clr/invokerExp.h
! src/share/transport/shmem/shmemBase.h
! src/share/transport/socket/socketTransport.c
! src/solaris/back/exec_md.c
! src/solaris/back/linker_md.c
! src/solaris/back/util_md.h
! src/solaris/bin/arm/jvm.cfg
! src/solaris/bin/i586/jvm.cfg
! src/solaris/bin/ppc/jvm.cfg
! src/solaris/bin/sparc/jvm.cfg
! src/solaris/classes/com/sun/management/UnixOperatingSystem.java
! src/solaris/classes/java/lang/ProcessEnvironment.java
! src/solaris/classes/java/lang/Terminator.java
! src/solaris/classes/java/net/DefaultInterface.java
! src/solaris/classes/sun/management/FileSystemImpl.java
! src/solaris/classes/sun/net/dns/ResolverConfigurationImpl.java
! src/solaris/classes/sun/nio/ch/DefaultSelectorProvider.java
! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java
! src/solaris/classes/sun/nio/ch/DevPollSelectorProvider.java
! src/solaris/classes/sun/nio/ch/EPoll.java
! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java
! src/solaris/classes/sun/nio/ch/InheritedChannel.java
! src/solaris/classes/sun/nio/ch/NativeThread.java
! src/solaris/classes/sun/nio/ch/PollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/SolarisEventPort.java
! src/solaris/classes/sun/nio/ch/sctp/AssociationChange.java
! src/solaris/classes/sun/nio/ch/sctp/AssociationImpl.java
! src/solaris/classes/sun/nio/ch/sctp/PeerAddrChange.java
! src/solaris/classes/sun/nio/ch/sctp/ResultContainer.java
! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java
! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java
! src/solaris/classes/sun/nio/ch/sctp/SctpNet.java
! src/solaris/classes/sun/nio/ch/sctp/SctpNotification.java
! src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java
! src/solaris/classes/sun/nio/ch/sctp/SendFailed.java
! src/solaris/classes/sun/nio/ch/sctp/Shutdown.java
! src/solaris/classes/sun/nio/fs/BsdFileStore.java
! src/solaris/classes/sun/nio/fs/BsdFileSystem.java
! src/solaris/classes/sun/nio/fs/BsdFileSystemProvider.java
! src/solaris/classes/sun/nio/fs/BsdNativeDispatcher.java
! src/solaris/classes/sun/nio/fs/DefaultFileTypeDetector.java
! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java
! src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java
! src/solaris/classes/sun/nio/fs/LinuxNativeDispatcher.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/SolarisFileSystem.java
! src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java
! src/solaris/classes/sun/nio/fs/SolarisNativeDispatcher.java
! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java
! src/solaris/classes/sun/nio/fs/UnixFileSystem.java
! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java
! src/solaris/classes/sun/print/CUPSPrinter.java
! src/solaris/classes/sun/security/smartcardio/PlatformPCSC.java
! src/solaris/classes/sun/tools/attach/BsdAttachProvider.java
! src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java
! src/solaris/classes/sun/tools/attach/SolarisVirtualMachine.java
! src/solaris/demo/jni/Poller/Client.java
! src/solaris/demo/jni/Poller/LinkedQueue.java
! src/solaris/demo/jni/Poller/Poller.c
! src/solaris/demo/jni/Poller/Poller.java
! src/solaris/demo/jni/Poller/PollingServer.java
! src/solaris/demo/jni/Poller/SimpleServer.java
! src/solaris/demo/jvmti/hprof/hprof_md.c
! src/solaris/doc/sun/man/man1/jcmd.1
! src/solaris/instrument/EncodingSupport_md.c
! src/solaris/javavm/export/jvm_md.h
! src/solaris/native/com/sun/management/MacosxOperatingSystem.c
! src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
! src/solaris/native/com/sun/security/auth/module/Unix.c
! src/solaris/native/java/io/UnixFileSystem_md.c
! src/solaris/native/java/io/canonicalize_md.c
! src/solaris/native/java/io/io_util_md.c
! src/solaris/native/java/io/io_util_md.h
! src/solaris/native/java/lang/ProcessEnvironment_md.c
! src/solaris/native/java/lang/java_props_macosx.c
! src/solaris/native/java/lang/java_props_macosx.h
! src/solaris/native/java/lang/java_props_md.c
! src/solaris/native/java/net/Inet4AddressImpl.c
! src/solaris/native/java/net/NetworkInterface.c
! src/solaris/native/java/net/PlainDatagramSocketImpl.c
! src/solaris/native/java/net/PlainSocketImpl.c
! src/solaris/native/java/net/SocketInputStream.c
! src/solaris/native/java/net/bsd_close.c
! src/solaris/native/java/net/net_util_md.h
! src/solaris/native/java/util/FileSystemPreferences.c
! src/solaris/native/sun/jdga/dgalock.c
! src/solaris/native/sun/management/FileSystemImpl.c
! src/solaris/native/sun/net/dns/ResolverConfigurationImpl.c
! src/solaris/native/sun/net/spi/DefaultProxySelector.c
! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c
! src/solaris/native/sun/nio/ch/DatagramDispatcher.c
! src/solaris/native/sun/nio/ch/DevPollArrayWrapper.c
! src/solaris/native/sun/nio/ch/EPoll.c
! src/solaris/native/sun/nio/ch/EPollArrayWrapper.c
! src/solaris/native/sun/nio/ch/FileChannelImpl.c
! src/solaris/native/sun/nio/ch/FileDispatcherImpl.c
! src/solaris/native/sun/nio/ch/FileKey.c
! src/solaris/native/sun/nio/ch/IOUtil.c
! src/solaris/native/sun/nio/ch/Net.c
! src/solaris/native/sun/nio/ch/SolarisEventPort.c
! src/solaris/native/sun/nio/ch/sctp/Sctp.h
! src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c
! src/solaris/native/sun/nio/ch/sctp/SctpNet.c
! src/solaris/native/sun/nio/ch/sctp/SctpServerChannelImpl.c
! src/solaris/native/sun/nio/fs/BsdNativeDispatcher.c
! src/solaris/native/sun/nio/fs/GnomeFileTypeDetector.c
! src/solaris/native/sun/nio/fs/LinuxNativeDispatcher.c
! src/solaris/native/sun/nio/fs/LinuxWatchService.c
! src/solaris/native/sun/nio/fs/MacOSXNativeDispatcher.c
! src/solaris/native/sun/nio/fs/SolarisNativeDispatcher.c
! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c
! src/solaris/native/sun/nio/fs/genSolarisConstants.c
! src/solaris/native/sun/nio/fs/genUnixConstants.c
! src/solaris/native/sun/security/jgss/wrapper/NativeFunc.c
! src/solaris/native/sun/security/pkcs11/j2secmod_md.c
! src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c
! src/solaris/native/sun/security/smartcardio/pcsc_md.c
! src/solaris/npt/npt_md.h
! src/solaris/transport/socket/socket_md.c
! src/windows/classes/com/sun/management/OperatingSystem.java
! src/windows/classes/java/lang/ProcessEnvironment.java
! src/windows/classes/java/lang/Terminator.java
! src/windows/classes/java/net/DefaultInterface.java
! src/windows/classes/java/net/TwoStacksPlainSocketImpl.java
! src/windows/classes/sun/management/FileSystemImpl.java
! src/windows/classes/sun/net/dns/ResolverConfigurationImpl.java
! src/windows/classes/sun/nio/ch/NativeThread.java
! src/windows/classes/sun/nio/ch/SocketDispatcher.java
! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java
! src/windows/classes/sun/nio/ch/sctp/SctpChannelImpl.java
! src/windows/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java
! src/windows/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java
! src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java
! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java
! src/windows/classes/sun/print/Win32PrintServiceLookup.java
! src/windows/classes/sun/security/krb5/internal/tools/Kinit.java
! src/windows/classes/sun/security/krb5/internal/tools/KinitOptions.java
! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java
! src/windows/classes/sun/security/smartcardio/PlatformPCSC.java
! src/windows/classes/sun/tools/attach/WindowsAttachProvider.java
! src/windows/native/java/io/WinNTFileSystem_md.c
! src/windows/native/java/io/io_util_md.h
! src/windows/native/java/lang/java_props_md.c
! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c
! src/windows/native/java/net/Inet6AddressImpl.c
! src/windows/native/java/net/NetworkInterface.c
! src/windows/native/java/net/NetworkInterface.h
! src/windows/native/java/net/NetworkInterface_winXP.c
! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c
! src/windows/native/java/net/TwoStacksPlainSocketImpl.c
! src/windows/native/java/net/net_util_md.c
! src/windows/native/java/net/net_util_md.h
! src/windows/native/sun/management/FileSystemImpl.c
! src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.c
! src/windows/native/sun/nio/ch/DatagramChannelImpl.c
! src/windows/native/sun/nio/ch/IOUtil.c
! src/windows/native/sun/nio/ch/Net.c
! src/windows/native/sun/nio/ch/SocketDispatcher.c
! src/windows/native/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.c
! src/windows/native/sun/nio/ch/nio_util.h
! src/windows/native/sun/security/krb5/NativeCreds.c
! src/windows/native/sun/security/pkcs11/j2secmod_md.c
! src/windows/native/sun/security/provider/WinCAPISeedGenerator.c
! src/windows/native/sun/tools/attach/WindowsAttachProvider.c
! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c
! src/windows/native/sun/tracing/dtrace/jvm_symbols_md.c
! src/windows/npt/npt_md.h
! src/windows/transport/shmem/shmem_md.c
! test/com/sun/crypto/provider/Cipher/DES/PaddingTest.java
! test/com/sun/crypto/provider/KeyGenerator/Test4628062.java
! test/com/sun/jdi/ConnectedVMs.java
! test/com/sun/jdi/EarlyReturnTest.java
! test/com/sun/jdi/ImmutableResourceTest.sh
! test/com/sun/jdi/JITDebug.sh
! test/com/sun/jdi/MethodEntryExitEvents.java
! test/com/sun/jdi/MethodExitReturnValuesTest.java
! test/com/sun/jdi/PrivateTransportTest.sh
! test/com/sun/jdi/ShellScaffold.sh
! test/com/sun/jdi/Solaris32AndSolaris64Test.sh
! test/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh
! test/com/sun/jndi/ldap/LdapTimeoutTest.java
! test/com/sun/management/OperatingSystemMXBean/TestTotalSwap.sh
! test/com/sun/net/httpserver/Test1.java
! test/com/sun/net/httpserver/Test10.java
! test/com/sun/net/httpserver/bugs/B6373555.java
! test/com/sun/nio/sctp/SctpChannel/SocketOptionTests.java
! test/com/sun/nio/sctp/SctpMultiChannel/SocketOptionTests.java
! test/com/sun/security/auth/login/ConfigFile/IllegalURL.java
! test/com/sun/servicetag/JavaServiceTagTest.java
! test/com/sun/servicetag/JavaServiceTagTest1.java
! test/com/sun/tools/attach/CommonSetup.sh
! test/demo/zipfs/basic.sh
! test/java/io/File/MaxPathLength.java
! test/java/io/File/basic.sh
! test/java/io/FileInputStream/LargeFileAvailable.java
! test/java/io/IOException/LastErrorString.java
! test/java/io/Serializable/badSubstByReplace/BadSubstByReplace.java
! test/java/io/Serializable/evolution/RenamePackage/run.sh
! test/java/io/Serializable/expectedStackTrace/ExpectedStackTrace.java
! test/java/io/Serializable/replaceStringArray/ReplaceStringArray.java
! test/java/io/Serializable/replaceWithNull/ReplaceWithNull.java
! test/java/io/Serializable/serialver/classpath/run.sh
! test/java/io/Serializable/serialver/nested/run.sh
! test/java/io/Serializable/verifyDynamicObjHandleTable/VerifyDynamicObjHandleTable.java
! test/java/lang/Character/CheckProp.java
! test/java/lang/Character/CheckScript.java
! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh
! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh
! test/java/lang/Double/ToHexString.java
! test/java/lang/Runtime/exec/StreamsSurviveDestroy.java
! test/java/lang/StringCoding/CheckEncodings.sh
! test/java/lang/ThreadGroup/NullThreadName.java
! test/java/lang/ThreadGroup/Stop.java
! test/java/lang/annotation/loaderLeak/LoaderLeak.sh
! test/java/lang/annotation/loaderLeak/Main.java
! test/java/lang/instrument/appendToClassLoaderSearch/CommonSetup.sh
! test/java/lang/invoke/CallSiteTest.java
! test/java/lang/invoke/ClassValueTest.java
! test/java/lang/invoke/JavaDocExamplesTest.java
! test/java/lang/invoke/MethodHandlesTest.java
! test/java/lang/invoke/MethodTypeTest.java
! test/java/lang/invoke/PrivateInvokeTest.java
! test/java/lang/invoke/RicochetTest.java
! test/java/lang/invoke/ThrowExceptionsTest.java
! test/java/lang/management/BufferPoolMXBean/Basic.java
! test/java/lang/management/ManagementFactory/GetPlatformMXBeans.java
! test/java/lang/management/ManagementFactory/MBeanServerMXBeanUnsupportedTest.java
! test/java/lang/management/ManagementFactory/ThreadMXBeanProxy.java
! test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java
! test/java/lang/management/MemoryMXBean/MemoryTest.java
! test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh
! test/java/lang/management/PlatformLoggingMXBean/PlatformLoggingMXBeanTest.java
! test/java/lang/ref/Basic.java
! test/java/net/Authenticator/B4678055.java
! test/java/net/Authenticator/B4722333.java
! test/java/net/Authenticator/B4759514.java
! test/java/net/Authenticator/B4769350.java
! test/java/net/Authenticator/B4921848.java
! test/java/net/Authenticator/B4933582.java
! test/java/net/Authenticator/B4933582.sh
! test/java/net/Authenticator/B4962064.java
! test/java/net/CookieHandler/CookieManagerTest.java
! test/java/net/CookieHandler/NullUriCookieTest.java
! test/java/net/CookieHandler/TestHttpCookie.java
! test/java/net/DatagramPacket/ReuseBuf.java
! test/java/net/DatagramSocket/Send12k.java
! test/java/net/DatagramSocket/SendDatagramToBadAddress.java
! test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh
! test/java/net/InetAddress/GetLocalHostWithSM.java
! test/java/net/NetworkInterface/NetParamsTest.java
! test/java/net/ProxySelector/LoopbackAddresses.java
! test/java/net/ProxySelector/ProxyTest.java
! test/java/net/Socket/OldSocketImpl.sh
! test/java/net/Socket/setReuseAddress/Basic.java
! test/java/net/Socket/setReuseAddress/Restart.java
! test/java/net/Socks/SocksServer.java
! test/java/net/Socks/SocksV4Test.java
! test/java/net/URL/B5086147.sh
! test/java/net/URL/OpenStream.java
! test/java/net/URL/PerConnectionProxy.java
! test/java/net/URL/Test.java
! test/java/net/URL/runconstructor.sh
! test/java/net/URLClassLoader/B5077773.sh
! test/java/net/URLClassLoader/closetest/CloseTest.java
! test/java/net/URLClassLoader/sealing/checksealed.sh
! test/java/net/URLConnection/6212146/test.sh
! test/java/net/URLConnection/B5052093.java
! test/java/net/URLConnection/Redirect307Test.java
! test/java/nio/Buffer/Basic-X.java.template
! test/java/nio/Buffer/Basic.java
! test/java/nio/Buffer/BasicByte.java
! test/java/nio/Buffer/BasicChar.java
! test/java/nio/Buffer/BasicDouble.java
! test/java/nio/Buffer/BasicFloat.java
! test/java/nio/Buffer/BasicInt.java
! test/java/nio/Buffer/BasicLong.java
! test/java/nio/Buffer/BasicShort.java
! test/java/nio/MappedByteBuffer/Truncate.java
! test/java/nio/channels/AsynchronousChannelGroup/AsExecutor.java
! test/java/nio/channels/AsynchronousChannelGroup/Basic.java
! test/java/nio/channels/AsynchronousChannelGroup/Restart.java
! test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java
! test/java/nio/channels/DatagramChannel/BasicMulticastTests.java
! test/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java
! test/java/nio/channels/DatagramChannel/NetworkConfiguration.java
! test/java/nio/channels/DatagramChannel/Refused.java
! test/java/nio/channels/DatagramChannel/SelectWhenRefused.java
! test/java/nio/channels/DatagramChannel/SocketOptionTests.java
! test/java/nio/channels/FileChannel/ClosedByInterrupt.java
! test/java/nio/channels/Selector/OpRead.java
! test/java/nio/channels/Selector/lots_of_updates.sh
! test/java/nio/channels/ServerSocketChannel/SocketOptionTests.java
! test/java/nio/channels/SocketChannel/AdaptSocket.java
! test/java/nio/channels/SocketChannel/Open.sh
! test/java/nio/channels/SocketChannel/Shutdown.java
! test/java/nio/channels/SocketChannel/SocketOptionTests.java
! test/java/nio/channels/TestUtil.java
! test/java/nio/charset/Charset/NIOCharsetAvailabilityTest.java
! test/java/nio/charset/coders/CheckSJISMappingProp.sh
! test/java/nio/charset/coders/Errors.java
! test/java/nio/charset/spi/basic.sh
! test/java/nio/file/Files/CustomOptions.java
! test/java/nio/file/Path/PathOps.java
! test/java/nio/file/WatchService/Basic.java
! test/java/nio/file/WatchService/SensitivityModifier.java
! test/java/nio/file/WatchService/WithSecurityManager.java
! test/java/rmi/activation/checkusage/CheckUsage.java
! test/java/rmi/testlibrary/JavaVM.java
! test/java/rmi/transport/pinLastArguments/PinLastArguments.java
! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh
! test/java/security/Security/ClassLoaderDeadlock/Deadlock.sh
! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh
! test/java/security/Security/signedfirst/Dyn.sh
! test/java/security/Security/signedfirst/Static.sh
! test/java/text/Bidi/Bug6850113.java
! test/java/util/Collection/BiggernYours.java
! test/java/util/Collections/EmptyIterator.java
! test/java/util/Currency/CurrencyTest.java
! test/java/util/Hashtable/HashCode.java
! test/java/util/Hashtable/SimpleSerialization.java
! test/java/util/Locale/Bug6989440.java
! test/java/util/Locale/LocaleCategory.sh
! test/java/util/Map/Get.java
! test/java/util/PluggableLocale/CurrencyNameProviderTest.sh
! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.sh
! test/java/util/PluggableLocale/ExecTest.sh
! test/java/util/PluggableLocale/LocaleNameProviderTest.sh
! test/java/util/PluggableLocale/ProviderTest.java
! test/java/util/PluggableLocale/providersrc/DateFormatSymbolsProviderImpl.java
! test/java/util/PluggableLocale/providersrc/LocaleNameProviderImpl.java
! test/java/util/ResourceBundle/Bug4168625Test.java
! test/java/util/ResourceBundle/Bug6299235Test.sh
! test/java/util/ResourceBundle/Control/Bug6530694.java
! test/java/util/ServiceLoader/basic.sh
! test/java/util/Timer/Args.java
! test/java/util/Timer/KillThread.java
! test/java/util/UUID/UUIDTest.java
! test/java/util/concurrent/FutureTask/BlockingTaskExecutor.java
! test/java/util/concurrent/ThreadPoolExecutor/Custom.java
! test/java/util/concurrent/locks/Lock/FlakyMutex.java
! test/java/util/concurrent/locks/Lock/TimedAcquireLeak.java
! test/java/util/logging/LoggingDeadlock4.java
! test/java/util/regex/RegExTest.java
! test/java/util/zip/ZipFile/ManyZipFiles.java
! test/javax/crypto/SecretKeyFactory/FailOverTest.sh
! test/javax/imageio/stream/StreamCloserLeak/run_test.sh
! test/javax/management/remote/mandatory/URLTest.java
! test/javax/management/remote/mandatory/notif/ListenerScaleTest.java
! test/javax/naming/spi/DirectoryManager/GetContDirCtx.java
! test/javax/script/CommonSetup.sh
! test/javax/security/auth/Subject/Synch.java
! test/javax/security/auth/Subject/Synch2.java
! test/javax/security/auth/Subject/Synch3.java
! test/javax/security/auth/Subject/doAs/Test.sh
! test/javax/security/auth/login/LoginContext/ResetConfigModule.java
! test/javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java
! test/lib/security/java.policy/Ext_AllPolicy.sh
! test/sun/invoke/util/ValueConversionsTest.java
! test/sun/misc/Cleaner/exitOnThrow.sh
! test/sun/misc/Version/Version.java
! test/sun/net/www/AuthHeaderTest.java
! test/sun/net/www/MarkResetTest.sh
! test/sun/net/www/http/ChunkedInputStream/ChunkedEncodingWithProgressMonitorTest.java
! test/sun/net/www/http/HttpClient/RetryPost.sh
! test/sun/net/www/http/KeepAliveCache/B5045306.java
! test/sun/net/www/httptest/HttpTransaction.java
! test/sun/net/www/httptest/TestHttpServer.java
! test/sun/net/www/protocol/file/DirPermissionDenied.sh
! test/sun/net/www/protocol/http/B6296310.java
! test/sun/net/www/protocol/http/B6299712.java
! test/sun/net/www/protocol/http/RelativeRedirect.java
! test/sun/net/www/protocol/http/ResponseCacheStream.java
! test/sun/net/www/protocol/http/SetChunkedStreamingMode.java
! test/sun/net/www/protocol/jar/B5105410.sh
! test/sun/net/www/protocol/jar/jarbug/run.sh
! 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/StrCodingBenchmark.java
! test/sun/nio/cs/StrCodingBenchmarkDB.java
! test/sun/nio/cs/TestCp834_SBCS.java
! test/sun/nio/cs/TestStringCoding.java
! test/sun/nio/cs/TestUTF8.java
! test/sun/nio/cs/TestX11JIS0201.java
! test/sun/security/krb5/ConfPlusProp.java
! test/sun/security/krb5/DnsFallback.java
! test/sun/security/krb5/Krb5NameEquals.java
! test/sun/security/krb5/ParseConfig.java
! 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
! test/sun/security/krb5/auto/BasicKrb5Test.java
! test/sun/security/krb5/auto/Context.java
! test/sun/security/krb5/auto/MaxRetries.java
! test/sun/security/krb5/auto/OneKDC.java
! test/sun/security/krb5/auto/SSL.java
! test/sun/security/krb5/auto/TcpTimeout.java
! test/sun/security/krb5/auto/W83.java
! test/sun/security/krb5/runNameEquals.sh
! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh
! test/sun/security/pkcs11/Provider/ConfigQuotedString.sh
! test/sun/security/pkcs11/Provider/Login.sh
! test/sun/security/pkcs11/Secmod/AddPrivateKey.java
! test/sun/security/pkcs11/Secmod/AddTrustedCert.java
! test/sun/security/pkcs11/Secmod/Crypto.java
! test/sun/security/pkcs11/Secmod/GetPrivateKey.java
! test/sun/security/pkcs11/Secmod/JksSetPrivateKey.java
! test/sun/security/pkcs11/Secmod/TrustAnchors.java
! test/sun/security/pkcs11/SecmodTest.java
! test/sun/security/pkcs11/ec/ReadCertificates.java
! test/sun/security/pkcs11/ec/ReadPKCS12.java
! test/sun/security/pkcs11/ec/TestECDH.java
! test/sun/security/pkcs11/ec/TestECDSA.java
! test/sun/security/pkcs11/fips/TrustManagerTest.java
! test/sun/security/pkcs11/rsa/TestCACerts.java
! test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java
! test/sun/security/pkcs12/PKCS12SameKeyId.java
! test/sun/security/provider/DSA/TestKeyPairGenerator.java
! test/sun/security/provider/PolicyFile/Comparator.java
! test/sun/security/provider/PolicyFile/getinstance/getinstance.sh
! test/sun/security/provider/X509Factory/BigCRL.java
! test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/ProviderTest.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadBlocksClose.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadHandshake.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadZeroBytes.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/RemoveMarkReset.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppOutputStream/NoExceptionOnClose.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/CipherSuiteOrder.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/RSAExport.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/HandshakeOutStream/NullCerts.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/SSLSocketTimeoutNulls.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/BadKSProvider.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/BadTSProvider.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/GoodProvider.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/RehandshakeFinished.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineDeadlock.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSessionImpl/HashCodeMissing.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/AsyncSSLSocketClose.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientModeClientAuth.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientTimeout.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/CloseSocketException.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NewSocketMethods.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NonAutoClose.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ReuseAddr.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ReverseNameLookup.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ServerTimeout.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SetClientMode.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/UnconnectedSocketWrongExceptions.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHost.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SocketCreation/SocketCreation.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/ClientServer.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/PKIXExtendedTM.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SunX509ExtendedTM.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/X509ExtendedTMEnabled.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/spi/ProviderInit.java
! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/CriticalSubjectAltName.java
! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/GetResponseCode.java
! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/ImplicitHandshake.java
! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/SSLSessionNulls.java
! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/SSLSocketInherit.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/CheckMyTrustedKeystore.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/HttpsURLConnectionLocalCertificateChain.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/JSSERenegotiate.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLCtxAccessToSessCtx.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/AcceptLargeFragments.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ExtendedKeySocket.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngineResult/Deserialize.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/testEnabledProtocols.java
! test/sun/security/ssl/javax/net/ssl/TLSv11/EmptyCertificateAuthorities.java
! test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableBlockCipher.java
! test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableStreamCipher.java
! test/sun/security/ssl/javax/net/ssl/TLSv11/GenericBlockCipher.java
! test/sun/security/ssl/javax/net/ssl/TLSv11/GenericStreamCipher.java
! test/sun/security/ssl/sanity/pluggability/CheckSSLContextExport.java
! test/sun/security/ssl/sun/net/www/http/ChunkedOutputStream/Test.java
! test/sun/security/ssl/sun/net/www/httpstest/HttpTransaction.java
! test/sun/security/ssl/sun/net/www/httpstest/TestHttpsServer.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsCreateSockTest.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsSocketFacTest.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh
! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/ComHostnameVerifier.java
! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/JavaxHostnameVerifier.java
! test/sun/security/ssl/templates/SSLEngineTemplate.java
! test/sun/security/ssl/templates/SSLSocketTemplate.java
! test/sun/security/tools/jarsigner/AlgOptions.sh
! test/sun/security/tools/jarsigner/JarSigningNonAscii.java
! test/sun/security/tools/jarsigner/LargeJarEntry.java
! test/sun/security/tools/jarsigner/PercentSign.sh
! test/sun/security/tools/jarsigner/concise_jarsigner.sh
! test/sun/security/tools/jarsigner/diffend.sh
! test/sun/security/tools/jarsigner/oldsig.sh
! test/sun/security/tools/keytool/AltProviderPath.sh
! test/sun/security/tools/keytool/CloneKeyAskPassword.sh
! test/sun/security/tools/keytool/NoExtNPE.sh
! test/sun/security/tools/keytool/SecretKeyKS.sh
! test/sun/security/tools/keytool/StandardAlgName.sh
! test/sun/security/tools/keytool/i18n.sh
! test/sun/security/tools/keytool/printssl.sh
! test/sun/security/tools/keytool/resource.sh
! test/sun/security/tools/keytool/standard.sh
! test/sun/security/tools/policytool/Alias.sh
! test/sun/security/tools/policytool/ChangeUI.sh
! test/sun/security/tools/policytool/OpenPolicy.sh
! test/sun/security/tools/policytool/SaveAs.sh
! test/sun/security/tools/policytool/UpdatePermissions.sh
! test/sun/security/tools/policytool/UsePolicy.sh
! test/sun/security/tools/policytool/i18n.sh
! test/sun/security/util/Oid/S11N.sh
! test/sun/security/util/Resources/NewNamesFormat.java
! test/sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java
! test/sun/tools/common/CommonSetup.sh
! test/sun/tools/jcmd/jcmd-Defaults.sh
! test/sun/tools/jcmd/jcmd-f.sh
! test/sun/tools/jcmd/jcmd-help-help.sh
! test/sun/tools/jcmd/jcmd-help.sh
! test/sun/tools/jcmd/jcmd-pid.sh
! test/sun/tools/jconsole/ImmutableResourceTest.sh
! test/sun/tools/jinfo/Basic.sh
! test/sun/tools/jrunscript/common.sh
! test/sun/tools/jrunscript/jrunscript-argsTest.sh
! test/sun/tools/jrunscript/jrunscript-eTest.sh
! test/sun/tools/jrunscript/jrunscript-fTest.sh
! test/sun/tools/jrunscript/jrunscriptTest.sh
! test/sun/tools/native2ascii/resources/ImmutableResourceTest.sh
! test/sun/util/logging/PlatformLoggerTest.java
! test/tools/launcher/DefaultLocaleTest.java
! test/tools/pack200/CommandLineTests.java
! test/tools/pack200/TimeStamp.java

Changeset: 6ffd64541a6c
Author:    lana
Date:      2012-11-02 17:44 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/6ffd64541a6c

Merge

- make/sun/jdbc/Makefile
! makefiles/CompileJavaClasses.gmk
! makefiles/CompileNativeLibraries.gmk
! makefiles/CopyIntoClasses.gmk
! makefiles/CreateJars.gmk
! makefiles/GendataBreakIterator.gmk
! makefiles/GensrcLocaleDataMetaInfo.gmk
! makefiles/GensrcMisc.gmk
! makefiles/GensrcSwing.gmk
! makefiles/mapfiles/libnio/mapfile-linux
! makefiles/mapfiles/libnio/mapfile-macosx
! makefiles/mapfiles/libnio/mapfile-solaris
- src/solaris/native/java/io/FileSystem_md.c
- src/windows/native/java/io/FileSystem_md.c
! test/javax/imageio/stream/StreamCloserLeak/run_test.sh

Changeset: 26dbd73fb766
Author:    katleman
Date:      2012-11-07 15:39 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/26dbd73fb766

Merge

! makefiles/CompileJavaClasses.gmk
! makefiles/CompileNativeLibraries.gmk
! makefiles/CreateJars.gmk

Changeset: 3717bcf9d7a7
Author:    dholmes
Date:      2012-11-07 23:12 -0500
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/3717bcf9d7a7

8002040: Allow Full Debug Symbols when cross-compiling
Reviewed-by: dcubed, erikj, tbell

! make/common/Defs-linux.gmk

Changeset: 1e79fec4a01f
Author:    ohrstrom
Date:      2012-11-08 12:25 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/1e79fec4a01f

8003161: small fixes to re-enable new build system
Reviewed-by: dholmes, alanb, erikj

! makefiles/CompileNativeLibraries.gmk
! makefiles/CreateJars.gmk

Changeset: 3201a4f42ee4
Author:    erikj
Date:      2012-11-08 13:56 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/3201a4f42ee4

Merge

! make/com/sun/java/pack/Makefile
! make/common/Demo.gmk
! make/common/internal/NativeCompileRules.gmk
! make/tools/reorder/Makefile
! make/tools/src/build/tools/compileproperties/CompileProperties.java
! make/tools/src/build/tools/stripproperties/StripProperties.java
! makefiles/CompileJavaClasses.gmk
! makefiles/CompileNativeLibraries.gmk
! makefiles/CopyIntoClasses.gmk
! makefiles/CreateJars.gmk
! makefiles/GendataBreakIterator.gmk
! makefiles/GendataTimeZone.gmk
! makefiles/GensrcLocaleDataMetaInfo.gmk
! makefiles/GensrcMisc.gmk
! makefiles/GensrcSwing.gmk
! makefiles/jprt.properties
! makefiles/mapfiles/launchers/mapfile-x86
! makefiles/mapfiles/launchers/mapfile-x86_64
! makefiles/mapfiles/libnio/mapfile-macosx
! makefiles/mapfiles/libsctp/mapfile-vers
! makefiles/mapfiles/libzip/mapfile-vers
! makefiles/scripts/genCharsetProvider.sh
! makefiles/scripts/genExceptions.sh
! makefiles/scripts/localelist.sh
! src/share/back/error_messages.h
! src/share/back/log_messages.h
! src/share/classes/sun/nio/ch/IOStatus.java
! src/share/classes/sun/nio/ch/sctp/SctpStdSocketOption.java
! src/share/demo/jvmti/hprof/hprof_error.h
! src/share/demo/jvmti/hprof/hprof_init.c
! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c
! src/share/instrument/JPLISAssert.h
! src/share/npt/utf.h
! src/share/transport/shmem/shmemBase.h
! src/solaris/classes/sun/nio/ch/sctp/AssociationChange.java
! src/solaris/classes/sun/nio/ch/sctp/PeerAddrChange.java
! src/solaris/classes/sun/nio/ch/sctp/ResultContainer.java
! src/solaris/instrument/EncodingSupport_md.c
- src/solaris/native/java/io/FileSystem_md.c
- src/windows/native/java/io/FileSystem_md.c



From erik.joelsson at oracle.com  Thu Nov  8 06:37:49 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 08 Nov 2012 14:37:49 +0000
Subject: hg: build-infra/jdk8: Improved description of import-hotspot parameter
Message-ID: <20121108143749.CD0DC47854@hg.openjdk.java.net>

Changeset: e3e5a1039192
Author:    erikj
Date:      2012-11-08 15:36 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/e3e5a1039192

Improved description of import-hotspot parameter

! common/autoconf/generated-configure.sh
! common/autoconf/source-dirs.m4
! common/makefiles/Main.gmk



From erik.joelsson at oracle.com  Thu Nov  8 07:21:34 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 08 Nov 2012 15:21:34 +0000
Subject: hg: build-infra/jdk8/jdk: 8003177 - Fixed diff in LocaleDataMetaInfo.
Message-ID: <20121108152147.7E1E747855@hg.openjdk.java.net>

Changeset: 5f4b83f939be
Author:    erikj
Date:      2012-11-08 16:21 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/5f4b83f939be

8003177 - Fixed diff in LocaleDataMetaInfo.

! makefiles/GensrcLocaleDataMetaInfo.gmk



From erik.joelsson at oracle.com  Thu Nov  8 08:47:05 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 08 Nov 2012 16:47:05 +0000
Subject: hg: build-infra/jdk8/jdk: Fixed hotspot import on solaris.
Message-ID: <20121108164717.20EB847856@hg.openjdk.java.net>

Changeset: a41ca816e110
Author:    erikj
Date:      2012-11-08 17:46 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/a41ca816e110

Fixed hotspot import on solaris.

! makefiles/Import.gmk



From jonathan.gibbons at oracle.com  Thu Nov  8 12:03:32 2012
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 08 Nov 2012 12:03:32 -0800
Subject: Fwd: New builds from the build-infra team
In-Reply-To: <AA30E7CB-8CF3-4254-8855-57F17D239B80@oracle.com>
References: <DCA50F95-9C8E-45BB-86BE-6BE322E1E916@oracle.com>
	<AA30E7CB-8CF3-4254-8855-57F17D239B80@oracle.com>
Message-ID: <509C1014.9020201@oracle.com>

I'm trying to use the new build system.

I'm working in a langtools repo, and I have a full shared TL forest 
elsewhere on my system.

In my langtools repo, I've created a build directory and I've executed 
the configure script from the shared TL forest, specifying that I want 
to override langtools ...

>     mkdir toybuild
>     cd toybuild
> bash /w/jjg/work/tl/common/autoconf/configure --with-override-langtools=..


The script appears to succeed, saying

> A new configuration has been successfully created in
> /w/jjg/work/newbuild/8/langtools/toybuild
> using configure arguments '--with-override-langtools=..'.


But when I try and build the "langtools" target, I get ...

> $ make langtools
> Building OpenJDK for target 'langtools' in configuration 
> '/w/jjg/work/newbuild/8/langtools/toybuild'
>
>
> ########################################################################
> ########################################################################
> ##### Entering langtools for target(s) all                         #####
> ########################################################################
>
> Makefile:45: *** Build from top-level Makefile instead.  Stop.
> Cannot locate top-level Makefile. Is this repo not checked out as part 
> of a complete forest?
> make: *** [langtools-only] Error 2


Has configure not correctly recognized the root of my shared TL 
forest?   Is there an option I can use to specify where the full forest 
is?  I tried --srcdir, but the description is somewhat obscure and I 
wasn't sure if that was the one I should be using, but anyway, it didn't 
work (for me.)

Also, another comment on the --help output,   many options explicitly 
list that they take a value.  For example,
   --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]

But most of the other --with-* options do not, implying that they do not 
accept a value.  But something seems to work if you give them a value.  
It's not clear (to me) if they are ignoring the value, or whether the 
value is accepted, but something else is stopping my config from working.

-- Jon

On 11/06/2012 04:54 PM, Kelly O'Hair wrote:
> Just another reminder.
> For those of you that have tried the new builds, thank you.
>
> But we have gotten very few reports from anyone having problems with these new build-infra builds.
> That means things are working really well and we have done a fantastic job, or people are too busy to try it.
> At some point, we will have to assume that everything is working really well and get puffy chests. ;^)
>
> So if you have some time, please give it a try, and keep us honest.
>
> Please only reply to the build-infra-dev mailing list, or just me.
>
> -kto
>
>



From david.holmes at oracle.com  Thu Nov  8 17:04:15 2012
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Fri, 09 Nov 2012 01:04:15 +0000
Subject: hg: jdk8/profiles/jdk: 3 new changesets
Message-ID: <20121109010504.B37404786A@hg.openjdk.java.net>

Changeset: 6b7b5379dd08
Author:    dholmes
Date:      2012-11-08 19:42 -0500
URL:       http://hg.openjdk.java.net/jdk8/profiles/jdk/rev/6b7b5379dd08

Fix supportsVersion() for a full JRE (profile name is empty "")

! src/share/classes/sun/misc/Version.java.template

Changeset: 2a8eb6f4ec28
Author:    dholmes
Date:      2012-11-08 19:59 -0500
URL:       http://hg.openjdk.java.net/jdk8/profiles/jdk/rev/2a8eb6f4ec28

Enable old build to work with updated Version.java.template

! make/java/version/Makefile

Changeset: c9ca39ad52ee
Author:    dholmes
Date:      2012-11-08 20:00 -0500
URL:       http://hg.openjdk.java.net/jdk8/profiles/jdk/rev/c9ca39ad52ee

Merge




From fredrik.ohrstrom at oracle.com  Thu Nov  8 22:48:28 2012
From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com)
Date: Fri, 09 Nov 2012 06:48:28 +0000
Subject: hg: build-infra/jdk8/langtools: Real fix for problem with pubapis
	from other threads.
Message-ID: <20121109064835.D755447884@hg.openjdk.java.net>

Changeset: 77c1336361c2
Author:    ohrstrom
Date:      2012-11-09 07:48 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/langtools/rev/77c1336361c2

Real fix for problem with pubapis from other threads.

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/sjavac/server/JavacServer.java



From erik.joelsson at oracle.com  Fri Nov  9 00:52:21 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 09 Nov 2012 09:52:21 +0100
Subject: Fwd: New builds from the build-infra team
In-Reply-To: <509C1014.9020201@oracle.com>
References: <DCA50F95-9C8E-45BB-86BE-6BE322E1E916@oracle.com>	<AA30E7CB-8CF3-4254-8855-57F17D239B80@oracle.com>
	<509C1014.9020201@oracle.com>
Message-ID: <509CC445.3040200@oracle.com>



On 2012-11-08 21:03, Jonathan Gibbons wrote:
> I'm trying to use the new build system.
>
> I'm working in a langtools repo, and I have a full shared TL forest 
> elsewhere on my system.
>
> In my langtools repo, I've created a build directory and I've executed 
> the configure script from the shared TL forest, specifying that I want 
> to override langtools ...
>
>>     mkdir toybuild
>>     cd toybuild
>> bash /w/jjg/work/tl/common/autoconf/configure 
>> --with-override-langtools=..
>
>
> The script appears to succeed, saying
>
>> A new configuration has been successfully created in
>> /w/jjg/work/newbuild/8/langtools/toybuild
>> using configure arguments '--with-override-langtools=..'.
>
>
> But when I try and build the "langtools" target, I get ...
>
>> $ make langtools
>> Building OpenJDK for target 'langtools' in configuration 
>> '/w/jjg/work/newbuild/8/langtools/toybuild'
>>
>>
>> ########################################################################
>> ########################################################################
>> ##### Entering langtools for target(s) all                         #####
>> ########################################################################
>>
>> Makefile:45: *** Build from top-level Makefile instead.  Stop.
>> Cannot locate top-level Makefile. Is this repo not checked out as 
>> part of a complete forest?
>> make: *** [langtools-only] Error 2
>
I haven't been involved in or tried this feature yet, but that sounds 
like it should work so I will do some investigation.
>
> Has configure not correctly recognized the root of my shared TL 
> forest?   Is there an option I can use to specify where the full 
> forest is?  I tried --srcdir, but the description is somewhat obscure 
> and I wasn't sure if that was the one I should be using, but anyway, 
> it didn't work (for me.)
>
> Also, another comment on the --help output,   many options explicitly 
> list that they take a value.  For example,
>   --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]
>
> But most of the other --with-* options do not, implying that they do 
> not accept a value.  But something seems to work if you give them a 
> value.  It's not clear (to me) if they are ignoring the value, or 
> whether the value is accepted, but something else is stopping my 
> config from working.
>
I'm sure we have missed explicitly declaring if the parameters take 
values. In some cases it's implied but this might need to be looked over.

/Erik


From erik.joelsson at oracle.com  Fri Nov  9 01:12:11 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 09 Nov 2012 10:12:11 +0100
Subject: Fwd: New builds from the build-infra team
In-Reply-To: <509CC445.3040200@oracle.com>
References: <DCA50F95-9C8E-45BB-86BE-6BE322E1E916@oracle.com>	<AA30E7CB-8CF3-4254-8855-57F17D239B80@oracle.com>	<509C1014.9020201@oracle.com>
	<509CC445.3040200@oracle.com>
Message-ID: <509CC8EB.7060002@oracle.com>



On 2012-11-09 09:52, Erik Joelsson wrote:
>
>
> On 2012-11-08 21:03, Jonathan Gibbons wrote:
>> I'm trying to use the new build system.
>>
>> I'm working in a langtools repo, and I have a full shared TL forest 
>> elsewhere on my system.
>>
>> In my langtools repo, I've created a build directory and I've 
>> executed the configure script from the shared TL forest, specifying 
>> that I want to override langtools ...
>>
>>>     mkdir toybuild
>>>     cd toybuild
>>> bash /w/jjg/work/tl/common/autoconf/configure 
>>> --with-override-langtools=..
>>
>>
>> The script appears to succeed, saying
>>
>>> A new configuration has been successfully created in
>>> /w/jjg/work/newbuild/8/langtools/toybuild
>>> using configure arguments '--with-override-langtools=..'.
>>
>>
>> But when I try and build the "langtools" target, I get ...
>>
>>> $ make langtools
>>> Building OpenJDK for target 'langtools' in configuration 
>>> '/w/jjg/work/newbuild/8/langtools/toybuild'
>>>
>>>
>>> ######################################################################## 
>>>
>>> ######################################################################## 
>>>
>>> ##### Entering langtools for target(s) all                         
>>> #####
>>> ######################################################################## 
>>>
>>>
>>> Makefile:45: *** Build from top-level Makefile instead.  Stop.
>>> Cannot locate top-level Makefile. Is this repo not checked out as 
>>> part of a complete forest?
>>> make: *** [langtools-only] Error 2
>>
> I haven't been involved in or tried this feature yet, but that sounds 
> like it should work so I will do some investigation.
I have now tried this by cloning jdk8/jdk8/langtools to jdk8-langtools. 
Created jdk8-langtools/mybuild. From that directory I ran configure from 
first my build infra repo just like you described 
--with-override-langtools=.. Running make langtools worked as expected 
and built langtools. I repeated this with configure from my jdk8/tl repo 
and it worked just as well.

A difference I noted though, in my tries, the build is emitting the new 
less verbose "## Starting langtools" instead of the big headers you 
have. This indicates that the tl forest has been updated since you 
tried. Either this was broken in the old version, or there was enough of 
a version mismatch between your langtools repo and the forest you tried 
to use configure from so that they didn't work together.

My first guess would be the renaming of langtools/makefile/Makefile to 
langtools/makefile/BuildLangtools.gmk and the file 
langtools/makefile/Makefile now being a wrapper for the root repo makefile.

/Erik


From erik.joelsson at oracle.com  Fri Nov  9 06:29:53 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 09 Nov 2012 14:29:53 +0000
Subject: hg: build-infra/jdk8: Adjusted compare for deploy on mac.
Message-ID: <20121109142953.A3FE8478AA@hg.openjdk.java.net>

Changeset: 09b6fab27b1d
Author:    erikj
Date:      2012-11-09 06:29 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/09b6fab27b1d

Adjusted compare for deploy on mac.

! common/bin/compare.sh
! common/bin/compare_exceptions.sh.incl



From jonathan.gibbons at oracle.com  Fri Nov  9 07:04:51 2012
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 09 Nov 2012 07:04:51 -0800
Subject: Fwd: New builds from the build-infra team
In-Reply-To: <509CC8EB.7060002@oracle.com>
References: <DCA50F95-9C8E-45BB-86BE-6BE322E1E916@oracle.com>	<AA30E7CB-8CF3-4254-8855-57F17D239B80@oracle.com>	<509C1014.9020201@oracle.com>
	<509CC445.3040200@oracle.com> <509CC8EB.7060002@oracle.com>
Message-ID: <509D1B93.70002@oracle.com>

On 11/09/2012 01:12 AM, Erik Joelsson wrote:
>
>
> On 2012-11-09 09:52, Erik Joelsson wrote:
>>
>>
>> On 2012-11-08 21:03, Jonathan Gibbons wrote:
>>> I'm trying to use the new build system.
>>>
>>> I'm working in a langtools repo, and I have a full shared TL forest 
>>> elsewhere on my system.
>>>
>>> In my langtools repo, I've created a build directory and I've 
>>> executed the configure script from the shared TL forest, specifying 
>>> that I want to override langtools ...
>>>
>>>>     mkdir toybuild
>>>>     cd toybuild
>>>> bash /w/jjg/work/tl/common/autoconf/configure 
>>>> --with-override-langtools=..
>>>
>>>
>>> The script appears to succeed, saying
>>>
>>>> A new configuration has been successfully created in
>>>> /w/jjg/work/newbuild/8/langtools/toybuild
>>>> using configure arguments '--with-override-langtools=..'.
>>>
>>>
>>> But when I try and build the "langtools" target, I get ...
>>>
>>>> $ make langtools
>>>> Building OpenJDK for target 'langtools' in configuration 
>>>> '/w/jjg/work/newbuild/8/langtools/toybuild'
>>>>
>>>>
>>>> ######################################################################## 
>>>>
>>>> ######################################################################## 
>>>>
>>>> ##### Entering langtools for target(s) all                         
>>>> #####
>>>> ######################################################################## 
>>>>
>>>>
>>>> Makefile:45: *** Build from top-level Makefile instead. Stop.
>>>> Cannot locate top-level Makefile. Is this repo not checked out as 
>>>> part of a complete forest?
>>>> make: *** [langtools-only] Error 2
>>>
>> I haven't been involved in or tried this feature yet, but that sounds 
>> like it should work so I will do some investigation.
> I have now tried this by cloning jdk8/jdk8/langtools to 
> jdk8-langtools. Created jdk8-langtools/mybuild. From that directory I 
> ran configure from first my build infra repo just like you described 
> --with-override-langtools=.. Running make langtools worked as expected 
> and built langtools. I repeated this with configure from my jdk8/tl 
> repo and it worked just as well.
>
> A difference I noted though, in my tries, the build is emitting the 
> new less verbose "## Starting langtools" instead of the big headers 
> you have. This indicates that the tl forest has been updated since you 
> tried. Either this was broken in the old version, or there was enough 
> of a version mismatch between your langtools repo and the forest you 
> tried to use configure from so that they didn't work together.
>
> My first guess would be the renaming of langtools/makefile/Makefile to 
> langtools/makefile/BuildLangtools.gmk and the file 
> langtools/makefile/Makefile now being a wrapper for the root repo 
> makefile.
>
> /Erik


Erik,

Thanks for following up on this.  I'll update my repos, try again, and 
report back.

-- Jon


From kelly.ohair at oracle.com  Fri Nov  9 13:05:46 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Fri, 9 Nov 2012 13:05:46 -0800
Subject: New builds from the build-infra team
In-Reply-To: <509D0D9F.9090207@oracle.com>
References: <DCA50F95-9C8E-45BB-86BE-6BE322E1E916@oracle.com>
	<509A6D34.8090507@oracle.com>
	<DEF58201-75C0-4D4B-A063-7C8622C4F9D5@oracle.com>
	<509D0D9F.9090207@oracle.com>
Message-ID: <A59F3F35-8DDF-407A-8449-5EEF4759F493@oracle.com>


On Nov 9, 2012, at 6:05 AM, Anthony Petrov wrote:

> On 11/8/2012 12:22 AM, Kelly O'Hair wrote:
>> On Nov 7, 2012, at 6:16 AM, Anthony Petrov wrote:
>>> (please keep me in CC since I'm not subscribed to this list)
>>> 
>>> (I'm building on Linux i586)
>> Fedora 9 x86 or something else?  The specific Linux distro and release number is always a big help.
> 
> I run Mandriva 2010.2 i586.

Interesting, never tried it before.  So I'm impressed it's working well. ;^)
We'll put Anthony Petrov down as the Mandriva expert. ;^)


> 
> 
>>> 1. Could we add the /java/re/jdk/<version>/promoted/latest/binaries/<platform>/ directories to check for a Boot JDK to ./configure? E.g. /java/re/jdk/7u10/promoted/latest/binaries/linux-i586. I realize that this is almost useless outside of Oracle, but it would be really helpful for internal builds when one has already set up the /java directory structure properly.
>> I'm not sure that "... set up the /java directory structure properly." is a very well-defined thing. That's been part of the issue
>> with the /java/ layout, many people think they know what the layout is, but nobody has the same layout. :^(
>> I generally put the boot jdk java in the PATH, and that seems to work fine.
>> With the /java/re path being an automount NFS path, I have a very hard time making that something we will find by default.
>> But Magnus added a --with-java-path option that will use the /java paths, just have not used it.
>> We have tried hard to make the builds as fast as possible and reliable, and local installs of the tools is what
>> should be preferred.
> 
> I realize that I could put it on path, or specify --with-java-path, or --with-boot-jdk. But I want to do neither of these. The old builds could always automatically find the correct boot jdk from the default location, which is:
> 
> /java/re/jdk/1.7.0/archive/fcs/binaries/linux-i586
> 
> (for JDK 8 builds on Linux i586).
> 
> When building JDK 7, for instance, it would be:
> 
> /java/re/jdk/1.6.0/archive/fcs/binaries/linux-i586

Technically, those are the wrong boot jdks in both cases. It's jdk7u7 for jdk8 now, and jdk6u18 for jdk7 update builds.
The jdk Makefiles are actually going after the wrong ones. :^( Nobody has ever keep these paths in the Makefiles up-to-date. :^(
The RE and JPRT builds explicitly set the boot jdk to local disk copies.

But the big issue is that maybe /java works for you, but not for many others, and even if we found this /java jdk,
if the NFS location is really slow (often hard to tell initially), do we automatically pick a boot jdk that could
cause the builds to be like 15X slower due to the NFS network being slow?
I have occasionally managed to get my /java automounts to go after the US East coast mirror instead of the
closer West coast /java area and everything gets so slow that it's impossible to get any work done until you
realize that your automounts are messed up due to some temporary system outage and a backup mount point.
So you in general cannot trust that /java will be there or be fast access.

So many people report to me that their builds are slow or unreliable, and I find out they are using NFS paths all over  the place.

I'm just not sure that looking for /java by default is a good idea when we cannot trust it.

I would rather explore a solution where we check the local disk areas for an appropriate java, and if none
is found, copy one over from the /java area. Or rsync the image in.
Are you in  a situation where the system being used is low on local disk space?

> 
> I see that ./configure already checks several paths under /usr/java/ and  /usr/lib/jvm/. I would like it to know about the standard /java/ paths as well, and wouldn't require any command-line options if I have a correct boot JDK there.
> 
> Could we do that?

Not sure I want to, but let me talk to the rest of the team about this.

> 
> 
>>> 2. What is the ./build/linux-x86-normal-server-release directory, and why is it not ./build/linux-i586 ? What does 'normal' stand for? The same question about the 'server' part.
>>> 
>> The configure allows for many variations on builds, and the basic variation is put into the directory name.
>> I have been tempted to soft link linux-i586 to linux-x86-normal-server-release or whatever linux-x86-*name is generated
>> (assuming only one exists), but it gets a little complicated.
> 
> Well, I'm fine with any directory name. I just want to understand the reason why we have to change it to something other than simple "linux-i586" (at least for default builds).
> 

Ah, one person's default is another person's custom one, it is hard to point at one configuration and say that's the default
for everybody, but let me talk to the others on this and see what they think.

-kto

> --
> best regards,
> Anthony
> 
> 
> 
>>> 3. I get the following error and the build stops:
>>> 
>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `UnrollHalfToFloat':
>>>> cmspack.c:(.text+0x1f25): undefined reference to `_cmsHalf2Float'
>>>> cmspack.c:(.text+0x1f73): undefined reference to `_cmsHalf2Float'
>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `UnrollHalfTo16':
>>>> cmspack.c:(.text+0x261d): undefined reference to `_cmsHalf2Float'
>>>> cmspack.c:(.text+0x26bd): undefined reference to `_cmsHalf2Float'
>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `PackHalfFromFloat':
>>>> cmspack.c:(.text+0x36bb): undefined reference to `_cmsFloat2Half'
>>>> cmspack.c:(.text+0x3710): undefined reference to `_cmsFloat2Half'
>>>> cmspack.c:(.text+0x37af): undefined reference to `_cmsFloat2Half'
>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `PackHalfFrom16':
>>>> cmspack.c:(.text+0x38a8): undefined reference to `_cmsFloat2Half'
>>>> cmspack.c:(.text+0x3906): undefined reference to `_cmsFloat2Half'
>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o:cmspack.c:(.text+0x39a7): more undefined references to `_cmsFloat2Half' follow
>>>> collect2: ld returned 1 exit status
>>>> gmake[3]: *** [/export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/lib/i386/liblcms.so] Error 1
>>>> gmake[3]: *** Waiting for unfinished jobs....
>>>> gmake[3]: Leaving directory `/export/anthony/8-50-full-new-build/jdk/makefiles'
>>>> gmake[2]: *** [libs-only] Error 2
>>>> gmake[2]: Leaving directory `/export/anthony/8-50-full-new-build/jdk/makefiles'
>>>> make[1]: *** [jdk-only] Error 2
>>>> make[1]: Leaving directory `/export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release'
>>>> make: *** [all] Error 2
>>> 
>>> Is this a known issue with lcms? Note that I've almost exclusively always built JDK w/ closed repos, and this time I'm building OpenJDK repos only. I'll try to clone the closed parts and see if this eliminates the issue #3.
>> Never seen this problem before.
>> -kto
>>> 
>>> --
>>> best regards,
>>> Anthony
>>> 
>>> On 11/1/2012 10:38 PM, Kelly O'Hair wrote:
>>>> Pardon the wide email, but this impacts everyone building the OpenJDK jdk8/jdk8 derived forests.
>>>> Please only reply to the build-infra-dev mailing list, or just me.
>>>> With some recent integrations from the build-infra project into jdk8/jdk8 repositories, the build-infra team
>>>> would like to get more exposure of the new builds. These jdk8/jdk8 changes will start showing up in various
>>>> jdk8 and team forests over the next few weeks. The default is still the old builds, but both builds work in most
>>>> cases for OpenJDK as far as we know.
>>>> At a very high level, the intent is that once you get a forest:
>>>> hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>>>> cd j8
>>>> sh ./get_source.sh
>>>> You should be able to simply configure&&make (the ultimate goal is this simple anyway), e.g.
>>>>  sh ./configure
>>>>  make NEWBUILD=true     # The NEWBUILD=true will become the default when we formally switch.
>>>> Where "make" is GNU make 3.81, and your system has all the requires packages and PATH contains the
>>>> needed tools. Note that on Windows, MKS unix utilities cannot be used with the new builds, just CYGWIN
>>>> is recommended at this time.
>>>> Of course, we know, it's never as easy as a simple configure&&make, and often you will need to pass in
>>>> configure options.
>>>> What we would like to know is where a simple configure&&make does not work, and anything people had
>>>> to do to make it work.
>>>> I know many of you are quite used to the old builds, so I have a temporary  "bridgeBuild" target
>>>> people can try that will attempt to map the ALT_* environment variables to an appropriate configure command
>>>> and then run that configure command and do the build, e.g.
>>>> make NEWBUILD=true bridgeBuild
>>>> People willing to do comparisons between the old and new builds could:
>>>> rm -f -r build
>>>> time make NEWBUILD=true bridgeBuild
>>>> rm -f -r build
>>>> time make NO_DOCS=true     # Old builds do not generate javadocs by default
>>>> Any observations about speed of the builds would be appreciated, as will any impressions on what you see.
>>>> At this time, we think this is working pretty well with a few caveats:
>>>> * GNU make with the new builds is doing much more parallel processing and this can stress out a system
>>>>   - Use "make JOBS=1" if you suspect a problem, then try adjusting it up slowly.
>>>> * Partial builds are limited, right now full builds of the entire OpenJDK is the target
>>>>   - Hotspot can still be built on it's own, but everyone else needs to build hotspot at least once
>>>> * Paths with multiple names can cause problems, e.g. being on system svc6, and access an exported share
>>>>   area as /net/svc6/export/foobar  instead of /export/foobar  will cause problems. Use local paths.
>>>> We know there are still issues and we will be focusing heavily on the critical ones in the next few weeks, but
>>>> we do need the community to tell us what the critical issues really are.
>>>> Our number one priority at this time is that everyone that was able to build the old way, should be able to build
>>>> with the new build-infra makefiles. Please help us verify that.
>>>> -kto



From kelly.ohair at oracle.com  Fri Nov  9 13:14:11 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Fri, 9 Nov 2012 13:14:11 -0800
Subject: New builds from the build-infra team
In-Reply-To: <509D1023.7070003@oracle.com>
References: <DCA50F95-9C8E-45BB-86BE-6BE322E1E916@oracle.com>
	<509A6D34.8090507@oracle.com> <509A7AE4.1060805@oracle.com>
	<509A7D7F.60608@oracle.com>
	<D06266B6-A104-4FF1-9262-62477B7FC259@oracle.com>
	<509D1023.7070003@oracle.com>
Message-ID: <A6ABECEE-5F9D-4620-AF5F-74686A8549CA@oracle.com>


On Nov 9, 2012, at 6:16 AM, Anthony Petrov wrote:

> On 11/8/2012 12:30 AM, Kelly O'Hair wrote:
>> On Nov 7, 2012, at 7:25 AM, Anthony Petrov wrote:
>>> A follow up message. Generally, the new builds work fine. A couple suggestions:
>>> 
>>> 1. Can we make hotspot builds less noisy? Unless there are warnings or errors, there's no need to print out the name of each file being compiled.
>> It's hard to know before hand if a file has errors or warnings but the hotspot makefiles are actually
>> unchanged for the most part, so you are seeing the old and traditional hotspot build output.
>> There is a great deal of debate on this noisy vs. quiet logging issue, and Magnus at least tried to deal with
>> it by adding a LOG option, so you can try:
>>   make LOG=warn
>> if I remember right. But it may be a while before we can get the hotspot makefiles to obey this setting.
> 
> I see. I just seen how much less noise the JDK build produces now (and this is cool, IMO), and been under impression that HotSpot makefiles differ a little in this respect. It appears they differ a lot... yet. All right, will wait then till HotSpot folks fix them.

I think the idea was to get the developer builds as noiseless as possible, and that would make any warning
errors stand out, which would trigger people to fix them. So with hotspot, this may take some time.

> 
> 
>>> 2. There's a lot of warnings generated when compiling JDK native code. I think some of them can be related to the new build. After they are analyzed, can somebody from build-infra file bugs against appropriate teams to fix them up?
>> I don't think the new build is adding warnings, but I can't be sure. These should be the same warnings as the old
>> build, but may be more visible when the compile lines are not echo'd.
> 
> Exactly!

Yup, assuming that we eventually get rid of all the warnings, someday anyway.

> 
>> The last time I filed a whole bunch of bugs against warnings in the build, it was a royal pain, like herding cats
>> to get all the various teams to do anything about it. But at some point we will do another warning hunt fix,
>> just not sure the build team will be driving it or not.
> 
> Well, I don't think we should actively drive this effort. But at least just filing the bugs would be a very good thing to do. As we slowly switching to the new build, I think we should just tell people to file bugs against warnings whenever they see them. I guess that after closing dozens of duplicates, the responsible teams will finally fix them.
> 

Interesting, have everyone file bugs and annoy the teams to fix them.   Not sure I want to advocate that,
some of these guys might be armed with sharp pens and pencils, I don't want to be attacked. ;^)

> And, btw, -Werror would make the issues P1. Just saying. :))

The goal with javac compilations is to get to -Werror, but with the native C/C++ compilers it is a bit trickier.
Sometimes fixing C/C++ warnings for gcc will trigger different warning errors from the Windows Visual Studio
compiler, or the Solaris Studio compilers. Not saying any of them are wrong, they are all different.
Since the gcc used on each Linux system can be different versions, adding -Werror has been problematic and
in many cases they had to turn it off to get the build to work.

I don't have a better idea on using -Werror with C/C++ compilers when we use so many different ones.

We do control javac compilations and the version used, and it's the same on all systems, so that one we
can strive to get -Werror on all javac compile lines.

-kto

> 
> --
> best regards,
> Anthony
> 
>> -kto
>>> --
>>> best regards,
>>> Anthony
>>> 
>>> On 11/7/2012 7:14 PM, Anthony Petrov wrote:
>>>> Update on issue #3: after cloning the closed repos my build succeeded. Must be an issue related to OPENJDK=true builds only. Still, I'd like to get some comments regarding #1 and #2 below. Thanks in advance.
>>>> -- 
>>>> best regards,
>>>> Anthony
>>>> On 11/7/2012 6:16 PM, Anthony Petrov wrote:
>>>>> Hi All,
>>>>> 
>>>>> (please keep me in CC since I'm not subscribed to this list)
>>>>> 
>>>>> (I'm building on Linux i586)
>>>>> 
>>>>> 1. Could we add the /java/re/jdk/<version>/promoted/latest/binaries/<platform>/ directories to check for a Boot JDK to ./configure? E.g. /java/re/jdk/7u10/promoted/latest/binaries/linux-i586. I realize that this is almost useless outside of Oracle, but it would be really helpful for internal builds when one has already set up the /java directory structure properly.
>>>>> 
>>>>> 2. What is the ./build/linux-x86-normal-server-release directory, and why is it not ./build/linux-i586 ? What does 'normal' stand for? The same question about the 'server' part.
>>>>> 
>>>>> 3. I get the following error and the build stops:
>>>>> 
>>>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `UnrollHalfToFloat':
>>>>>> cmspack.c:(.text+0x1f25): undefined reference to `_cmsHalf2Float'
>>>>>> cmspack.c:(.text+0x1f73): undefined reference to `_cmsHalf2Float'
>>>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `UnrollHalfTo16':
>>>>>> cmspack.c:(.text+0x261d): undefined reference to `_cmsHalf2Float'
>>>>>> cmspack.c:(.text+0x26bd): undefined reference to `_cmsHalf2Float'
>>>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `PackHalfFromFloat':
>>>>>> cmspack.c:(.text+0x36bb): undefined reference to `_cmsFloat2Half'
>>>>>> cmspack.c:(.text+0x3710): undefined reference to `_cmsFloat2Half'
>>>>>> cmspack.c:(.text+0x37af): undefined reference to `_cmsFloat2Half'
>>>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `PackHalfFrom16':
>>>>>> cmspack.c:(.text+0x38a8): undefined reference to `_cmsFloat2Half'
>>>>>> cmspack.c:(.text+0x3906): undefined reference to `_cmsFloat2Half'
>>>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o:cmspack.c:(.text+0x39a7): more undefined references to `_cmsFloat2Half' follow
>>>>>> collect2: ld returned 1 exit status
>>>>>> gmake[3]: *** [/export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/lib/i386/liblcms.so] Error 1
>>>>>> gmake[3]: *** Waiting for unfinished jobs....
>>>>>> gmake[3]: Leaving directory `/export/anthony/8-50-full-new-build/jdk/makefiles'
>>>>>> gmake[2]: *** [libs-only] Error 2
>>>>>> gmake[2]: Leaving directory `/export/anthony/8-50-full-new-build/jdk/makefiles'
>>>>>> make[1]: *** [jdk-only] Error 2
>>>>>> make[1]: Leaving directory `/export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release' make: *** [all] Error 2
>>>>> Is this a known issue with lcms? Note that I've almost exclusively always built JDK w/ closed repos, and this time I'm building OpenJDK repos only. I'll try to clone the closed parts and see if this eliminates the issue #3.
>>>>> 
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>> 
>>>>> On 11/1/2012 10:38 PM, Kelly O'Hair wrote:
>>>>>> Pardon the wide email, but this impacts everyone building the OpenJDK jdk8/jdk8 derived forests.
>>>>>> 
>>>>>> Please only reply to the build-infra-dev mailing list, or just me.
>>>>>> 
>>>>>> With some recent integrations from the build-infra project into jdk8/jdk8 repositories, the build-infra team
>>>>>> would like to get more exposure of the new builds. These jdk8/jdk8 changes will start showing up in various
>>>>>> jdk8 and team forests over the next few weeks. The default is still the old builds, but both builds work in most
>>>>>> cases for OpenJDK as far as we know.
>>>>>> 
>>>>>> At a very high level, the intent is that once you get a forest:
>>>>>> hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>>>>>> cd j8
>>>>>> sh ./get_source.sh
>>>>>> 
>>>>>> You should be able to simply configure&&make (the ultimate goal is this simple anyway), e.g.
>>>>>>  sh ./configure
>>>>>>  make NEWBUILD=true     # The NEWBUILD=true will become the default when we formally switch.
>>>>>> 
>>>>>> Where "make" is GNU make 3.81, and your system has all the requires packages and PATH contains the
>>>>>> needed tools. Note that on Windows, MKS unix utilities cannot be used with the new builds, just CYGWIN
>>>>>> is recommended at this time.
>>>>>> 
>>>>>> Of course, we know, it's never as easy as a simple configure&&make, and often you will need to pass in
>>>>>> configure options.
>>>>>> 
>>>>>> What we would like to know is where a simple configure&&make does not work, and anything people had
>>>>>> to do to make it work.
>>>>>> 
>>>>>> I know many of you are quite used to the old builds, so I have a temporary  "bridgeBuild" target
>>>>>> people can try that will attempt to map the ALT_* environment variables to an appropriate configure command
>>>>>> and then run that configure command and do the build, e.g.
>>>>>> 
>>>>>> make NEWBUILD=true bridgeBuild
>>>>>> 
>>>>>> People willing to do comparisons between the old and new builds could:
>>>>>> rm -f -r build
>>>>>> time make NEWBUILD=true bridgeBuild
>>>>>> rm -f -r build
>>>>>> time make NO_DOCS=true     # Old builds do not generate javadocs by default
>>>>>> 
>>>>>> Any observations about speed of the builds would be appreciated, as will any impressions on what you see.
>>>>>> 
>>>>>> At this time, we think this is working pretty well with a few caveats:
>>>>>> * GNU make with the new builds is doing much more parallel processing and this can stress out a system
>>>>>>   - Use "make JOBS=1" if you suspect a problem, then try adjusting it up slowly.
>>>>>> * Partial builds are limited, right now full builds of the entire OpenJDK is the target
>>>>>>   - Hotspot can still be built on it's own, but everyone else needs to build hotspot at least once
>>>>>> * Paths with multiple names can cause problems, e.g. being on system svc6, and access an exported share
>>>>>>   area as /net/svc6/export/foobar  instead of /export/foobar  will cause problems. Use local paths.
>>>>>> 
>>>>>> We know there are still issues and we will be focusing heavily on the critical ones in the next few weeks, but
>>>>>> we do need the community to tell us what the critical issues really are.
>>>>>> 
>>>>>> Our number one priority at this time is that everyone that was able to build the old way, should be able to build
>>>>>> with the new build-infra makefiles. Please help us verify that.
>>>>>> 
>>>>>> -kto
>>>>>> 



From mike.duigou at oracle.com  Fri Nov  9 17:11:14 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 9 Nov 2012 17:11:14 -0800
Subject: Problems building JDK8 on x64 Linux with new build
In-Reply-To: <2DC6706F-FA00-47B4-8C87-B1E91494C7A3@oracle.com>
References: <2DC6706F-FA00-47B4-8C87-B1E91494C7A3@oracle.com>
Message-ID: <B795AE4B-7994-4BF3-B59E-A8E268D009E8@oracle.com>

Backing out cc998992dc32 currently isn't sufficient to produce a working x64 Linux image with new build. There appears to also be a problem with CreateJars.gmk running the `images` target:

make[2]: Entering directory `/home/mike/code/jdk/jdk8/jdk/makefiles'
/bin/sh: 1: cannot create /home/mike/code/jdk/jdk8/build/linux-x86_64-normal-server-fastdebug/images/lib/ext//_the.localedata.jar_include: Directory nonexistent
/bin/grep: /home/mike/code/jdk/jdk8/build/linux-x86_64-normal-server-fastdebug/images/lib/ext//_the.localedata.jar_include: No such file or directory
make[3]: Entering directory `/home/mike/code/jdk/jdk8/jdk/makefiles'
CreateJars.gmk:905: *** missing `endif'.  Stop.
make[3]: Leaving directory `/home/mike/code/jdk/jdk8/jdk/makefiles'

I spent some time trying to find the missing endif but it was elusive. (wouldn't it be useful if make told you the start line of the unclosed if!)

The preceding failed output lines are also suspicious to me. 

This kind of problem shouldn't be getting in to the master jdk8 repo.

Mike


On Nov 7 2012, at 08:35 , Mike Duigou wrote:

> Building jdk8 currently fails :
> 
> /home/mike/code/jdk8/jdk/build/linux-x86_64-normal-server-fastdebug/jdk/objs/liblcms/cmspack.o: In function `UnrollHalfToFloat':
> cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
> cmspack.c:(.text+0x27c6): undefined reference to `_cmsHalf2Float'
> 
> presumably caused by:
> 
> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/cc998992dc32
> 
> 



From david.holmes at oracle.com  Fri Nov  9 18:11:40 2012
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 10 Nov 2012 12:11:40 +1000
Subject: Problems building JDK8 on x64 Linux with new build
In-Reply-To: <B795AE4B-7994-4BF3-B59E-A8E268D009E8@oracle.com>
References: <2DC6706F-FA00-47B4-8C87-B1E91494C7A3@oracle.com>
	<B795AE4B-7994-4BF3-B59E-A8E268D009E8@oracle.com>
Message-ID: <509DB7DC.40701@oracle.com>

Mike,

Which forest did you clone?

David

On 10/11/2012 11:11 AM, Mike Duigou wrote:
> Backing out cc998992dc32 currently isn't sufficient to produce a working x64 Linux image with new build. There appears to also be a problem with CreateJars.gmk running the `images` target:
>
> make[2]: Entering directory `/home/mike/code/jdk/jdk8/jdk/makefiles'
> /bin/sh: 1: cannot create /home/mike/code/jdk/jdk8/build/linux-x86_64-normal-server-fastdebug/images/lib/ext//_the.localedata.jar_include: Directory nonexistent
> /bin/grep: /home/mike/code/jdk/jdk8/build/linux-x86_64-normal-server-fastdebug/images/lib/ext//_the.localedata.jar_include: No such file or directory
> make[3]: Entering directory `/home/mike/code/jdk/jdk8/jdk/makefiles'
> CreateJars.gmk:905: *** missing `endif'.  Stop.
> make[3]: Leaving directory `/home/mike/code/jdk/jdk8/jdk/makefiles'
>
> I spent some time trying to find the missing endif but it was elusive. (wouldn't it be useful if make told you the start line of the unclosed if!)
>
> The preceding failed output lines are also suspicious to me.
>
> This kind of problem shouldn't be getting in to the master jdk8 repo.
>
> Mike
>
>
> On Nov 7 2012, at 08:35 , Mike Duigou wrote:
>
>> Building jdk8 currently fails :
>>
>> /home/mike/code/jdk8/jdk/build/linux-x86_64-normal-server-fastdebug/jdk/objs/liblcms/cmspack.o: In function `UnrollHalfToFloat':
>> cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
>> cmspack.c:(.text+0x27c6): undefined reference to `_cmsHalf2Float'
>>
>> presumably caused by:
>>
>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/cc998992dc32
>>
>>
>


From kelly.ohair at oracle.com  Fri Nov  9 18:12:42 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Fri, 9 Nov 2012 18:12:42 -0800
Subject: Problems building JDK8 on x64 Linux with new build
In-Reply-To: <B795AE4B-7994-4BF3-B59E-A8E268D009E8@oracle.com>
References: <2DC6706F-FA00-47B4-8C87-B1E91494C7A3@oracle.com>
	<B795AE4B-7994-4BF3-B59E-A8E268D009E8@oracle.com>
Message-ID: <9C717C4C-8B54-4062-A4CB-D7591C8E68D2@oracle.com>

Fredrik fixed one endif related bug:

http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/1e79fec4a01f

-kto

On Nov 9, 2012, at 5:11 PM, Mike Duigou wrote:

> Backing out cc998992dc32 currently isn't sufficient to produce a working x64 Linux image with new build. There appears to also be a problem with CreateJars.gmk running the `images` target:
> 
> make[2]: Entering directory `/home/mike/code/jdk/jdk8/jdk/makefiles'
> /bin/sh: 1: cannot create /home/mike/code/jdk/jdk8/build/linux-x86_64-normal-server-fastdebug/images/lib/ext//_the.localedata.jar_include: Directory nonexistent
> /bin/grep: /home/mike/code/jdk/jdk8/build/linux-x86_64-normal-server-fastdebug/images/lib/ext//_the.localedata.jar_include: No such file or directory
> make[3]: Entering directory `/home/mike/code/jdk/jdk8/jdk/makefiles'
> CreateJars.gmk:905: *** missing `endif'.  Stop.
> make[3]: Leaving directory `/home/mike/code/jdk/jdk8/jdk/makefiles'
> 
> I spent some time trying to find the missing endif but it was elusive. (wouldn't it be useful if make told you the start line of the unclosed if!)
> 
> The preceding failed output lines are also suspicious to me. 
> 
> This kind of problem shouldn't be getting in to the master jdk8 repo.
> 
> Mike
> 
> 
> On Nov 7 2012, at 08:35 , Mike Duigou wrote:
> 
>> Building jdk8 currently fails :
>> 
>> /home/mike/code/jdk8/jdk/build/linux-x86_64-normal-server-fastdebug/jdk/objs/liblcms/cmspack.o: In function `UnrollHalfToFloat':
>> cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
>> cmspack.c:(.text+0x27c6): undefined reference to `_cmsHalf2Float'
>> 
>> presumably caused by:
>> 
>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/cc998992dc32
>> 
>> 
> 



From david.holmes at oracle.com  Fri Nov  9 18:36:45 2012
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 10 Nov 2012 12:36:45 +1000
Subject: Auxiliary class warnings?
Message-ID: <509DBDBD.8040808@oracle.com>

I now see a lot of warnings in the build like so:

/java/embedded/users/dh198349/build-infra/jdk/make/tools/src/build/tools/generatenimbus/SynthModel.java:207: 
Note: auxiliary class Rectangle in 
/java/embedded/users/dh198349/build-infra/jdk/make/tools/src/build/tools/generatenimbus/Shape.java 
should not be accessed from outside its own source file
         @XmlElement(name = "rectangle", type = Rectangle.class)
                                                ^
This seems to be due to Fredrik's javac enhancement for 
-Xlint:auxiliaryclass

Is there some reason this is turned on by default?

Aside: the Note is completely inappropriate as there are no Java 
language violations of any kind occurring. It should say "is being 
accessed" not "should not be accessed".

David



From mike.duigou at oracle.com  Fri Nov  9 18:42:20 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 9 Nov 2012 18:42:20 -0800
Subject: Problems building JDK8 on x64 Linux with new build
In-Reply-To: <509DB7DC.40701@oracle.com>
References: <2DC6706F-FA00-47B4-8C87-B1E91494C7A3@oracle.com>
	<B795AE4B-7994-4BF3-B59E-A8E268D009E8@oracle.com>
	<509DB7DC.40701@oracle.com>
Message-ID: <1A13BA4F-4A58-4B9C-A7CD-27EA6BB846AB@oracle.com>

Both of these problems are reproducible with builds of http://hg.openjdk.java.net/jdk8/jdk8/

I just checked the patch kelly mentioned and it resolved both issues. It would be nice to get it into jdk8/jdk8 and team workspaces asap.

Mike

On Nov 9 2012, at 18:11 , David Holmes wrote:

> Mike,
> 
> Which forest did you clone?
> 
> David
> 
> On 10/11/2012 11:11 AM, Mike Duigou wrote:
>> Backing out cc998992dc32 currently isn't sufficient to produce a working x64 Linux image with new build. There appears to also be a problem with CreateJars.gmk running the `images` target:
>> 
>> make[2]: Entering directory `/home/mike/code/jdk/jdk8/jdk/makefiles'
>> /bin/sh: 1: cannot create /home/mike/code/jdk/jdk8/build/linux-x86_64-normal-server-fastdebug/images/lib/ext//_the.localedata.jar_include: Directory nonexistent
>> /bin/grep: /home/mike/code/jdk/jdk8/build/linux-x86_64-normal-server-fastdebug/images/lib/ext//_the.localedata.jar_include: No such file or directory
>> make[3]: Entering directory `/home/mike/code/jdk/jdk8/jdk/makefiles'
>> CreateJars.gmk:905: *** missing `endif'.  Stop.
>> make[3]: Leaving directory `/home/mike/code/jdk/jdk8/jdk/makefiles'
>> 
>> I spent some time trying to find the missing endif but it was elusive. (wouldn't it be useful if make told you the start line of the unclosed if!)
>> 
>> The preceding failed output lines are also suspicious to me.
>> 
>> This kind of problem shouldn't be getting in to the master jdk8 repo.
>> 
>> Mike
>> 
>> 
>> On Nov 7 2012, at 08:35 , Mike Duigou wrote:
>>> Building jdk8 currently fails :
>>> 
>>> /home/mike/code/jdk8/jdk/build/linux-x86_64-normal-server-fastdebug/jdk/objs/liblcms/cmspack.o: In function `UnrollHalfToFloat':
>>> cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
>>> cmspack.c:(.text+0x27c6): undefined reference to `_cmsHalf2Float'
>>> 
>>> presumably caused by:
>>> 
>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/cc998992dc32
>>> 
>>> 
>> 



From alan.bateman at oracle.com  Sat Nov 10 12:06:37 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sat, 10 Nov 2012 20:06:37 +0000
Subject: hg: jdk8/profiles/jdk: Throw UnsupportedProfileException rather than
	Error when JAR file specify a profile that is not supported
Message-ID: <20121110200719.0A0DD478CF@hg.openjdk.java.net>

Changeset: 70944a34ee0a
Author:    alanb
Date:      2012-11-10 20:04 +0000
URL:       http://hg.openjdk.java.net/jdk8/profiles/jdk/rev/70944a34ee0a

Throw UnsupportedProfileException rather than Error when JAR file specify a profile that is not supported

! src/share/classes/java/net/URLClassLoader.java
! src/share/classes/java/util/jar/Attributes.java
+ src/share/classes/java/util/jar/UnsupportedProfileException.java
! src/share/classes/sun/misc/URLClassPath.java
+ test/java/net/URLClassLoader/profiles/Basic.java
+ test/java/net/URLClassLoader/profiles/Lib.java
+ test/java/net/URLClassLoader/profiles/Lib.mf
+ test/java/net/URLClassLoader/profiles/basic.sh



From sadhak001 at gmail.com  Sun Nov 11 14:27:47 2012
From: sadhak001 at gmail.com (Mani Sarkar)
Date: Sun, 11 Nov 2012 22:27:47 +0000
Subject: Error when running make clean (hotspot) under Ubuntu 12.10
Message-ID: <CAGHtMW=OQKqUV8sW+QadXrkU8DkvCcpQy_b2uzjtcDYGekWmtQ@mail.gmail.com>

Hi all,

Can you please help us out with this issue when building the openJDK using
infra-build under Ubuntu 12.10. I have attached a snippet of the error
message Log files are also available if you need them (> 1.05mb).

Compiling
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/blockOffsetTable.cpp
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
In instantiation of ?void AscendTreeCensusClosure<Chunk_t,
FreeList_t>::do_tree(TreeList<Chunk_t, FreeList_t>*) [with Chunk_t =
FreeChunk; FreeList_t = AdaptiveFreeList]?:
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1295:21:
  required from here
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:943:7:
error: ?do_list? was not declared in this scope, and no declarations were
found by argument-dependent lookup at the point of instantiation
[-fpermissive]
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:943:7:
note: declarations in dependent base ?TreeCensusClosure<FreeChunk,
AdaptiveFreeList>? are not found by unqualified lookup
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:943:7:
note: use ?this->do_list? instead
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
In instantiation of ?TreeList<Chunk_t, FreeList_t>* TreeList<Chunk_t,
FreeList_t>::remove_chunk_replace_if_needed(TreeChunk<Chunk_t,
FreeList_t>*) [with Chunk_t = Metablock; FreeList_t = FreeList]?:
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1407:16:
  required from here
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:242:7:
error: ?link_tail? was not declared in this scope, and no declarations were
found by argument-dependent lookup at the point of instantiation
[-fpermissive]
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:242:7:
note: declarations in dependent base ?FreeList<Metablock>? are not found by
unqualified lookup
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:242:7:
note: use ?this->link_tail? instead
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
In instantiation of ?void TreeList<Chunk_t,
FreeList_t>::return_chunk_at_head(TreeChunk<Chunk_t, FreeList_t>*) [with
Chunk_t = Metablock; FreeList_t = FreeList]?:
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1407:16:
  required from here
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:326:5:
error: ?link_tail? was not declared in this scope, and no declarations were
found by argument-dependent lookup at the point of instantiation
[-fpermissive]
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:326:5:
note: declarations in dependent base ?FreeList<Metablock>? are not found by
unqualified lookup
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:326:5:
note: use ?this->link_tail? instead
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
In instantiation of ?void TreeList<Chunk_t,
FreeList_t>::return_chunk_at_tail(TreeChunk<Chunk_t, FreeList_t>*) [with
Chunk_t = Metablock; FreeList_t = FreeList]?:
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1407:16:
  required from here
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:299:3:
error: ?link_tail? was not declared in this scope, and no declarations were
found by argument-dependent lookup at the point of instantiation
[-fpermissive]
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:299:3:
note: declarations in dependent base ?FreeList<Metablock>? are not found by
unqualified lookup
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:299:3:
note: use ?this->link_tail? instead
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
In instantiation of ?TreeList<Chunk_t, FreeList_t>* TreeList<Chunk_t,
FreeList_t>::remove_chunk_replace_if_needed(TreeChunk<Chunk_t,
FreeList_t>*) [with Chunk_t = Metachunk; FreeList_t = FreeList]?:
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1411:16:
  required from here
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:242:7:
error: ?link_tail? was not declared in this scope, and no declarations were
found by argument-dependent lookup at the point of instantiation
[-fpermissive]
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:242:7:
note: declarations in dependent base ?FreeList<Metachunk>? are not found by
unqualified lookup
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:242:7:
note: use ?this->link_tail? instead
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
In instantiation of ?void TreeList<Chunk_t,
FreeList_t>::return_chunk_at_head(TreeChunk<Chunk_t, FreeList_t>*) [with
Chunk_t = Metachunk; FreeList_t = FreeList]?:
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1411:16:
  required from here
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:326:5:
error: ?link_tail? was not declared in this scope, and no declarations were
found by argument-dependent lookup at the point of instantiation
[-fpermissive]
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:326:5:
note: declarations in dependent base ?FreeList<Metachunk>? are not found by
unqualified lookup
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:326:5:
note: use ?this->link_tail? instead
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
In instantiation of ?void TreeList<Chunk_t,
FreeList_t>::return_chunk_at_tail(TreeChunk<Chunk_t, FreeList_t>*) [with
Chunk_t = Metachunk; FreeList_t = FreeList]?:
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1411:16:
  required from here
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:299:3:
error: ?link_tail? was not declared in this scope, and no declarations were
found by argument-dependent lookup at the point of instantiation
[-fpermissive]
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:299:3:
note: declarations in dependent base ?FreeList<Metachunk>? are not found by
unqualified lookup
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:299:3:
note: use ?this->link_tail? instead
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
In instantiation of ?TreeList<Chunk_t, FreeList_t>* TreeList<Chunk_t,
FreeList_t>::remove_chunk_replace_if_needed(TreeChunk<Chunk_t,
FreeList_t>*) [with Chunk_t = FreeChunk; FreeList_t = AdaptiveFreeList]?:
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1418:16:
  required from here
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:242:7:
error: ?link_tail? was not declared in this scope, and no declarations were
found by argument-dependent lookup at the point of instantiation
[-fpermissive]
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:242:7:
note: declarations in dependent base ?FreeList<FreeChunk>? are not found by
unqualified lookup
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:242:7:
note: use ?this->link_tail? instead
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
In instantiation of ?void TreeList<Chunk_t,
FreeList_t>::return_chunk_at_head(TreeChunk<Chunk_t, FreeList_t>*) [with
Chunk_t = FreeChunk; FreeList_t = AdaptiveFreeList]?:
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1418:16:
  required from here
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:326:5:
error: ?link_tail? was not declared in this scope, and no declarations were
found by argument-dependent lookup at the point of instantiation
[-fpermissive]
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:326:5:
note: declarations in dependent base ?FreeList<FreeChunk>? are not found by
unqualified lookup
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:326:5:
note: use ?this->link_tail? instead
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
In instantiation of ?void TreeList<Chunk_t,
FreeList_t>::return_chunk_at_tail(TreeChunk<Chunk_t, FreeList_t>*) [with
Chunk_t = FreeChunk; FreeList_t = AdaptiveFreeList]?:
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1418:16:
  required from here
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:299:3:
error: ?link_tail? was not declared in this scope, and no declarations were
found by argument-dependent lookup at the point of instantiation
[-fpermissive]
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:299:3:
note: declarations in dependent base ?FreeList<FreeChunk>? are not found by
unqualified lookup
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:299:3:
note: use ?this->link_tail? instead
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
In instantiation of ?bool DescendTreeSearchClosure<Chunk_t,
FreeList_t>::do_tree(TreeList<Chunk_t, FreeList_t>*) [with Chunk_t =
Metablock; FreeList_t = FreeList]?:
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1058:42:
  required from ?Chunk_t* BinaryTreeDictionary<Chunk_t,
FreeList_t>::find_chunk_ends_at(HeapWord*) const [with Chunk_t = Metablock;
FreeList_t = FreeList]?
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1408:16:
  required from here
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1025:7:
error: ?do_list? was not declared in this scope, and no declarations were
found by argument-dependent lookup at the point of instantiation
[-fpermissive]
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1025:7:
note: declarations in dependent base ?TreeSearchClosure<Metablock,
FreeList>? are not found by unqualified lookup
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1025:7:
note: use ?this->do_list? instead
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
In instantiation of ?void AscendTreeCensusClosure<Chunk_t,
FreeList_t>::do_tree(TreeList<Chunk_t, FreeList_t>*) [with Chunk_t =
Metablock; FreeList_t = FreeList]?:
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1070:3:
  required from ?void BinaryTreeDictionary<Chunk_t,
FreeList_t>::begin_sweep_dict_census(double, float, float, float) [with
Chunk_t = Metablock; FreeList_t = FreeList]?
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1408:16:
  required from here
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:943:7:
error: ?do_list? was not declared in this scope, and no declarations were
found by argument-dependent lookup at the point of instantiation
[-fpermissive]
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:943:7:
note: declarations in dependent base ?TreeCensusClosure<Metablock,
FreeList>? are not found by unqualified lookup
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:943:7:
note: use ?this->do_list? instead
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
In instantiation of ?void DescendTreeCensusClosure<Chunk_t,
FreeList_t>::do_tree(TreeList<Chunk_t, FreeList_t>*) [with Chunk_t =
Metablock; FreeList_t = FreeList]?:
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1174:3:
  required from ?void BinaryTreeDictionary<Chunk_t,
FreeList_t>::set_tree_hints() [with Chunk_t = Metablock; FreeList_t =
FreeList]?
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1408:16:
  required from here
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:955:7:
error: ?do_list? was not declared in this scope, and no declarations were
found by argument-dependent lookup at the point of instantiation
[-fpermissive]
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:955:7:
note: declarations in dependent base ?TreeCensusClosure<Metablock,
FreeList>? are not found by unqualified lookup
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:955:7:
note: use ?this->do_list? instead
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
In instantiation of ?bool DescendTreeSearchClosure<Chunk_t,
FreeList_t>::do_tree(TreeList<Chunk_t, FreeList_t>*) [with Chunk_t =
Metachunk; FreeList_t = FreeList]?:
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1058:42:
  required from ?Chunk_t* BinaryTreeDictionary<Chunk_t,
FreeList_t>::find_chunk_ends_at(HeapWord*) const [with Chunk_t = Metachunk;
FreeList_t = FreeList]?
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1412:16:
  required from here
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1025:7:
error: ?do_list? was not declared in this scope, and no declarations were
found by argument-dependent lookup at the point of instantiation
[-fpermissive]
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1025:7:
note: declarations in dependent base ?TreeSearchClosure<Metachunk,
FreeList>? are not found by unqualified lookup
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1025:7:
note: use ?this->do_list? instead
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
In instantiation of ?void AscendTreeCensusClosure<Chunk_t,
FreeList_t>::do_tree(TreeList<Chunk_t, FreeList_t>*) [with Chunk_t =
Metachunk; FreeList_t = FreeList]?:
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1070:3:
  required from ?void BinaryTreeDictionary<Chunk_t,
FreeList_t>::begin_sweep_dict_census(double, float, float, float) [with
Chunk_t = Metachunk; FreeList_t = FreeList]?
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1412:16:
  required from here
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:943:7:
error: ?do_list? was not declared in this scope, and no declarations were
found by argument-dependent lookup at the point of instantiation
[-fpermissive]
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:943:7:
note: declarations in dependent base ?TreeCensusClosure<Metachunk,
FreeList>? are not found by unqualified lookup
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:943:7:
note: use ?this->do_list? instead
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
In instantiation of ?void DescendTreeCensusClosure<Chunk_t,
FreeList_t>::do_tree(TreeList<Chunk_t, FreeList_t>*) [with Chunk_t =
Metachunk; FreeList_t = FreeList]?:
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1174:3:
  required from ?void BinaryTreeDictionary<Chunk_t,
FreeList_t>::set_tree_hints() [with Chunk_t = Metachunk; FreeList_t =
FreeList]?
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1412:16:
  required from here
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:955:7:
error: ?do_list? was not declared in this scope, and no declarations were
found by argument-dependent lookup at the point of instantiation
[-fpermissive]
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:955:7:
note: declarations in dependent base ?TreeCensusClosure<Metachunk,
FreeList>? are not found by unqualified lookup
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:955:7:
note: use ?this->do_list? instead
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
In instantiation of ?bool DescendTreeSearchClosure<Chunk_t,
FreeList_t>::do_tree(TreeList<Chunk_t, FreeList_t>*) [with Chunk_t =
FreeChunk; FreeList_t = AdaptiveFreeList]?:
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1058:42:
  required from ?Chunk_t* BinaryTreeDictionary<Chunk_t,
FreeList_t>::find_chunk_ends_at(HeapWord*) const [with Chunk_t = FreeChunk;
FreeList_t = AdaptiveFreeList]?
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1419:16:
  required from here
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1025:7:
error: ?do_list? was not declared in this scope, and no declarations were
found by argument-dependent lookup at the point of instantiation
[-fpermissive]
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1025:7:
note: declarations in dependent base ?TreeSearchClosure<FreeChunk,
AdaptiveFreeList>? are not found by unqualified lookup
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1025:7:
note: use ?this->do_list? instead
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
In instantiation of ?void DescendTreeCensusClosure<Chunk_t,
FreeList_t>::do_tree(TreeList<Chunk_t, FreeList_t>*) [with Chunk_t =
FreeChunk; FreeList_t = AdaptiveFreeList]?:
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1174:3:
  required from ?void BinaryTreeDictionary<Chunk_t,
FreeList_t>::set_tree_hints() [with Chunk_t = FreeChunk; FreeList_t =
AdaptiveFreeList]?
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1419:16:
  required from here
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:955:7:
error: ?do_list? was not declared in this scope, and no declarations were
found by argument-dependent lookup at the point of instantiation
[-fpermissive]
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:955:7:
note: declarations in dependent base ?TreeCensusClosure<FreeChunk,
AdaptiveFreeList>? are not found by unqualified lookup
/home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:955:7:
note: use ?this->do_list? instead
make[6]: *** [binaryTreeDictionary.o] Error 1
make[6]: *** Waiting for unfinished jobs....
make[5]: *** [the_vm] Error 2
make[4]: *** [product] Error 2
make[3]: *** [generic_build2] Error 2
make[2]: *** [product] Error 2
make[1]: ***
[/home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp]
Error 2
make: *** [hotspot-only] Error 2

Any thoughts?

Regards,
Mani

-- 
Twitter: @theNeomatrix369
Blog: http://neomatrix369.wordpress.com <http://neomatrxi369.wordpress.com>

*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*


From david.holmes at oracle.com  Sun Nov 11 14:41:55 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 12 Nov 2012 08:41:55 +1000
Subject: Error when running make clean (hotspot) under Ubuntu 12.10
In-Reply-To: <CAGHtMW=OQKqUV8sW+QadXrkU8DkvCcpQy_b2uzjtcDYGekWmtQ@mail.gmail.com>
References: <CAGHtMW=OQKqUV8sW+QadXrkU8DkvCcpQy_b2uzjtcDYGekWmtQ@mail.gmail.com>
Message-ID: <50A029B3.9080601@oracle.com>

This is a hotspot issue. A recent push of the NPG changes broke a 
previous changeset that allowed compilation under GCC 4.7.2

Workaround is to add this-> as directed; or do put in the missing using 
directives. See:

http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-November/004737.html

David

On 12/11/2012 8:27 AM, Mani Sarkar wrote:
> Hi all,
>
> Can you please help us out with this issue when building the openJDK using
> infra-build under Ubuntu 12.10. I have attached a snippet of the error
> message Log files are also available if you need them (>  1.05mb).
>
> Compiling
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/blockOffsetTable.cpp
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
> In instantiation of ?void AscendTreeCensusClosure<Chunk_t,
> FreeList_t>::do_tree(TreeList<Chunk_t, FreeList_t>*) [with Chunk_t =
> FreeChunk; FreeList_t = AdaptiveFreeList]?:
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1295:21:
>    required from here
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:943:7:
> error: ?do_list? was not declared in this scope, and no declarations were
> found by argument-dependent lookup at the point of instantiation
> [-fpermissive]
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:943:7:
> note: declarations in dependent base ?TreeCensusClosure<FreeChunk,
> AdaptiveFreeList>? are not found by unqualified lookup
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:943:7:
> note: use ?this->do_list? instead
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
> In instantiation of ?TreeList<Chunk_t, FreeList_t>* TreeList<Chunk_t,
> FreeList_t>::remove_chunk_replace_if_needed(TreeChunk<Chunk_t,
> FreeList_t>*) [with Chunk_t = Metablock; FreeList_t = FreeList]?:
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1407:16:
>    required from here
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:242:7:
> error: ?link_tail? was not declared in this scope, and no declarations were
> found by argument-dependent lookup at the point of instantiation
> [-fpermissive]
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:242:7:
> note: declarations in dependent base ?FreeList<Metablock>? are not found by
> unqualified lookup
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:242:7:
> note: use ?this->link_tail? instead
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
> In instantiation of ?void TreeList<Chunk_t,
> FreeList_t>::return_chunk_at_head(TreeChunk<Chunk_t, FreeList_t>*) [with
> Chunk_t = Metablock; FreeList_t = FreeList]?:
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1407:16:
>    required from here
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:326:5:
> error: ?link_tail? was not declared in this scope, and no declarations were
> found by argument-dependent lookup at the point of instantiation
> [-fpermissive]
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:326:5:
> note: declarations in dependent base ?FreeList<Metablock>? are not found by
> unqualified lookup
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:326:5:
> note: use ?this->link_tail? instead
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
> In instantiation of ?void TreeList<Chunk_t,
> FreeList_t>::return_chunk_at_tail(TreeChunk<Chunk_t, FreeList_t>*) [with
> Chunk_t = Metablock; FreeList_t = FreeList]?:
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1407:16:
>    required from here
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:299:3:
> error: ?link_tail? was not declared in this scope, and no declarations were
> found by argument-dependent lookup at the point of instantiation
> [-fpermissive]
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:299:3:
> note: declarations in dependent base ?FreeList<Metablock>? are not found by
> unqualified lookup
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:299:3:
> note: use ?this->link_tail? instead
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
> In instantiation of ?TreeList<Chunk_t, FreeList_t>* TreeList<Chunk_t,
> FreeList_t>::remove_chunk_replace_if_needed(TreeChunk<Chunk_t,
> FreeList_t>*) [with Chunk_t = Metachunk; FreeList_t = FreeList]?:
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1411:16:
>    required from here
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:242:7:
> error: ?link_tail? was not declared in this scope, and no declarations were
> found by argument-dependent lookup at the point of instantiation
> [-fpermissive]
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:242:7:
> note: declarations in dependent base ?FreeList<Metachunk>? are not found by
> unqualified lookup
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:242:7:
> note: use ?this->link_tail? instead
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
> In instantiation of ?void TreeList<Chunk_t,
> FreeList_t>::return_chunk_at_head(TreeChunk<Chunk_t, FreeList_t>*) [with
> Chunk_t = Metachunk; FreeList_t = FreeList]?:
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1411:16:
>    required from here
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:326:5:
> error: ?link_tail? was not declared in this scope, and no declarations were
> found by argument-dependent lookup at the point of instantiation
> [-fpermissive]
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:326:5:
> note: declarations in dependent base ?FreeList<Metachunk>? are not found by
> unqualified lookup
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:326:5:
> note: use ?this->link_tail? instead
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
> In instantiation of ?void TreeList<Chunk_t,
> FreeList_t>::return_chunk_at_tail(TreeChunk<Chunk_t, FreeList_t>*) [with
> Chunk_t = Metachunk; FreeList_t = FreeList]?:
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1411:16:
>    required from here
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:299:3:
> error: ?link_tail? was not declared in this scope, and no declarations were
> found by argument-dependent lookup at the point of instantiation
> [-fpermissive]
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:299:3:
> note: declarations in dependent base ?FreeList<Metachunk>? are not found by
> unqualified lookup
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:299:3:
> note: use ?this->link_tail? instead
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
> In instantiation of ?TreeList<Chunk_t, FreeList_t>* TreeList<Chunk_t,
> FreeList_t>::remove_chunk_replace_if_needed(TreeChunk<Chunk_t,
> FreeList_t>*) [with Chunk_t = FreeChunk; FreeList_t = AdaptiveFreeList]?:
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1418:16:
>    required from here
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:242:7:
> error: ?link_tail? was not declared in this scope, and no declarations were
> found by argument-dependent lookup at the point of instantiation
> [-fpermissive]
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:242:7:
> note: declarations in dependent base ?FreeList<FreeChunk>? are not found by
> unqualified lookup
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:242:7:
> note: use ?this->link_tail? instead
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
> In instantiation of ?void TreeList<Chunk_t,
> FreeList_t>::return_chunk_at_head(TreeChunk<Chunk_t, FreeList_t>*) [with
> Chunk_t = FreeChunk; FreeList_t = AdaptiveFreeList]?:
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1418:16:
>    required from here
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:326:5:
> error: ?link_tail? was not declared in this scope, and no declarations were
> found by argument-dependent lookup at the point of instantiation
> [-fpermissive]
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:326:5:
> note: declarations in dependent base ?FreeList<FreeChunk>? are not found by
> unqualified lookup
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:326:5:
> note: use ?this->link_tail? instead
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
> In instantiation of ?void TreeList<Chunk_t,
> FreeList_t>::return_chunk_at_tail(TreeChunk<Chunk_t, FreeList_t>*) [with
> Chunk_t = FreeChunk; FreeList_t = AdaptiveFreeList]?:
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1418:16:
>    required from here
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:299:3:
> error: ?link_tail? was not declared in this scope, and no declarations were
> found by argument-dependent lookup at the point of instantiation
> [-fpermissive]
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:299:3:
> note: declarations in dependent base ?FreeList<FreeChunk>? are not found by
> unqualified lookup
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:299:3:
> note: use ?this->link_tail? instead
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
> In instantiation of ?bool DescendTreeSearchClosure<Chunk_t,
> FreeList_t>::do_tree(TreeList<Chunk_t, FreeList_t>*) [with Chunk_t =
> Metablock; FreeList_t = FreeList]?:
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1058:42:
>    required from ?Chunk_t* BinaryTreeDictionary<Chunk_t,
> FreeList_t>::find_chunk_ends_at(HeapWord*) const [with Chunk_t = Metablock;
> FreeList_t = FreeList]?
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1408:16:
>    required from here
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1025:7:
> error: ?do_list? was not declared in this scope, and no declarations were
> found by argument-dependent lookup at the point of instantiation
> [-fpermissive]
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1025:7:
> note: declarations in dependent base ?TreeSearchClosure<Metablock,
> FreeList>? are not found by unqualified lookup
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1025:7:
> note: use ?this->do_list? instead
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
> In instantiation of ?void AscendTreeCensusClosure<Chunk_t,
> FreeList_t>::do_tree(TreeList<Chunk_t, FreeList_t>*) [with Chunk_t =
> Metablock; FreeList_t = FreeList]?:
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1070:3:
>    required from ?void BinaryTreeDictionary<Chunk_t,
> FreeList_t>::begin_sweep_dict_census(double, float, float, float) [with
> Chunk_t = Metablock; FreeList_t = FreeList]?
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1408:16:
>    required from here
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:943:7:
> error: ?do_list? was not declared in this scope, and no declarations were
> found by argument-dependent lookup at the point of instantiation
> [-fpermissive]
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:943:7:
> note: declarations in dependent base ?TreeCensusClosure<Metablock,
> FreeList>? are not found by unqualified lookup
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:943:7:
> note: use ?this->do_list? instead
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
> In instantiation of ?void DescendTreeCensusClosure<Chunk_t,
> FreeList_t>::do_tree(TreeList<Chunk_t, FreeList_t>*) [with Chunk_t =
> Metablock; FreeList_t = FreeList]?:
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1174:3:
>    required from ?void BinaryTreeDictionary<Chunk_t,
> FreeList_t>::set_tree_hints() [with Chunk_t = Metablock; FreeList_t =
> FreeList]?
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1408:16:
>    required from here
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:955:7:
> error: ?do_list? was not declared in this scope, and no declarations were
> found by argument-dependent lookup at the point of instantiation
> [-fpermissive]
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:955:7:
> note: declarations in dependent base ?TreeCensusClosure<Metablock,
> FreeList>? are not found by unqualified lookup
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:955:7:
> note: use ?this->do_list? instead
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
> In instantiation of ?bool DescendTreeSearchClosure<Chunk_t,
> FreeList_t>::do_tree(TreeList<Chunk_t, FreeList_t>*) [with Chunk_t =
> Metachunk; FreeList_t = FreeList]?:
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1058:42:
>    required from ?Chunk_t* BinaryTreeDictionary<Chunk_t,
> FreeList_t>::find_chunk_ends_at(HeapWord*) const [with Chunk_t = Metachunk;
> FreeList_t = FreeList]?
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1412:16:
>    required from here
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1025:7:
> error: ?do_list? was not declared in this scope, and no declarations were
> found by argument-dependent lookup at the point of instantiation
> [-fpermissive]
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1025:7:
> note: declarations in dependent base ?TreeSearchClosure<Metachunk,
> FreeList>? are not found by unqualified lookup
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1025:7:
> note: use ?this->do_list? instead
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
> In instantiation of ?void AscendTreeCensusClosure<Chunk_t,
> FreeList_t>::do_tree(TreeList<Chunk_t, FreeList_t>*) [with Chunk_t =
> Metachunk; FreeList_t = FreeList]?:
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1070:3:
>    required from ?void BinaryTreeDictionary<Chunk_t,
> FreeList_t>::begin_sweep_dict_census(double, float, float, float) [with
> Chunk_t = Metachunk; FreeList_t = FreeList]?
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1412:16:
>    required from here
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:943:7:
> error: ?do_list? was not declared in this scope, and no declarations were
> found by argument-dependent lookup at the point of instantiation
> [-fpermissive]
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:943:7:
> note: declarations in dependent base ?TreeCensusClosure<Metachunk,
> FreeList>? are not found by unqualified lookup
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:943:7:
> note: use ?this->do_list? instead
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
> In instantiation of ?void DescendTreeCensusClosure<Chunk_t,
> FreeList_t>::do_tree(TreeList<Chunk_t, FreeList_t>*) [with Chunk_t =
> Metachunk; FreeList_t = FreeList]?:
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1174:3:
>    required from ?void BinaryTreeDictionary<Chunk_t,
> FreeList_t>::set_tree_hints() [with Chunk_t = Metachunk; FreeList_t =
> FreeList]?
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1412:16:
>    required from here
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:955:7:
> error: ?do_list? was not declared in this scope, and no declarations were
> found by argument-dependent lookup at the point of instantiation
> [-fpermissive]
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:955:7:
> note: declarations in dependent base ?TreeCensusClosure<Metachunk,
> FreeList>? are not found by unqualified lookup
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:955:7:
> note: use ?this->do_list? instead
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
> In instantiation of ?bool DescendTreeSearchClosure<Chunk_t,
> FreeList_t>::do_tree(TreeList<Chunk_t, FreeList_t>*) [with Chunk_t =
> FreeChunk; FreeList_t = AdaptiveFreeList]?:
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1058:42:
>    required from ?Chunk_t* BinaryTreeDictionary<Chunk_t,
> FreeList_t>::find_chunk_ends_at(HeapWord*) const [with Chunk_t = FreeChunk;
> FreeList_t = AdaptiveFreeList]?
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1419:16:
>    required from here
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1025:7:
> error: ?do_list? was not declared in this scope, and no declarations were
> found by argument-dependent lookup at the point of instantiation
> [-fpermissive]
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1025:7:
> note: declarations in dependent base ?TreeSearchClosure<FreeChunk,
> AdaptiveFreeList>? are not found by unqualified lookup
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1025:7:
> note: use ?this->do_list? instead
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
> In instantiation of ?void DescendTreeCensusClosure<Chunk_t,
> FreeList_t>::do_tree(TreeList<Chunk_t, FreeList_t>*) [with Chunk_t =
> FreeChunk; FreeList_t = AdaptiveFreeList]?:
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1174:3:
>    required from ?void BinaryTreeDictionary<Chunk_t,
> FreeList_t>::set_tree_hints() [with Chunk_t = FreeChunk; FreeList_t =
> AdaptiveFreeList]?
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:1419:16:
>    required from here
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:955:7:
> error: ?do_list? was not declared in this scope, and no declarations were
> found by argument-dependent lookup at the point of instantiation
> [-fpermissive]
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:955:7:
> note: declarations in dependent base ?TreeCensusClosure<FreeChunk,
> AdaptiveFreeList>? are not found by unqualified lookup
> /home/openjdk/sources/jdk8_tl/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:955:7:
> note: use ?this->do_list? instead
> make[6]: *** [binaryTreeDictionary.o] Error 1
> make[6]: *** Waiting for unfinished jobs....
> make[5]: *** [the_vm] Error 2
> make[4]: *** [product] Error 2
> make[3]: *** [generic_build2] Error 2
> make[2]: *** [product] Error 2
> make[1]: ***
> [/home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp]
> Error 2
> make: *** [hotspot-only] Error 2
>
> Any thoughts?
>
> Regards,
> Mani
>


From martijnverburg at gmail.com  Sun Nov 11 14:45:48 2012
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Sun, 11 Nov 2012 22:45:48 +0000
Subject: cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
	error in build-infra build ('old' build works OK)
Message-ID: <CAP7YuAT+X+BfcsFm=tZk3orEHyFh=_eK07B1KUPmJ106CnREyw@mail.gmail.com>

Hi all,

Building jdk8_tl on Ubuntu 12.04 with OpenJDK Runtime Environment (IcedTea7
2.3.3) (7u9-2.3.3-0ubuntu1~12.04.1)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode). I get the following
compilation error using build-infra (but not the 'old' build).

/home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:
In function `UnrollHalfToFloat':
cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
cmspack.c:(.text+0x27c6): undefined reference to `_cmsHalf2Float'
/home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:
In function `UnrollHalfTo16':
cmspack.c:(.text+0x2953): undefined reference to `_cmsHalf2Float'
cmspack.c:(.text+0x29fa): undefined reference to `_cmsHalf2Float'
/home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:
In function `PackHalfFromFloat':
cmspack.c:(.text+0x2baf): undefined reference to `_cmsFloat2Half'
cmspack.c:(.text+0x2c10): undefined reference to `_cmsFloat2Half'
cmspack.c:(.text+0x2ccb): undefined reference to `_cmsFloat2Half'
/home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:
In function `PackHalfFrom16':
cmspack.c:(.text+0x2de7): undefined reference to `_cmsFloat2Half'
cmspack.c:(.text+0x2e4d): undefined reference to `_cmsFloat2Half'
/home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:cmspack.c:(.text+0x2f01):
more undefined references to `_cmsFloat2Half' follow
collect2: ld returned 1 exit status
make[2]: ***
[/home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/lib/amd64/liblcms.so]
Error 1
make[1]: *** [libs-only] Error 2
make: *** [jdk-only] Error 2

Haven't tracked it down any further than this yet, but thought I should
report it in :-).

Cheers,
Martijn


From david.holmes at oracle.com  Sun Nov 11 15:02:30 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 12 Nov 2012 09:02:30 +1000
Subject: cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
	error in build-infra build ('old' build works OK)
In-Reply-To: <CAP7YuAT+X+BfcsFm=tZk3orEHyFh=_eK07B1KUPmJ106CnREyw@mail.gmail.com>
References: <CAP7YuAT+X+BfcsFm=tZk3orEHyFh=_eK07B1KUPmJ106CnREyw@mail.gmail.com>
Message-ID: <50A02E86.6080002@oracle.com>

Hi Martijn,

Known issue fixed a couple of days ago:

http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/1e79fec4a01f

David

On 12/11/2012 8:45 AM, Martijn Verburg wrote:
> Hi all,
>
> Building jdk8_tl on Ubuntu 12.04 with OpenJDK Runtime Environment (IcedTea7
> 2.3.3) (7u9-2.3.3-0ubuntu1~12.04.1)
> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode). I get the following
> compilation error using build-infra (but not the 'old' build).
>
> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:
> In function `UnrollHalfToFloat':
> cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
> cmspack.c:(.text+0x27c6): undefined reference to `_cmsHalf2Float'
> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:
> In function `UnrollHalfTo16':
> cmspack.c:(.text+0x2953): undefined reference to `_cmsHalf2Float'
> cmspack.c:(.text+0x29fa): undefined reference to `_cmsHalf2Float'
> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:
> In function `PackHalfFromFloat':
> cmspack.c:(.text+0x2baf): undefined reference to `_cmsFloat2Half'
> cmspack.c:(.text+0x2c10): undefined reference to `_cmsFloat2Half'
> cmspack.c:(.text+0x2ccb): undefined reference to `_cmsFloat2Half'
> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:
> In function `PackHalfFrom16':
> cmspack.c:(.text+0x2de7): undefined reference to `_cmsFloat2Half'
> cmspack.c:(.text+0x2e4d): undefined reference to `_cmsFloat2Half'
> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:cmspack.c:(.text+0x2f01):
> more undefined references to `_cmsFloat2Half' follow
> collect2: ld returned 1 exit status
> make[2]: ***
> [/home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/lib/amd64/liblcms.so]
> Error 1
> make[1]: *** [libs-only] Error 2
> make: *** [jdk-only] Error 2
>
> Haven't tracked it down any further than this yet, but thought I should
> report it in :-).
>
> Cheers,
> Martijn


From sadhak001 at gmail.com  Sun Nov 11 15:41:33 2012
From: sadhak001 at gmail.com (Mani Sarkar)
Date: Sun, 11 Nov 2012 23:41:33 +0000
Subject: Error when running make clean (hotspot) under Ubuntu 12.10
In-Reply-To: <50A029B3.9080601@oracle.com>
References: <CAGHtMW=OQKqUV8sW+QadXrkU8DkvCcpQy_b2uzjtcDYGekWmtQ@mail.gmail.com>
	<50A029B3.9080601@oracle.com>
Message-ID: <CAGHtMWkVWOxps3AXcWjSjnEuoe2rDLsSoHYfWZ3mQdHPKeWKGA@mail.gmail.com>

Thanks David, Ill keep you posted of the outcome of the below!

Cheers,
Mani

On Sun, Nov 11, 2012 at 10:41 PM, David Holmes <david.holmes at oracle.com>wrote:

> This is a hotspot issue. A recent push of the NPG changes broke a previous
> changeset that allowed compilation under GCC 4.7.2
>
> Workaround is to add this-> as directed; or do put in the missing using
> directives. See:
>
> http://mail.openjdk.java.net/**pipermail/hotspot-runtime-dev/**
> 2012-November/004737.html<http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-November/004737.html>
>
> David
>
>
> On 12/11/2012 8:27 AM, Mani Sarkar wrote:
>
>> Hi all,
>>
>> Can you please help us out with this issue when building the openJDK using
>> infra-build under Ubuntu 12.10. I have attached a snippet of the error
>> message Log files are also available if you need them (>  1.05mb).
>>
>> Compiling
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> blockOffsetTable.cpp
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:
>> In instantiation of ?void AscendTreeCensusClosure<Chunk_**t,
>> FreeList_t>::do_tree(TreeList<**Chunk_t, FreeList_t>*) [with Chunk_t =
>> FreeChunk; FreeList_t = AdaptiveFreeList]?:
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1295:**21:
>>    required from here
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:943:**7:
>> error: ?do_list? was not declared in this scope, and no declarations were
>> found by argument-dependent lookup at the point of instantiation
>> [-fpermissive]
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:943:**7:
>> note: declarations in dependent base ?TreeCensusClosure<FreeChunk,
>> AdaptiveFreeList>? are not found by unqualified lookup
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:943:**7:
>> note: use ?this->do_list? instead
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:
>> In instantiation of ?TreeList<Chunk_t, FreeList_t>* TreeList<Chunk_t,
>> FreeList_t>::remove_chunk_**replace_if_needed(TreeChunk<**Chunk_t,
>> FreeList_t>*) [with Chunk_t = Metablock; FreeList_t = FreeList]?:
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1407:**16:
>>    required from here
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:242:**7:
>> error: ?link_tail? was not declared in this scope, and no declarations
>> were
>> found by argument-dependent lookup at the point of instantiation
>> [-fpermissive]
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:242:**7:
>> note: declarations in dependent base ?FreeList<Metablock>? are not found
>> by
>> unqualified lookup
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:242:**7:
>> note: use ?this->link_tail? instead
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:
>> In instantiation of ?void TreeList<Chunk_t,
>> FreeList_t>::return_chunk_at_**head(TreeChunk<Chunk_t, FreeList_t>*)
>> [with
>> Chunk_t = Metablock; FreeList_t = FreeList]?:
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1407:**16:
>>    required from here
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:326:**5:
>> error: ?link_tail? was not declared in this scope, and no declarations
>> were
>> found by argument-dependent lookup at the point of instantiation
>> [-fpermissive]
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:326:**5:
>> note: declarations in dependent base ?FreeList<Metablock>? are not found
>> by
>> unqualified lookup
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:326:**5:
>> note: use ?this->link_tail? instead
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:
>> In instantiation of ?void TreeList<Chunk_t,
>> FreeList_t>::return_chunk_at_**tail(TreeChunk<Chunk_t, FreeList_t>*)
>> [with
>> Chunk_t = Metablock; FreeList_t = FreeList]?:
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1407:**16:
>>    required from here
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:299:**3:
>> error: ?link_tail? was not declared in this scope, and no declarations
>> were
>> found by argument-dependent lookup at the point of instantiation
>> [-fpermissive]
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:299:**3:
>> note: declarations in dependent base ?FreeList<Metablock>? are not found
>> by
>> unqualified lookup
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:299:**3:
>> note: use ?this->link_tail? instead
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:
>> In instantiation of ?TreeList<Chunk_t, FreeList_t>* TreeList<Chunk_t,
>> FreeList_t>::remove_chunk_**replace_if_needed(TreeChunk<**Chunk_t,
>> FreeList_t>*) [with Chunk_t = Metachunk; FreeList_t = FreeList]?:
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1411:**16:
>>    required from here
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:242:**7:
>> error: ?link_tail? was not declared in this scope, and no declarations
>> were
>> found by argument-dependent lookup at the point of instantiation
>> [-fpermissive]
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:242:**7:
>> note: declarations in dependent base ?FreeList<Metachunk>? are not found
>> by
>> unqualified lookup
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:242:**7:
>> note: use ?this->link_tail? instead
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:
>> In instantiation of ?void TreeList<Chunk_t,
>> FreeList_t>::return_chunk_at_**head(TreeChunk<Chunk_t, FreeList_t>*)
>> [with
>> Chunk_t = Metachunk; FreeList_t = FreeList]?:
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1411:**16:
>>    required from here
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:326:**5:
>> error: ?link_tail? was not declared in this scope, and no declarations
>> were
>> found by argument-dependent lookup at the point of instantiation
>> [-fpermissive]
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:326:**5:
>> note: declarations in dependent base ?FreeList<Metachunk>? are not found
>> by
>> unqualified lookup
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:326:**5:
>> note: use ?this->link_tail? instead
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:
>> In instantiation of ?void TreeList<Chunk_t,
>> FreeList_t>::return_chunk_at_**tail(TreeChunk<Chunk_t, FreeList_t>*)
>> [with
>> Chunk_t = Metachunk; FreeList_t = FreeList]?:
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1411:**16:
>>    required from here
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:299:**3:
>> error: ?link_tail? was not declared in this scope, and no declarations
>> were
>> found by argument-dependent lookup at the point of instantiation
>> [-fpermissive]
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:299:**3:
>> note: declarations in dependent base ?FreeList<Metachunk>? are not found
>> by
>> unqualified lookup
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:299:**3:
>> note: use ?this->link_tail? instead
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:
>> In instantiation of ?TreeList<Chunk_t, FreeList_t>* TreeList<Chunk_t,
>> FreeList_t>::remove_chunk_**replace_if_needed(TreeChunk<**Chunk_t,
>> FreeList_t>*) [with Chunk_t = FreeChunk; FreeList_t = AdaptiveFreeList]?:
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1418:**16:
>>    required from here
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:242:**7:
>> error: ?link_tail? was not declared in this scope, and no declarations
>> were
>> found by argument-dependent lookup at the point of instantiation
>> [-fpermissive]
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:242:**7:
>> note: declarations in dependent base ?FreeList<FreeChunk>? are not found
>> by
>> unqualified lookup
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:242:**7:
>> note: use ?this->link_tail? instead
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:
>> In instantiation of ?void TreeList<Chunk_t,
>> FreeList_t>::return_chunk_at_**head(TreeChunk<Chunk_t, FreeList_t>*)
>> [with
>> Chunk_t = FreeChunk; FreeList_t = AdaptiveFreeList]?:
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1418:**16:
>>    required from here
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:326:**5:
>> error: ?link_tail? was not declared in this scope, and no declarations
>> were
>> found by argument-dependent lookup at the point of instantiation
>> [-fpermissive]
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:326:**5:
>> note: declarations in dependent base ?FreeList<FreeChunk>? are not found
>> by
>> unqualified lookup
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:326:**5:
>> note: use ?this->link_tail? instead
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:
>> In instantiation of ?void TreeList<Chunk_t,
>> FreeList_t>::return_chunk_at_**tail(TreeChunk<Chunk_t, FreeList_t>*)
>> [with
>> Chunk_t = FreeChunk; FreeList_t = AdaptiveFreeList]?:
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1418:**16:
>>    required from here
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:299:**3:
>> error: ?link_tail? was not declared in this scope, and no declarations
>> were
>> found by argument-dependent lookup at the point of instantiation
>> [-fpermissive]
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:299:**3:
>> note: declarations in dependent base ?FreeList<FreeChunk>? are not found
>> by
>> unqualified lookup
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:299:**3:
>> note: use ?this->link_tail? instead
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:
>> In instantiation of ?bool DescendTreeSearchClosure<**Chunk_t,
>> FreeList_t>::do_tree(TreeList<**Chunk_t, FreeList_t>*) [with Chunk_t =
>> Metablock; FreeList_t = FreeList]?:
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1058:**42:
>>    required from ?Chunk_t* BinaryTreeDictionary<Chunk_t,
>> FreeList_t>::find_chunk_ends_**at(HeapWord*) const [with Chunk_t =
>> Metablock;
>> FreeList_t = FreeList]?
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1408:**16:
>>    required from here
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1025:**7:
>> error: ?do_list? was not declared in this scope, and no declarations were
>> found by argument-dependent lookup at the point of instantiation
>> [-fpermissive]
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1025:**7:
>> note: declarations in dependent base ?TreeSearchClosure<Metablock,
>> FreeList>? are not found by unqualified lookup
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1025:**7:
>> note: use ?this->do_list? instead
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:
>> In instantiation of ?void AscendTreeCensusClosure<Chunk_**t,
>> FreeList_t>::do_tree(TreeList<**Chunk_t, FreeList_t>*) [with Chunk_t =
>> Metablock; FreeList_t = FreeList]?:
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1070:**3:
>>    required from ?void BinaryTreeDictionary<Chunk_t,
>> FreeList_t>::begin_sweep_dict_**census(double, float, float, float) [with
>> Chunk_t = Metablock; FreeList_t = FreeList]?
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1408:**16:
>>    required from here
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:943:**7:
>> error: ?do_list? was not declared in this scope, and no declarations were
>> found by argument-dependent lookup at the point of instantiation
>> [-fpermissive]
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:943:**7:
>> note: declarations in dependent base ?TreeCensusClosure<Metablock,
>> FreeList>? are not found by unqualified lookup
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:943:**7:
>> note: use ?this->do_list? instead
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:
>> In instantiation of ?void DescendTreeCensusClosure<**Chunk_t,
>> FreeList_t>::do_tree(TreeList<**Chunk_t, FreeList_t>*) [with Chunk_t =
>> Metablock; FreeList_t = FreeList]?:
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1174:**3:
>>    required from ?void BinaryTreeDictionary<Chunk_t,
>> FreeList_t>::set_tree_hints() [with Chunk_t = Metablock; FreeList_t =
>> FreeList]?
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1408:**16:
>>    required from here
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:955:**7:
>> error: ?do_list? was not declared in this scope, and no declarations were
>> found by argument-dependent lookup at the point of instantiation
>> [-fpermissive]
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:955:**7:
>> note: declarations in dependent base ?TreeCensusClosure<Metablock,
>> FreeList>? are not found by unqualified lookup
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:955:**7:
>> note: use ?this->do_list? instead
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:
>> In instantiation of ?bool DescendTreeSearchClosure<**Chunk_t,
>> FreeList_t>::do_tree(TreeList<**Chunk_t, FreeList_t>*) [with Chunk_t =
>> Metachunk; FreeList_t = FreeList]?:
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1058:**42:
>>    required from ?Chunk_t* BinaryTreeDictionary<Chunk_t,
>> FreeList_t>::find_chunk_ends_**at(HeapWord*) const [with Chunk_t =
>> Metachunk;
>> FreeList_t = FreeList]?
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1412:**16:
>>    required from here
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1025:**7:
>> error: ?do_list? was not declared in this scope, and no declarations were
>> found by argument-dependent lookup at the point of instantiation
>> [-fpermissive]
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1025:**7:
>> note: declarations in dependent base ?TreeSearchClosure<Metachunk,
>> FreeList>? are not found by unqualified lookup
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1025:**7:
>> note: use ?this->do_list? instead
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:
>> In instantiation of ?void AscendTreeCensusClosure<Chunk_**t,
>> FreeList_t>::do_tree(TreeList<**Chunk_t, FreeList_t>*) [with Chunk_t =
>> Metachunk; FreeList_t = FreeList]?:
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1070:**3:
>>    required from ?void BinaryTreeDictionary<Chunk_t,
>> FreeList_t>::begin_sweep_dict_**census(double, float, float, float) [with
>> Chunk_t = Metachunk; FreeList_t = FreeList]?
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1412:**16:
>>    required from here
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:943:**7:
>> error: ?do_list? was not declared in this scope, and no declarations were
>> found by argument-dependent lookup at the point of instantiation
>> [-fpermissive]
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:943:**7:
>> note: declarations in dependent base ?TreeCensusClosure<Metachunk,
>> FreeList>? are not found by unqualified lookup
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:943:**7:
>> note: use ?this->do_list? instead
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:
>> In instantiation of ?void DescendTreeCensusClosure<**Chunk_t,
>> FreeList_t>::do_tree(TreeList<**Chunk_t, FreeList_t>*) [with Chunk_t =
>> Metachunk; FreeList_t = FreeList]?:
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1174:**3:
>>    required from ?void BinaryTreeDictionary<Chunk_t,
>> FreeList_t>::set_tree_hints() [with Chunk_t = Metachunk; FreeList_t =
>> FreeList]?
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1412:**16:
>>    required from here
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:955:**7:
>> error: ?do_list? was not declared in this scope, and no declarations were
>> found by argument-dependent lookup at the point of instantiation
>> [-fpermissive]
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:955:**7:
>> note: declarations in dependent base ?TreeCensusClosure<Metachunk,
>> FreeList>? are not found by unqualified lookup
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:955:**7:
>> note: use ?this->do_list? instead
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:
>> In instantiation of ?bool DescendTreeSearchClosure<**Chunk_t,
>> FreeList_t>::do_tree(TreeList<**Chunk_t, FreeList_t>*) [with Chunk_t =
>> FreeChunk; FreeList_t = AdaptiveFreeList]?:
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1058:**42:
>>    required from ?Chunk_t* BinaryTreeDictionary<Chunk_t,
>> FreeList_t>::find_chunk_ends_**at(HeapWord*) const [with Chunk_t =
>> FreeChunk;
>> FreeList_t = AdaptiveFreeList]?
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1419:**16:
>>    required from here
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1025:**7:
>> error: ?do_list? was not declared in this scope, and no declarations were
>> found by argument-dependent lookup at the point of instantiation
>> [-fpermissive]
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1025:**7:
>> note: declarations in dependent base ?TreeSearchClosure<FreeChunk,
>> AdaptiveFreeList>? are not found by unqualified lookup
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1025:**7:
>> note: use ?this->do_list? instead
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:
>> In instantiation of ?void DescendTreeCensusClosure<**Chunk_t,
>> FreeList_t>::do_tree(TreeList<**Chunk_t, FreeList_t>*) [with Chunk_t =
>> FreeChunk; FreeList_t = AdaptiveFreeList]?:
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1174:**3:
>>    required from ?void BinaryTreeDictionary<Chunk_t,
>> FreeList_t>::set_tree_hints() [with Chunk_t = FreeChunk; FreeList_t =
>> AdaptiveFreeList]?
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:1419:**16:
>>    required from here
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:955:**7:
>> error: ?do_list? was not declared in this scope, and no declarations were
>> found by argument-dependent lookup at the point of instantiation
>> [-fpermissive]
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:955:**7:
>> note: declarations in dependent base ?TreeCensusClosure<FreeChunk,
>> AdaptiveFreeList>? are not found by unqualified lookup
>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>> binaryTreeDictionary.cpp:955:**7:
>> note: use ?this->do_list? instead
>> make[6]: *** [binaryTreeDictionary.o] Error 1
>> make[6]: *** Waiting for unfinished jobs....
>> make[5]: *** [the_vm] Error 2
>> make[4]: *** [product] Error 2
>> make[3]: *** [generic_build2] Error 2
>> make[2]: *** [product] Error 2
>> make[1]: ***
>> [/home/openjdk/sources/jdk8_**tl/build/linux-x86_64-normal-**
>> server-release/hotspot/_**hotspot.timestamp]
>> Error 2
>> make: *** [hotspot-only] Error 2
>>
>> Any thoughts?
>>
>> Regards,
>> Mani
>>
>>


-- 
Twitter: @theNeomatrix369
Blog: http://neomatrix369.wordpress.com <http://neomatrxi369.wordpress.com>

*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*


From martijnverburg at gmail.com  Sun Nov 11 16:00:34 2012
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Mon, 12 Nov 2012 00:00:34 +0000
Subject: cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
	error in build-infra build ('old' build works OK)
In-Reply-To: <50A02E86.6080002@oracle.com>
References: <CAP7YuAT+X+BfcsFm=tZk3orEHyFh=_eK07B1KUPmJ106CnREyw@mail.gmail.com>
	<50A02E86.6080002@oracle.com>
Message-ID: <CAP7YuATdnL+9pc6HS92MtfzZEanN3O=JamRee6LRJ=wftJGjrA@mail.gmail.com>

Ah thanks - guess my archive searching foo was less than adequate this time
around :-(.  Is there a recommended way to search them?

On 11 November 2012 23:02, David Holmes <david.holmes at oracle.com> wrote:

> http://hg.openjdk.java.net/**build-infra/jdk8/jdk/rev/**1e79fec4a01f<http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/1e79fec4a01f>


From erik.joelsson at oracle.com  Mon Nov 12 01:01:35 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 12 Nov 2012 10:01:35 +0100
Subject: Problems building JDK8 on x64 Linux with new build
In-Reply-To: <9C717C4C-8B54-4062-A4CB-D7591C8E68D2@oracle.com>
References: <2DC6706F-FA00-47B4-8C87-B1E91494C7A3@oracle.com>	<B795AE4B-7994-4BF3-B59E-A8E268D009E8@oracle.com>
	<9C717C4C-8B54-4062-A4CB-D7591C8E68D2@oracle.com>
Message-ID: <50A0BAEF.6090500@oracle.com>

Fredrik fixed both of these in jdk8/build as soon as we found out. The 
missing endif was a merge artifact with a stray '\' hiding it. The only 
way to prevent this that I can see would be for integrators to test both 
builds from now on.

/Erik

On 2012-11-10 03:12, Kelly O'Hair wrote:
> Fredrik fixed one endif related bug:
>
> http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/1e79fec4a01f
>
> -kto
>
> On Nov 9, 2012, at 5:11 PM, Mike Duigou wrote:
>
>> Backing out cc998992dc32 currently isn't sufficient to produce a working x64 Linux image with new build. There appears to also be a problem with CreateJars.gmk running the `images` target:
>>
>> make[2]: Entering directory `/home/mike/code/jdk/jdk8/jdk/makefiles'
>> /bin/sh: 1: cannot create /home/mike/code/jdk/jdk8/build/linux-x86_64-normal-server-fastdebug/images/lib/ext//_the.localedata.jar_include: Directory nonexistent
>> /bin/grep: /home/mike/code/jdk/jdk8/build/linux-x86_64-normal-server-fastdebug/images/lib/ext//_the.localedata.jar_include: No such file or directory
>> make[3]: Entering directory `/home/mike/code/jdk/jdk8/jdk/makefiles'
>> CreateJars.gmk:905: *** missing `endif'.  Stop.
>> make[3]: Leaving directory `/home/mike/code/jdk/jdk8/jdk/makefiles'
>>
>> I spent some time trying to find the missing endif but it was elusive. (wouldn't it be useful if make told you the start line of the unclosed if!)
>>
>> The preceding failed output lines are also suspicious to me.
>>
>> This kind of problem shouldn't be getting in to the master jdk8 repo.
>>
>> Mike
>>
>>
>> On Nov 7 2012, at 08:35 , Mike Duigou wrote:
>>
>>> Building jdk8 currently fails :
>>>
>>> /home/mike/code/jdk8/jdk/build/linux-x86_64-normal-server-fastdebug/jdk/objs/liblcms/cmspack.o: In function `UnrollHalfToFloat':
>>> cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
>>> cmspack.c:(.text+0x27c6): undefined reference to `_cmsHalf2Float'
>>>
>>> presumably caused by:
>>>
>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/cc998992dc32
>>>
>>>


From martijnverburg at gmail.com  Mon Nov 12 01:58:20 2012
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Mon, 12 Nov 2012 09:58:20 +0000
Subject: _the.localejar.jar_include missing
Message-ID: <CAP7YuATwTGVvAj1TcgtUwciU=i7M1=E+xCbfy8zhkRVEtZGzWw@mail.gmail.com>

Hi all,

On the Eurostar so I can't search the archives all to well, so apologies if
this had


From erik.joelsson at oracle.com  Mon Nov 12 02:07:55 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Mon, 12 Nov 2012 10:07:55 +0000
Subject: hg: build-infra/jdk8: 8001965: Fixed compare script exceptions on mac.
Message-ID: <20121112100755.772AE478E8@hg.openjdk.java.net>

Changeset: e511ede50f1e
Author:    erikj
Date:      2012-11-12 02:10 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/e511ede50f1e

8001965: Fixed compare script exceptions on mac.

! common/bin/compare_exceptions.sh.incl



From erik.joelsson at oracle.com  Mon Nov 12 02:08:09 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Mon, 12 Nov 2012 10:08:09 +0000
Subject: hg: build-infra/jdk8/jdk: 8001965: Use closed version of icon on
	macosx in new build.
Message-ID: <20121112100824.0D3BD478E9@hg.openjdk.java.net>

Changeset: dfab270eec70
Author:    erikj
Date:      2012-11-12 02:06 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/dfab270eec70

8001965: Use closed version of icon on macosx in new build.

! makefiles/GensrcIcons.gmk



From martijnverburg at gmail.com  Mon Nov 12 02:43:33 2012
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Mon, 12 Nov 2012 10:43:33 +0000
Subject: _the.localedata.jar_include missing
Message-ID: <CAP7YuAQZqJyKuysRogUQamsFYvNf7jNsx8Wgg_W42Qkjwe0uvQ@mail.gmail.com>

Heh, that was well cut out :-).

So basically the build-infra build fails as the
localedata.jar_include file doesn't get built/copied into the lib/ext.

I'll send through further details when I get better access.

Cheers,
Martijn






On Monday, 12 November 2012, Martijn Verburg wrote:

> Hi all,
>
> On the Eurostar so I can't search the archives all to well, so apologies
> if this had
>


From alan.bateman at oracle.com  Mon Nov 12 04:18:21 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Mon, 12 Nov 2012 12:18:21 +0000
Subject: hg: jdk8/profiles/jdk: Handle JAR files with bad Profile value
	consistently
Message-ID: <20121112121857.25C5C478EB@hg.openjdk.java.net>

Changeset: 4c233f462bda
Author:    alanb
Date:      2012-11-12 12:09 +0000
URL:       http://hg.openjdk.java.net/jdk8/profiles/jdk/rev/4c233f462bda

Handle JAR files with bad Profile value consistently

! src/share/classes/sun/launcher/LauncherHelper.java
! src/share/classes/sun/misc/URLClassPath.java
! test/java/net/URLClassLoader/profiles/Basic.java
- test/java/net/URLClassLoader/profiles/Lib.mf
! test/java/net/URLClassLoader/profiles/basic.sh
! test/tools/launcher/profiles/Basic.java



From martijnverburg at gmail.com  Mon Nov 12 05:32:29 2012
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Mon, 12 Nov 2012 13:32:29 +0000
Subject: _the.localedata.jar_include missing
In-Reply-To: <CAP7YuAQZqJyKuysRogUQamsFYvNf7jNsx8Wgg_W42Qkjwe0uvQ@mail.gmail.com>
References: <CAP7YuAQZqJyKuysRogUQamsFYvNf7jNsx8Wgg_W42Qkjwe0uvQ@mail.gmail.com>
Message-ID: <CAP7YuAT3C_-1kn_8kevON+AK6GsSfySHY1ej7hivzFUzQ+XaFA@mail.gmail.com>

Hi all,

OK, here's some more details:

...

## Starting images
/bin/sh: 1: cannot create
/home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/images/lib/ext//_the.localedata.jar_include:
Directory nonexistent
/bin/grep:
/home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/images/lib/ext//_the.localedata.jar_include:
No such file or directory
Creating images/lib/jconsole.jar
Creating images/lib/ext/dnsns.jar
Creating images/lib/ext/localedata.jar
/bin/grep:
/home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/images/lib/ext//_the.localedata.jar_include:
No such file or directory
'u' flag requires manifest, 'e' flag or input files to be specified!
Usage: jar {ctxui}[vfm0Me] [jar-file] [manifest-file] [entry-point] [-C
dir] files ...
Options:
    -c  create new archive
    -t  list table of contents for archive
    -x  extract named (or all) files from archive
    -u  update existing archive
    -v  generate verbose output on standard output
    -f  specify archive file name
    -m  include manifest information from specified manifest file
    -e  specify application entry point for stand-alone application
        bundled into an executable jar file
    -0  store only; use no ZIP compression
    -M  do not create a manifest file for the entries
    -i  generate index information for the specified jar files
    -C  change to the specified directory and include the following file
If any file is a directory then it is processed recursively.
The manifest file name, the archive file name and the entry point name are
specified in the same order as the 'm', 'f' and 'e' flags.

Example 1: to archive two class files into an archive called classes.jar:
       jar cvf classes.jar Foo.class Bar.class
Example 2: use an existing manifest file 'mymanifest' and archive all the
           files in the foo/ directory into 'classes.jar':
       jar cvfm classes.jar mymanifest -C foo/ .

make[2]: ***
[/home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/images/lib/ext/localedata.jar]
Error 1
make[1]: *** [images] Error 2
make: *** [images-only] Error 2

Cheers,
Martijn

On 12 November 2012 10:43, Martijn Verburg <martijnverburg at gmail.com> wrote:

> Heh, that was well cut out :-).
>
> So basically the build-infra build fails as the
> localedata.jar_include file doesn't get built/copied into the lib/ext.
>
> I'll send through further details when I get better access.
>
> Cheers,
> Martijn
>
>
>
>
>
>
> On Monday, 12 November 2012, Martijn Verburg wrote:
>
>> Hi all,
>>
>> On the Eurostar so I can't search the archives all to well, so apologies
>> if this had
>>
>


From erik.joelsson at oracle.com  Mon Nov 12 05:40:47 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 12 Nov 2012 14:40:47 +0100
Subject: _the.localedata.jar_include missing
In-Reply-To: <CAP7YuAT3C_-1kn_8kevON+AK6GsSfySHY1ej7hivzFUzQ+XaFA@mail.gmail.com>
References: <CAP7YuAQZqJyKuysRogUQamsFYvNf7jNsx8Wgg_W42Qkjwe0uvQ@mail.gmail.com>
	<CAP7YuAT3C_-1kn_8kevON+AK6GsSfySHY1ej7hivzFUzQ+XaFA@mail.gmail.com>
Message-ID: <50A0FC5F.5010000@oracle.com>

This looks like one of the problems Fredrik fixed in jdk8/build after 
the merge with jdk8/jdk8 last week:

http://hg.openjdk.java.net/jdk8/build/rev/8bbc72864a41

/Erik


On 2012-11-12 14:32, Martijn Verburg wrote:
> Hi all,
>
> OK, here's some more details:
>
> ...
>
> ## Starting images
> /bin/sh: 1: cannot create
> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/images/lib/ext//_the.localedata.jar_include:
> Directory nonexistent
> /bin/grep:
> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/images/lib/ext//_the.localedata.jar_include:
> No such file or directory
> Creating images/lib/jconsole.jar
> Creating images/lib/ext/dnsns.jar
> Creating images/lib/ext/localedata.jar
> /bin/grep:
> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/images/lib/ext//_the.localedata.jar_include:
> No such file or directory
> 'u' flag requires manifest, 'e' flag or input files to be specified!
> Usage: jar {ctxui}[vfm0Me] [jar-file] [manifest-file] [entry-point] [-C
> dir] files ...
> Options:
>      -c  create new archive
>      -t  list table of contents for archive
>      -x  extract named (or all) files from archive
>      -u  update existing archive
>      -v  generate verbose output on standard output
>      -f  specify archive file name
>      -m  include manifest information from specified manifest file
>      -e  specify application entry point for stand-alone application
>          bundled into an executable jar file
>      -0  store only; use no ZIP compression
>      -M  do not create a manifest file for the entries
>      -i  generate index information for the specified jar files
>      -C  change to the specified directory and include the following file
> If any file is a directory then it is processed recursively.
> The manifest file name, the archive file name and the entry point name are
> specified in the same order as the 'm', 'f' and 'e' flags.
>
> Example 1: to archive two class files into an archive called classes.jar:
>         jar cvf classes.jar Foo.class Bar.class
> Example 2: use an existing manifest file 'mymanifest' and archive all the
>             files in the foo/ directory into 'classes.jar':
>         jar cvfm classes.jar mymanifest -C foo/ .
>
> make[2]: ***
> [/home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/images/lib/ext/localedata.jar]
> Error 1
> make[1]: *** [images] Error 2
> make: *** [images-only] Error 2
>
> Cheers,
> Martijn
>
> On 12 November 2012 10:43, Martijn Verburg<martijnverburg at gmail.com>  wrote:
>
>> Heh, that was well cut out :-).
>>
>> So basically the build-infra build fails as the
>> localedata.jar_include file doesn't get built/copied into the lib/ext.
>>
>> I'll send through further details when I get better access.
>>
>> Cheers,
>> Martijn
>>
>>
>>
>>
>>
>>
>> On Monday, 12 November 2012, Martijn Verburg wrote:
>>
>>> Hi all,
>>>
>>> On the Eurostar so I can't search the archives all to well, so apologies
>>> if this had
>>>


From erik.joelsson at oracle.com  Mon Nov 12 06:46:45 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Mon, 12 Nov 2012 14:46:45 +0000
Subject: hg: build-infra/jdk8: Cleanup of deploy build from build-infra.
Message-ID: <20121112144646.71590478EC@hg.openjdk.java.net>

Changeset: ef6c8313570a
Author:    erikj
Date:      2012-11-12 14:02 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/ef6c8313570a

Cleanup of deploy build from build-infra.

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/autoconf/toolchain.m4



From erik.joelsson at oracle.com  Mon Nov 12 06:46:45 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Mon, 12 Nov 2012 14:46:45 +0000
Subject: hg: build-infra/jdk8/jdk: Removing unused Makefile from old build
	that should already be gone.
Message-ID: <20121112144724.8E0B0478ED@hg.openjdk.java.net>

Changeset: 6a4a4079f513
Author:    erikj
Date:      2012-11-12 14:53 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/6a4a4079f513

Removing unused Makefile from old build that should already be gone.

- make/sun/jdbc/Makefile



From erik.joelsson at oracle.com  Mon Nov 12 08:07:43 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Mon, 12 Nov 2012 16:07:43 +0000
Subject: hg: build-infra/jdk8: 8001875: build-infra: We must be able to force
	static linking of stdc++
Message-ID: <20121112160743.CECB1478EE@hg.openjdk.java.net>

Changeset: d9d10ee7e7f4
Author:    erikj
Date:      2012-11-12 17:05 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/d9d10ee7e7f4

8001875: build-infra: We must be able to force static linking of stdc++

! common/autoconf/generated-configure.sh
! common/autoconf/libraries.m4



From erik.joelsson at oracle.com  Mon Nov 12 09:17:05 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Mon, 12 Nov 2012 17:17:05 +0000
Subject: hg: build-infra/jdk8: 8001941: Fixed --disable-precompiled-headers.
Message-ID: <20121112171705.787C7478EF@hg.openjdk.java.net>

Changeset: a6bb3c8f7fb3
Author:    erikj
Date:      2012-11-12 18:13 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/a6bb3c8f7fb3

8001941: Fixed --disable-precompiled-headers.

! common/autoconf/build-performance.m4
! common/autoconf/generated-configure.sh
! common/autoconf/hotspot-spec.gmk.in



From martijnverburg at gmail.com  Mon Nov 12 13:29:59 2012
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Mon, 12 Nov 2012 21:29:59 +0000
Subject: _the.localedata.jar_include missing
In-Reply-To: <50A0FC5F.5010000@oracle.com>
References: <CAP7YuAQZqJyKuysRogUQamsFYvNf7jNsx8Wgg_W42Qkjwe0uvQ@mail.gmail.com>
	<CAP7YuAT3C_-1kn_8kevON+AK6GsSfySHY1ej7hivzFUzQ+XaFA@mail.gmail.com>
	<50A0FC5F.5010000@oracle.com>
Message-ID: <CAP7YuASuR2RNuyB8xaL09T0bO+kBqvXF+s5ZmoNnzvufs6ZKvA@mail.gmail.com>

That did the trick - thanks - M

On 12 November 2012 13:40, Erik Joelsson <erik.joelsson at oracle.com> wrote:

> This looks like one of the problems Fredrik fixed in jdk8/build after the
> merge with jdk8/jdk8 last week:
>
> http://hg.openjdk.java.net/**jdk8/build/rev/8bbc72864a41<http://hg.openjdk.java.net/jdk8/build/rev/8bbc72864a41>
>
> /Erik
>
>
>
> On 2012-11-12 14:32, Martijn Verburg wrote:
>
>> Hi all,
>>
>> OK, here's some more details:
>>
>> ...
>>
>> ## Starting images
>> /bin/sh: 1: cannot create
>> /home/openjdk/sources/jdk8_tl/**build/linux-x86_64-normal-**
>> server-release/images/lib/ext/**/_the.localedata.jar_include:
>> Directory nonexistent
>> /bin/grep:
>> /home/openjdk/sources/jdk8_tl/**build/linux-x86_64-normal-**
>> server-release/images/lib/ext/**/_the.localedata.jar_include:
>> No such file or directory
>> Creating images/lib/jconsole.jar
>> Creating images/lib/ext/dnsns.jar
>> Creating images/lib/ext/localedata.jar
>> /bin/grep:
>> /home/openjdk/sources/jdk8_tl/**build/linux-x86_64-normal-**
>> server-release/images/lib/ext/**/_the.localedata.jar_include:
>> No such file or directory
>> 'u' flag requires manifest, 'e' flag or input files to be specified!
>> Usage: jar {ctxui}[vfm0Me] [jar-file] [manifest-file] [entry-point] [-C
>> dir] files ...
>> Options:
>>      -c  create new archive
>>      -t  list table of contents for archive
>>      -x  extract named (or all) files from archive
>>      -u  update existing archive
>>      -v  generate verbose output on standard output
>>      -f  specify archive file name
>>      -m  include manifest information from specified manifest file
>>      -e  specify application entry point for stand-alone application
>>          bundled into an executable jar file
>>      -0  store only; use no ZIP compression
>>      -M  do not create a manifest file for the entries
>>      -i  generate index information for the specified jar files
>>      -C  change to the specified directory and include the following file
>> If any file is a directory then it is processed recursively.
>> The manifest file name, the archive file name and the entry point name are
>> specified in the same order as the 'm', 'f' and 'e' flags.
>>
>> Example 1: to archive two class files into an archive called classes.jar:
>>         jar cvf classes.jar Foo.class Bar.class
>> Example 2: use an existing manifest file 'mymanifest' and archive all the
>>             files in the foo/ directory into 'classes.jar':
>>         jar cvfm classes.jar mymanifest -C foo/ .
>>
>> make[2]: ***
>> [/home/openjdk/sources/jdk8_**tl/build/linux-x86_64-normal-**
>> server-release/images/lib/ext/**localedata.jar]
>> Error 1
>> make[1]: *** [images] Error 2
>> make: *** [images-only] Error 2
>>
>> Cheers,
>> Martijn
>>
>> On 12 November 2012 10:43, Martijn Verburg<martijnverburg at gmail.**com<martijnverburg at gmail.com>>
>>  wrote:
>>
>>  Heh, that was well cut out :-).
>>>
>>> So basically the build-infra build fails as the
>>> localedata.jar_include file doesn't get built/copied into the lib/ext.
>>>
>>> I'll send through further details when I get better access.
>>>
>>> Cheers,
>>> Martijn
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Monday, 12 November 2012, Martijn Verburg wrote:
>>>
>>>  Hi all,
>>>>
>>>> On the Eurostar so I can't search the archives all to well, so apologies
>>>> if this had
>>>>
>>>>


From alex.buckley at oracle.com  Mon Nov 12 13:51:44 2012
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 12 Nov 2012 13:51:44 -0800
Subject: Building with a new javac flag
Message-ID: <50A16F70.5050107@oracle.com>

Dear build experts,

In JDK8, javac will be able to store the names/modifiers of method 
parameters in the class file. The names are stored only if a flag - 
let's say "-parameters" - is passed to javac.

(I know this feels like storing debug info with -g. Please set that 
concern aside.)

What would it take to compile JDK8 _without_ this flag when building 
Java SE Embedded, and _with_ this flag otherwise?

(I know this will raise immediate questions about the size of 
non-Embedded rt.jar. Please set that concern aside.)

David Holmes has suggested that javac flags are or could be expressed as 
a ./configure option, so that Embedded and non-Embedded build scripts 
can turn the -parameters flag on or off.

Alex


From zonski at gmail.com  Mon Nov 12 14:19:45 2012
From: zonski at gmail.com (Daniel Zwolenski)
Date: Tue, 13 Nov 2012 09:19:45 +1100
Subject: Compact JRE Profiles for Desktop?
Message-ID: <CANbPsPyyxYos5K1EMKpg4EhLr31CpRxuryTX+fAB044uDzXvDg@mail.gmail.com>

Hey Guys,

I'm new to this list so apologies if any of this is off topic or been
covered before. If so please let me know.

In the JavaFX space there is a recent trend towards using "native
installers" for deploying Java applications - the world is moving away from
browser plugins, and so Applets and JNLP are fading into obscurity.

In the "native installer" approach we create an installer for each target
platform (e.g. MSI on windows, RPM for Linux, etc - and in the future
bundles for the various app stores out there). The installer includes the
developer's app but it also includes a private copy of the JRE. i.e. each
Java app you install will have it's own internal JRE specific to it,
removing security problems and versioning problems that come with a
central, system-wide, shared JRE.

One of the challenges with this approach is the current size of the JRE.
We're looking at around 70MB+. We'd like to cut this down to the minimal
size to make downloading (and uploading) distribution bundles a lot
smaller, quicker and easier.

I'm interested to know people's thoughts on how we can create a stripped
down JRE for desktop deployment of Java. Project Jigsaw was looking good
but it's now too far off. The work you guys are doing on the "compact
profiles" seems exactly like what we need. However given the "embedded"
focus it looks to be primarily focused on Linux environments.

If I wanted to do something like compact profiles for desktop environments
(windows, mac, linux), would I be better off looking at the compact
profiles you guys are working on, or starting with the normal OpenJDK
project and just look at putting in custom build files that produce
stripped down versions of the normal JRE? Is it possible, easy, hard, etc?

Given that you guys have done a lot of work in this space, I'd be very
interested in any and all tips and ideas on strategies to make this happen.

Also, it's worth mentioning that there is a lot of community
interest/pressure around getting JavaFX (and Java in general) running on
Android and iOS devices. A stripped down JRE looks like a necessary
pre-cursor to making that happen too.

Cheers,
Dan


From sadhak001 at gmail.com  Mon Nov 12 15:56:03 2012
From: sadhak001 at gmail.com (Mani Sarkar)
Date: Mon, 12 Nov 2012 23:56:03 +0000
Subject: Error when running make clean (hotspot) under Ubuntu 12.10
In-Reply-To: <CAGHtMWkVWOxps3AXcWjSjnEuoe2rDLsSoHYfWZ3mQdHPKeWKGA@mail.gmail.com>
References: <CAGHtMW=OQKqUV8sW+QadXrkU8DkvCcpQy_b2uzjtcDYGekWmtQ@mail.gmail.com>
	<50A029B3.9080601@oracle.com>
	<CAGHtMWkVWOxps3AXcWjSjnEuoe2rDLsSoHYfWZ3mQdHPKeWKGA@mail.gmail.com>
Message-ID: <CAGHtMWmBKgFZ4L1C=V6id+uit=RdEb4sTx+JaJwwK4oaah5HTw@mail.gmail.com>

Hi David

I took your suggestion and tried applying the two patches, and they both
generated .rej files and showed a number of conflicts.

Then I looked further down in on the page which had Peter's response, and
applied the changes and got success (see attached file).

I hope my feedback helps you.

Cheers,
Mani

On Sun, Nov 11, 2012 at 11:41 PM, Mani Sarkar <sadhak001 at gmail.com> wrote:

> Thanks David, Ill keep you posted of the outcome of the below!
>
> Cheers,
> Mani
>
>
> On Sun, Nov 11, 2012 at 10:41 PM, David Holmes <david.holmes at oracle.com>wrote:
>
>> This is a hotspot issue. A recent push of the NPG changes broke a
>> previous changeset that allowed compilation under GCC 4.7.2
>>
>> Workaround is to add this-> as directed; or do put in the missing using
>> directives. See:
>>
>> http://mail.openjdk.java.net/**pipermail/hotspot-runtime-dev/**
>> 2012-November/004737.html<http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-November/004737.html>
>>
>> David
>>
>>
>> On 12/11/2012 8:27 AM, Mani Sarkar wrote:
>>
>>> Hi all,
>>>
>>> Can you please help us out with this issue when building the openJDK
>>> using
>>> infra-build under Ubuntu 12.10. I have attached a snippet of the error
>>> message Log files are also available if you need them (>  1.05mb).
>>>
>>> Compiling
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> blockOffsetTable.cpp
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:
>>> In instantiation of ?void AscendTreeCensusClosure<Chunk_**t,
>>> FreeList_t>::do_tree(TreeList<**Chunk_t, FreeList_t>*) [with Chunk_t =
>>> FreeChunk; FreeList_t = AdaptiveFreeList]?:
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1295:**21:
>>>    required from here
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:943:**7:
>>> error: ?do_list? was not declared in this scope, and no declarations were
>>> found by argument-dependent lookup at the point of instantiation
>>> [-fpermissive]
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:943:**7:
>>> note: declarations in dependent base ?TreeCensusClosure<FreeChunk,
>>> AdaptiveFreeList>? are not found by unqualified lookup
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:943:**7:
>>> note: use ?this->do_list? instead
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:
>>> In instantiation of ?TreeList<Chunk_t, FreeList_t>* TreeList<Chunk_t,
>>> FreeList_t>::remove_chunk_**replace_if_needed(TreeChunk<**Chunk_t,
>>> FreeList_t>*) [with Chunk_t = Metablock; FreeList_t = FreeList]?:
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1407:**16:
>>>    required from here
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:242:**7:
>>> error: ?link_tail? was not declared in this scope, and no declarations
>>> were
>>> found by argument-dependent lookup at the point of instantiation
>>> [-fpermissive]
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:242:**7:
>>> note: declarations in dependent base ?FreeList<Metablock>? are not found
>>> by
>>> unqualified lookup
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:242:**7:
>>> note: use ?this->link_tail? instead
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:
>>> In instantiation of ?void TreeList<Chunk_t,
>>> FreeList_t>::return_chunk_at_**head(TreeChunk<Chunk_t, FreeList_t>*)
>>> [with
>>> Chunk_t = Metablock; FreeList_t = FreeList]?:
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1407:**16:
>>>    required from here
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:326:**5:
>>> error: ?link_tail? was not declared in this scope, and no declarations
>>> were
>>> found by argument-dependent lookup at the point of instantiation
>>> [-fpermissive]
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:326:**5:
>>> note: declarations in dependent base ?FreeList<Metablock>? are not found
>>> by
>>> unqualified lookup
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:326:**5:
>>> note: use ?this->link_tail? instead
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:
>>> In instantiation of ?void TreeList<Chunk_t,
>>> FreeList_t>::return_chunk_at_**tail(TreeChunk<Chunk_t, FreeList_t>*)
>>> [with
>>> Chunk_t = Metablock; FreeList_t = FreeList]?:
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1407:**16:
>>>    required from here
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:299:**3:
>>> error: ?link_tail? was not declared in this scope, and no declarations
>>> were
>>> found by argument-dependent lookup at the point of instantiation
>>> [-fpermissive]
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:299:**3:
>>> note: declarations in dependent base ?FreeList<Metablock>? are not found
>>> by
>>> unqualified lookup
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:299:**3:
>>> note: use ?this->link_tail? instead
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:
>>> In instantiation of ?TreeList<Chunk_t, FreeList_t>* TreeList<Chunk_t,
>>> FreeList_t>::remove_chunk_**replace_if_needed(TreeChunk<**Chunk_t,
>>> FreeList_t>*) [with Chunk_t = Metachunk; FreeList_t = FreeList]?:
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1411:**16:
>>>    required from here
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:242:**7:
>>> error: ?link_tail? was not declared in this scope, and no declarations
>>> were
>>> found by argument-dependent lookup at the point of instantiation
>>> [-fpermissive]
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:242:**7:
>>> note: declarations in dependent base ?FreeList<Metachunk>? are not found
>>> by
>>> unqualified lookup
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:242:**7:
>>> note: use ?this->link_tail? instead
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:
>>> In instantiation of ?void TreeList<Chunk_t,
>>> FreeList_t>::return_chunk_at_**head(TreeChunk<Chunk_t, FreeList_t>*)
>>> [with
>>> Chunk_t = Metachunk; FreeList_t = FreeList]?:
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1411:**16:
>>>    required from here
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:326:**5:
>>> error: ?link_tail? was not declared in this scope, and no declarations
>>> were
>>> found by argument-dependent lookup at the point of instantiation
>>> [-fpermissive]
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:326:**5:
>>> note: declarations in dependent base ?FreeList<Metachunk>? are not found
>>> by
>>> unqualified lookup
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:326:**5:
>>> note: use ?this->link_tail? instead
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:
>>> In instantiation of ?void TreeList<Chunk_t,
>>> FreeList_t>::return_chunk_at_**tail(TreeChunk<Chunk_t, FreeList_t>*)
>>> [with
>>> Chunk_t = Metachunk; FreeList_t = FreeList]?:
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1411:**16:
>>>    required from here
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:299:**3:
>>> error: ?link_tail? was not declared in this scope, and no declarations
>>> were
>>> found by argument-dependent lookup at the point of instantiation
>>> [-fpermissive]
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:299:**3:
>>> note: declarations in dependent base ?FreeList<Metachunk>? are not found
>>> by
>>> unqualified lookup
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:299:**3:
>>> note: use ?this->link_tail? instead
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:
>>> In instantiation of ?TreeList<Chunk_t, FreeList_t>* TreeList<Chunk_t,
>>> FreeList_t>::remove_chunk_**replace_if_needed(TreeChunk<**Chunk_t,
>>> FreeList_t>*) [with Chunk_t = FreeChunk; FreeList_t = AdaptiveFreeList]?:
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1418:**16:
>>>    required from here
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:242:**7:
>>> error: ?link_tail? was not declared in this scope, and no declarations
>>> were
>>> found by argument-dependent lookup at the point of instantiation
>>> [-fpermissive]
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:242:**7:
>>> note: declarations in dependent base ?FreeList<FreeChunk>? are not found
>>> by
>>> unqualified lookup
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:242:**7:
>>> note: use ?this->link_tail? instead
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:
>>> In instantiation of ?void TreeList<Chunk_t,
>>> FreeList_t>::return_chunk_at_**head(TreeChunk<Chunk_t, FreeList_t>*)
>>> [with
>>> Chunk_t = FreeChunk; FreeList_t = AdaptiveFreeList]?:
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1418:**16:
>>>    required from here
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:326:**5:
>>> error: ?link_tail? was not declared in this scope, and no declarations
>>> were
>>> found by argument-dependent lookup at the point of instantiation
>>> [-fpermissive]
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:326:**5:
>>> note: declarations in dependent base ?FreeList<FreeChunk>? are not found
>>> by
>>> unqualified lookup
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:326:**5:
>>> note: use ?this->link_tail? instead
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:
>>> In instantiation of ?void TreeList<Chunk_t,
>>> FreeList_t>::return_chunk_at_**tail(TreeChunk<Chunk_t, FreeList_t>*)
>>> [with
>>> Chunk_t = FreeChunk; FreeList_t = AdaptiveFreeList]?:
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1418:**16:
>>>    required from here
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:299:**3:
>>> error: ?link_tail? was not declared in this scope, and no declarations
>>> were
>>> found by argument-dependent lookup at the point of instantiation
>>> [-fpermissive]
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:299:**3:
>>> note: declarations in dependent base ?FreeList<FreeChunk>? are not found
>>> by
>>> unqualified lookup
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:299:**3:
>>> note: use ?this->link_tail? instead
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:
>>> In instantiation of ?bool DescendTreeSearchClosure<**Chunk_t,
>>> FreeList_t>::do_tree(TreeList<**Chunk_t, FreeList_t>*) [with Chunk_t =
>>> Metablock; FreeList_t = FreeList]?:
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1058:**42:
>>>    required from ?Chunk_t* BinaryTreeDictionary<Chunk_t,
>>> FreeList_t>::find_chunk_ends_**at(HeapWord*) const [with Chunk_t =
>>> Metablock;
>>> FreeList_t = FreeList]?
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1408:**16:
>>>    required from here
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1025:**7:
>>> error: ?do_list? was not declared in this scope, and no declarations were
>>> found by argument-dependent lookup at the point of instantiation
>>> [-fpermissive]
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1025:**7:
>>> note: declarations in dependent base ?TreeSearchClosure<Metablock,
>>> FreeList>? are not found by unqualified lookup
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1025:**7:
>>> note: use ?this->do_list? instead
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:
>>> In instantiation of ?void AscendTreeCensusClosure<Chunk_**t,
>>> FreeList_t>::do_tree(TreeList<**Chunk_t, FreeList_t>*) [with Chunk_t =
>>> Metablock; FreeList_t = FreeList]?:
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1070:**3:
>>>    required from ?void BinaryTreeDictionary<Chunk_t,
>>> FreeList_t>::begin_sweep_dict_**census(double, float, float, float)
>>> [with
>>> Chunk_t = Metablock; FreeList_t = FreeList]?
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1408:**16:
>>>    required from here
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:943:**7:
>>> error: ?do_list? was not declared in this scope, and no declarations were
>>> found by argument-dependent lookup at the point of instantiation
>>> [-fpermissive]
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:943:**7:
>>> note: declarations in dependent base ?TreeCensusClosure<Metablock,
>>> FreeList>? are not found by unqualified lookup
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:943:**7:
>>> note: use ?this->do_list? instead
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:
>>> In instantiation of ?void DescendTreeCensusClosure<**Chunk_t,
>>> FreeList_t>::do_tree(TreeList<**Chunk_t, FreeList_t>*) [with Chunk_t =
>>> Metablock; FreeList_t = FreeList]?:
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1174:**3:
>>>    required from ?void BinaryTreeDictionary<Chunk_t,
>>> FreeList_t>::set_tree_hints() [with Chunk_t = Metablock; FreeList_t =
>>> FreeList]?
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1408:**16:
>>>    required from here
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:955:**7:
>>> error: ?do_list? was not declared in this scope, and no declarations were
>>> found by argument-dependent lookup at the point of instantiation
>>> [-fpermissive]
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:955:**7:
>>> note: declarations in dependent base ?TreeCensusClosure<Metablock,
>>> FreeList>? are not found by unqualified lookup
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:955:**7:
>>> note: use ?this->do_list? instead
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:
>>> In instantiation of ?bool DescendTreeSearchClosure<**Chunk_t,
>>> FreeList_t>::do_tree(TreeList<**Chunk_t, FreeList_t>*) [with Chunk_t =
>>> Metachunk; FreeList_t = FreeList]?:
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1058:**42:
>>>    required from ?Chunk_t* BinaryTreeDictionary<Chunk_t,
>>> FreeList_t>::find_chunk_ends_**at(HeapWord*) const [with Chunk_t =
>>> Metachunk;
>>> FreeList_t = FreeList]?
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1412:**16:
>>>    required from here
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1025:**7:
>>> error: ?do_list? was not declared in this scope, and no declarations were
>>> found by argument-dependent lookup at the point of instantiation
>>> [-fpermissive]
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1025:**7:
>>> note: declarations in dependent base ?TreeSearchClosure<Metachunk,
>>> FreeList>? are not found by unqualified lookup
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1025:**7:
>>> note: use ?this->do_list? instead
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:
>>> In instantiation of ?void AscendTreeCensusClosure<Chunk_**t,
>>> FreeList_t>::do_tree(TreeList<**Chunk_t, FreeList_t>*) [with Chunk_t =
>>> Metachunk; FreeList_t = FreeList]?:
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1070:**3:
>>>    required from ?void BinaryTreeDictionary<Chunk_t,
>>> FreeList_t>::begin_sweep_dict_**census(double, float, float, float)
>>> [with
>>> Chunk_t = Metachunk; FreeList_t = FreeList]?
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1412:**16:
>>>    required from here
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:943:**7:
>>> error: ?do_list? was not declared in this scope, and no declarations were
>>> found by argument-dependent lookup at the point of instantiation
>>> [-fpermissive]
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:943:**7:
>>> note: declarations in dependent base ?TreeCensusClosure<Metachunk,
>>> FreeList>? are not found by unqualified lookup
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:943:**7:
>>> note: use ?this->do_list? instead
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:
>>> In instantiation of ?void DescendTreeCensusClosure<**Chunk_t,
>>> FreeList_t>::do_tree(TreeList<**Chunk_t, FreeList_t>*) [with Chunk_t =
>>> Metachunk; FreeList_t = FreeList]?:
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1174:**3:
>>>    required from ?void BinaryTreeDictionary<Chunk_t,
>>> FreeList_t>::set_tree_hints() [with Chunk_t = Metachunk; FreeList_t =
>>> FreeList]?
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1412:**16:
>>>    required from here
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:955:**7:
>>> error: ?do_list? was not declared in this scope, and no declarations were
>>> found by argument-dependent lookup at the point of instantiation
>>> [-fpermissive]
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:955:**7:
>>> note: declarations in dependent base ?TreeCensusClosure<Metachunk,
>>> FreeList>? are not found by unqualified lookup
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:955:**7:
>>> note: use ?this->do_list? instead
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:
>>> In instantiation of ?bool DescendTreeSearchClosure<**Chunk_t,
>>> FreeList_t>::do_tree(TreeList<**Chunk_t, FreeList_t>*) [with Chunk_t =
>>> FreeChunk; FreeList_t = AdaptiveFreeList]?:
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1058:**42:
>>>    required from ?Chunk_t* BinaryTreeDictionary<Chunk_t,
>>> FreeList_t>::find_chunk_ends_**at(HeapWord*) const [with Chunk_t =
>>> FreeChunk;
>>> FreeList_t = AdaptiveFreeList]?
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1419:**16:
>>>    required from here
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1025:**7:
>>> error: ?do_list? was not declared in this scope, and no declarations were
>>> found by argument-dependent lookup at the point of instantiation
>>> [-fpermissive]
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1025:**7:
>>> note: declarations in dependent base ?TreeSearchClosure<FreeChunk,
>>> AdaptiveFreeList>? are not found by unqualified lookup
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1025:**7:
>>> note: use ?this->do_list? instead
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:
>>> In instantiation of ?void DescendTreeCensusClosure<**Chunk_t,
>>> FreeList_t>::do_tree(TreeList<**Chunk_t, FreeList_t>*) [with Chunk_t =
>>> FreeChunk; FreeList_t = AdaptiveFreeList]?:
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1174:**3:
>>>    required from ?void BinaryTreeDictionary<Chunk_t,
>>> FreeList_t>::set_tree_hints() [with Chunk_t = FreeChunk; FreeList_t =
>>> AdaptiveFreeList]?
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:1419:**16:
>>>    required from here
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:955:**7:
>>> error: ?do_list? was not declared in this scope, and no declarations were
>>> found by argument-dependent lookup at the point of instantiation
>>> [-fpermissive]
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:955:**7:
>>> note: declarations in dependent base ?TreeCensusClosure<FreeChunk,
>>> AdaptiveFreeList>? are not found by unqualified lookup
>>> /home/openjdk/sources/jdk8_tl/**hotspot/src/share/vm/memory/**
>>> binaryTreeDictionary.cpp:955:**7:
>>> note: use ?this->do_list? instead
>>> make[6]: *** [binaryTreeDictionary.o] Error 1
>>> make[6]: *** Waiting for unfinished jobs....
>>> make[5]: *** [the_vm] Error 2
>>> make[4]: *** [product] Error 2
>>> make[3]: *** [generic_build2] Error 2
>>> make[2]: *** [product] Error 2
>>> make[1]: ***
>>> [/home/openjdk/sources/jdk8_**tl/build/linux-x86_64-normal-**
>>> server-release/hotspot/_**hotspot.timestamp]
>>> Error 2
>>> make: *** [hotspot-only] Error 2
>>>
>>> Any thoughts?
>>>
>>> Regards,
>>> Mani
>>>
>>>
>
>
> --
> Twitter: @theNeomatrix369
> Blog: http://neomatrix369.wordpress.com<http://neomatrxi369.wordpress.com>
>
> *Don't chase success, rather aim for "Excellence", and success will come
> chasing after you!*
>
>


-- 
Twitter: @theNeomatrix369
Blog: http://neomatrix369.wordpress.com <http://neomatrxi369.wordpress.com>

*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*

From david.holmes at oracle.com  Mon Nov 12 16:13:56 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 13 Nov 2012 10:13:56 +1000
Subject: Building with a new javac flag
In-Reply-To: <50A16F70.5050107@oracle.com>
References: <50A16F70.5050107@oracle.com>
Message-ID: <50A190C4.2070105@oracle.com>

On 13/11/2012 7:51 AM, Alex Buckley wrote:
> Dear build experts,
>
> In JDK8, javac will be able to store the names/modifiers of method
> parameters in the class file. The names are stored only if a flag -
> let's say "-parameters" - is passed to javac.
>
> (I know this feels like storing debug info with -g. Please set that
> concern aside.)
>
> What would it take to compile JDK8 _without_ this flag when building
> Java SE Embedded, and _with_ this flag otherwise?
>
> (I know this will raise immediate questions about the size of
> non-Embedded rt.jar. Please set that concern aside.)
>
> David Holmes has suggested that javac flags are or could be expressed as
> a ./configure option, so that Embedded and non-Embedded build scripts
> can turn the -parameters flag on or off.

But I also questioned whether it should be a configure option as you 
can't make every possible tool flag be a configure option.

The basic requirement is that the -parameters setting must be 
customizable, so we need to decide the best way to achieve that.

David

> Alex


From david.holmes at oracle.com  Mon Nov 12 16:42:20 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 13 Nov 2012 10:42:20 +1000
Subject: Compact JRE Profiles for Desktop?
In-Reply-To: <CANbPsPyyxYos5K1EMKpg4EhLr31CpRxuryTX+fAB044uDzXvDg@mail.gmail.com>
References: <CANbPsPyyxYos5K1EMKpg4EhLr31CpRxuryTX+fAB044uDzXvDg@mail.gmail.com>
Message-ID: <50A1976C.7050308@oracle.com>

Hi Daniel,

It isn't really on-topic for this list but I'll try to answer in part 
anyway.

The Compact Profiles work is part of SE 8 and will be defined for any 
platform. However that doesn't mean that the OpenJDK sources will 
necessarily be set up to build profiles for all platforms. At present 
the Profiles work (in the jdk8/profiles forest) is Linux-only.

IANAL but a key part of the Profiles work is updating the SE 
specification to define Compact Profiles as allowable subsets of the 
platform. If you customize things yourself there may be limits on how 
you can share that with others.

I must say that a JRE per app makes me cringe. Didn't we try that kind 
of deployment model (not for Java of course :) ) back in the 80's  (DLL 
Hell) ?

David Holmes

On 13/11/2012 8:19 AM, Daniel Zwolenski wrote:
> Hey Guys,
>
> I'm new to this list so apologies if any of this is off topic or been
> covered before. If so please let me know.
>
> In the JavaFX space there is a recent trend towards using "native
> installers" for deploying Java applications - the world is moving away from
> browser plugins, and so Applets and JNLP are fading into obscurity.
>
> In the "native installer" approach we create an installer for each target
> platform (e.g. MSI on windows, RPM for Linux, etc - and in the future
> bundles for the various app stores out there). The installer includes the
> developer's app but it also includes a private copy of the JRE. i.e. each
> Java app you install will have it's own internal JRE specific to it,
> removing security problems and versioning problems that come with a
> central, system-wide, shared JRE.
>
> One of the challenges with this approach is the current size of the JRE.
> We're looking at around 70MB+. We'd like to cut this down to the minimal
> size to make downloading (and uploading) distribution bundles a lot
> smaller, quicker and easier.
>
> I'm interested to know people's thoughts on how we can create a stripped
> down JRE for desktop deployment of Java. Project Jigsaw was looking good
> but it's now too far off. The work you guys are doing on the "compact
> profiles" seems exactly like what we need. However given the "embedded"
> focus it looks to be primarily focused on Linux environments.
>
> If I wanted to do something like compact profiles for desktop environments
> (windows, mac, linux), would I be better off looking at the compact
> profiles you guys are working on, or starting with the normal OpenJDK
> project and just look at putting in custom build files that produce
> stripped down versions of the normal JRE? Is it possible, easy, hard, etc?
>
> Given that you guys have done a lot of work in this space, I'd be very
> interested in any and all tips and ideas on strategies to make this happen.
>
> Also, it's worth mentioning that there is a lot of community
> interest/pressure around getting JavaFX (and Java in general) running on
> Android and iOS devices. A stripped down JRE looks like a necessary
> pre-cursor to making that happen too.
>
> Cheers,
> Dan


From zonski at gmail.com  Mon Nov 12 18:00:29 2012
From: zonski at gmail.com (Daniel Zwolenski)
Date: Tue, 13 Nov 2012 13:00:29 +1100
Subject: Compact JRE Profiles for Desktop?
In-Reply-To: <50A1976C.7050308@oracle.com>
References: <CANbPsPyyxYos5K1EMKpg4EhLr31CpRxuryTX+fAB044uDzXvDg@mail.gmail.com>
	<50A1976C.7050308@oracle.com>
Message-ID: <CANbPsPxycTyfcOtTWTMsjmyHX9zGrGn0vK2gkEKWbueRzuithw@mail.gmail.com>

Thanks for the response David

On Tue, Nov 13, 2012 at 11:42 AM, David Holmes <david.holmes at oracle.com>wrote:

> It isn't really on-topic for this list but I'll try to answer in part
> anyway.
>

Is there anywhere good to ask these questions (other than the JFX forum
where knowledge about this stuff is limited)?


> The Compact Profiles work is part of SE 8 and will be defined for any
> platform. However that doesn't mean that the OpenJDK sources will
> necessarily be set up to build profiles for all platforms. At present the
> Profiles work (in the jdk8/profiles forest) is Linux-only.
>

Do you know who, what, where decides whether the profiles will be available
for platforms other than linux? Is there anyone I can hit up to make this
happen and/or offer whatever contribution I could make to this?


> IANAL but a key part of the Profiles work is updating the SE specification
> to define Compact Profiles as allowable subsets of the platform. If you
> customize things yourself there may be limits on how you can share that
> with others.
>

Yea, the legals is an issue. Ideally this will be official Oracle work
making it back into the main JRE. "App Stores" in particular stop us from
using the OpenJDK as an embedded JRE due to the GPL licencing conflicts
(even without me making any modifications).

Since you guys are doing most of the work for Linux anyway from an
outsiders perspective it looks like the only reason it's not happening on
non-Linux platforms is motivation+resources? If this process could be
opened up to allow JFX developers (who have motivation) to do this work
(i.e provide resources) then it would be great if Oracle could support this
to happen.

But this is why I'm asking questions around it before doing anything.
Mostly working out where/who/how this work should be done if it is to be
done at all, and which team at Oracle (if any) is willing to help shepherd
this work through.

I must say that a JRE per app makes me cringe. Didn't we try that kind of
> deployment model (not for Java of course :) ) back in the 80's  (DLL Hell) ?


There's basically little choice for client side Java in the future Mac and
Windows app stores are moving more towards locking down what can be
installed. We're seeing a trend where system-wide JRE installs are being
heavily biased against and potentially openly blocked (much like Flash was
blocked on iOS). The Bring Your Own Runtime (BYOR) approach is looking like
the best option in this brave new world.

Browser's (and users) are definitely locking down on browser plugins too.
So many security issues and problems and recently Java has had a bad run on
this making people even more wary to install the plugin (which is needed
for webstart and Applets to work). This is one step away from being a dead
technology.

On the other hand, co-bundling a private JRE really isn't that horrible a
situation. It doesn't need to be "installed" and is just unzipped into the
apps folder along with the JARS and other resources. It is basically just
like a third party library that your app is using - no DLL hell as none of
the native DLLs etx are "installed" to the system path.

The co-bundled JRE is very much the same idea as your embedded JRE. It's
the same model as Flash uses to run on iOS and if/when JavaFX makes it onto
Smart Devices the embedded JRE will be a requirement there as there is no
alternative.

All roads currently lead to embedded JREs in apps.

p.s. on the smart phones topic, I do find it rather odd that Oracle has an
"embedded" team and a "desktop" team but has left the massively popular
in-between bit of "smartdevice" in no man's land.





> On 13/11/2012 8:19 AM, Daniel Zwolenski wrote:
>
>> Hey Guys,
>>
>> I'm new to this list so apologies if any of this is off topic or been
>> covered before. If so please let me know.
>>
>> In the JavaFX space there is a recent trend towards using "native
>> installers" for deploying Java applications - the world is moving away
>> from
>> browser plugins, and so Applets and JNLP are fading into obscurity.
>>
>> In the "native installer" approach we create an installer for each target
>> platform (e.g. MSI on windows, RPM for Linux, etc - and in the future
>> bundles for the various app stores out there). The installer includes the
>> developer's app but it also includes a private copy of the JRE. i.e. each
>> Java app you install will have it's own internal JRE specific to it,
>> removing security problems and versioning problems that come with a
>> central, system-wide, shared JRE.
>>
>> One of the challenges with this approach is the current size of the JRE.
>> We're looking at around 70MB+. We'd like to cut this down to the minimal
>> size to make downloading (and uploading) distribution bundles a lot
>> smaller, quicker and easier.
>>
>> I'm interested to know people's thoughts on how we can create a stripped
>> down JRE for desktop deployment of Java. Project Jigsaw was looking good
>> but it's now too far off. The work you guys are doing on the "compact
>> profiles" seems exactly like what we need. However given the "embedded"
>> focus it looks to be primarily focused on Linux environments.
>>
>> If I wanted to do something like compact profiles for desktop environments
>> (windows, mac, linux), would I be better off looking at the compact
>> profiles you guys are working on, or starting with the normal OpenJDK
>> project and just look at putting in custom build files that produce
>> stripped down versions of the normal JRE? Is it possible, easy, hard, etc?
>>
>> Given that you guys have done a lot of work in this space, I'd be very
>> interested in any and all tips and ideas on strategies to make this
>> happen.
>>
>> Also, it's worth mentioning that there is a lot of community
>> interest/pressure around getting JavaFX (and Java in general) running on
>> Android and iOS devices. A stripped down JRE looks like a necessary
>> pre-cursor to making that happen too.
>>
>> Cheers,
>> Dan
>>
>


From erik.joelsson at oracle.com  Tue Nov 13 00:12:36 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 13 Nov 2012 09:12:36 +0100
Subject: Building with a new javac flag
In-Reply-To: <50A190C4.2070105@oracle.com>
References: <50A16F70.5050107@oracle.com> <50A190C4.2070105@oracle.com>
Message-ID: <50A200F4.10001@oracle.com>

In this case I would go with configure. This is because the value of the 
option has different defaults depending on jdk variant/profile. If it 
was a less often used parameter, something more general like 
"--with-add-javacflags=" could be used, but that only fits options that 
are always default off.

On a sidenote, it's still possible to override configure options with 
variables in the environment or on the command line if you know the name 
of the make variable being set. I just wouldn't normally recommend it.

/Erik

On 2012-11-13 01:13, David Holmes wrote:
> On 13/11/2012 7:51 AM, Alex Buckley wrote:
>> Dear build experts,
>>
>> In JDK8, javac will be able to store the names/modifiers of method
>> parameters in the class file. The names are stored only if a flag -
>> let's say "-parameters" - is passed to javac.
>>
>> (I know this feels like storing debug info with -g. Please set that
>> concern aside.)
>>
>> What would it take to compile JDK8 _without_ this flag when building
>> Java SE Embedded, and _with_ this flag otherwise?
>>
>> (I know this will raise immediate questions about the size of
>> non-Embedded rt.jar. Please set that concern aside.)
>>
>> David Holmes has suggested that javac flags are or could be expressed as
>> a ./configure option, so that Embedded and non-Embedded build scripts
>> can turn the -parameters flag on or off.
>
> But I also questioned whether it should be a configure option as you 
> can't make every possible tool flag be a configure option.
>
> The basic requirement is that the -parameters setting must be 
> customizable, so we need to decide the best way to achieve that.
>
> David
>
>> Alex


From erik.joelsson at oracle.com  Tue Nov 13 01:04:00 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 13 Nov 2012 09:04:00 +0000
Subject: hg: build-infra/jdk8: 8003317: build-infra: Configure fails when
	current dir is part of a symlink
Message-ID: <20121113090401.300944791E@hg.openjdk.java.net>

Changeset: e260056ac664
Author:    erikj
Date:      2012-11-13 10:02 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/e260056ac664

8003317: build-infra: Configure fails when current dir is part of a symlink

! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh



From Alan.Bateman at oracle.com  Tue Nov 13 02:01:34 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 13 Nov 2012 10:01:34 +0000
Subject: Compact JRE Profiles for Desktop?
In-Reply-To: <CANbPsPxycTyfcOtTWTMsjmyHX9zGrGn0vK2gkEKWbueRzuithw@mail.gmail.com>
References: <CANbPsPyyxYos5K1EMKpg4EhLr31CpRxuryTX+fAB044uDzXvDg@mail.gmail.com>
	<50A1976C.7050308@oracle.com>
	<CANbPsPxycTyfcOtTWTMsjmyHX9zGrGn0vK2gkEKWbueRzuithw@mail.gmail.com>
Message-ID: <50A21A7E.6030307@oracle.com>

On 13/11/2012 02:00, Daniel Zwolenski wrote:
> :
> Is there anywhere good to ask these questions (other than the JFX forum
> where knowledge about this stuff is limited)?
There isn't a separate mailing list for the Compact Profiles effort. The 
changes are expected to be mostly build related so this is why the 
jdk8/profiles forest was setup to send the hg notifications here.

> :
>
>
> Do you know who, what, where decides whether the profiles will be available
> for platforms other than linux? Is there anyone I can hit up to make this
> happen and/or offer whatever contribution I could make to this?
There's nothing platform specific in the proposal, it's just that we are 
only adding support to build the profiles on Linux at this time.

I don't think it would take a huge amount of effort to add support for 
other building on other platforms and perhaps this is something that you 
or others would like to contribute?

-Alan.


From zonski at gmail.com  Tue Nov 13 02:34:57 2012
From: zonski at gmail.com (Daniel Zwolenski)
Date: Tue, 13 Nov 2012 21:34:57 +1100
Subject: Compact JRE Profiles for Desktop?
In-Reply-To: <50A21A7E.6030307@oracle.com>
References: <CANbPsPyyxYos5K1EMKpg4EhLr31CpRxuryTX+fAB044uDzXvDg@mail.gmail.com>
	<50A1976C.7050308@oracle.com>
	<CANbPsPxycTyfcOtTWTMsjmyHX9zGrGn0vK2gkEKWbueRzuithw@mail.gmail.com>
	<50A21A7E.6030307@oracle.com>
Message-ID: <3F1F82C0-17F5-47EB-9B8B-D32FEDAFEAA0@gmail.com>

Hi Alan,

Thanks for your response. Contributing to the efforts for support on other platforms is something I am willing to have a crack at.

I have signed the oracle contributors agreement and all that jazz, and I'm totally confident with all things java. The native, low level stuff might be a bit of a learning curve so I guess I'll just take a stab at it and see what happens. Any tips on how best to get started?

Cheers,
Dan



On 13/11/2012, at 9:01 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 13/11/2012 02:00, Daniel Zwolenski wrote:
>> :
>> Is there anywhere good to ask these questions (other than the JFX forum
>> where knowledge about this stuff is limited)?
> There isn't a separate mailing list for the Compact Profiles effort. The changes are expected to be mostly build related so this is why the jdk8/profiles forest was setup to send the hg notifications here.
> 
>> :
>> 
>> 
>> Do you know who, what, where decides whether the profiles will be available
>> for platforms other than linux? Is there anyone I can hit up to make this
>> happen and/or offer whatever contribution I could make to this?
> There's nothing platform specific in the proposal, it's just that we are only adding support to build the profiles on Linux at this time.
> 
> I don't think it would take a huge amount of effort to add support for other building on other platforms and perhaps this is something that you or others would like to contribute?
> 
> -Alan.


From erik.joelsson at oracle.com  Tue Nov 13 02:38:39 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 13 Nov 2012 10:38:39 +0000
Subject: hg: build-infra/jdk8/jdk: 8001906: build-infra: warning: [path] bad
	path element on Solaris
Message-ID: <20121113103921.D156A47921@hg.openjdk.java.net>

Changeset: 6a61387c2557
Author:    erikj
Date:      2012-11-13 11:38 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/6a61387c2557

8001906: build-infra: warning: [path] bad path element on Solaris

! makefiles/CompileDemos.gmk



From Alan.Bateman at oracle.com  Tue Nov 13 02:44:27 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 13 Nov 2012 10:44:27 +0000
Subject: Compact JRE Profiles for Desktop?
In-Reply-To: <3F1F82C0-17F5-47EB-9B8B-D32FEDAFEAA0@gmail.com>
References: <CANbPsPyyxYos5K1EMKpg4EhLr31CpRxuryTX+fAB044uDzXvDg@mail.gmail.com>
	<50A1976C.7050308@oracle.com>
	<CANbPsPxycTyfcOtTWTMsjmyHX9zGrGn0vK2gkEKWbueRzuithw@mail.gmail.com>
	<50A21A7E.6030307@oracle.com>
	<3F1F82C0-17F5-47EB-9B8B-D32FEDAFEAA0@gmail.com>
Message-ID: <50A2248B.5030104@oracle.com>

On 13/11/2012 10:34, Daniel Zwolenski wrote:
> Hi Alan,
>
> Thanks for your response. Contributing to the efforts for support on other platforms is something I am willing to have a crack at.
>
> I have signed the oracle contributors agreement and all that jazz, and I'm totally confident with all things java. The native, low level stuff might be a bit of a learning curve so I guess I'll just take a stab at it and see what happens. Any tips on how best to get started?
>
I suggest taking a clone of jdk8/profiles and build it on Linux so that 
you get a feel for the build and the new "profiles" build target.

The forest is currently at jdk8-b60 so another thing you could do is "hg 
diff -g -r jdk8-b60" to get a feel for the changes in each of the 
repositories, in particular the platforms that are platform specific. A 
bit sync up will be required soon and that may require a lot of changes 
to the build so keep that in mind.

-Alan


From david.holmes at oracle.com  Tue Nov 13 03:41:49 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 13 Nov 2012 21:41:49 +1000
Subject: Building with a new javac flag
In-Reply-To: <50A200F4.10001@oracle.com>
References: <50A16F70.5050107@oracle.com> <50A190C4.2070105@oracle.com>
	<50A200F4.10001@oracle.com>
Message-ID: <50A231FD.4050501@oracle.com>

On 13/11/2012 6:12 PM, Erik Joelsson wrote:
> In this case I would go with configure. This is because the value of the
> option has different defaults depending on jdk variant/profile. If it
> was a less often used parameter, something more general like
> "--with-add-javacflags=" could be used, but that only fits options that
> are always default off.

Bear in mind that we don't want to have to set this on the configure 
invocation but rather be able to change the default through the custom 
build files. This could either be done at configure time, or in the 
custom makefiles by setting an appropriate make variable. So there is 
some flexibility.

I haven't had a chance to look at where this needs to be set and am 
travelling over the next few days.

David
-----

> On a sidenote, it's still possible to override configure options with
> variables in the environment or on the command line if you know the name
> of the make variable being set. I just wouldn't normally recommend it.
>
> /Erik
>
> On 2012-11-13 01:13, David Holmes wrote:
>> On 13/11/2012 7:51 AM, Alex Buckley wrote:
>>> Dear build experts,
>>>
>>> In JDK8, javac will be able to store the names/modifiers of method
>>> parameters in the class file. The names are stored only if a flag -
>>> let's say "-parameters" - is passed to javac.
>>>
>>> (I know this feels like storing debug info with -g. Please set that
>>> concern aside.)
>>>
>>> What would it take to compile JDK8 _without_ this flag when building
>>> Java SE Embedded, and _with_ this flag otherwise?
>>>
>>> (I know this will raise immediate questions about the size of
>>> non-Embedded rt.jar. Please set that concern aside.)
>>>
>>> David Holmes has suggested that javac flags are or could be expressed as
>>> a ./configure option, so that Embedded and non-Embedded build scripts
>>> can turn the -parameters flag on or off.
>>
>> But I also questioned whether it should be a configure option as you
>> can't make every possible tool flag be a configure option.
>>
>> The basic requirement is that the -parameters setting must be
>> customizable, so we need to decide the best way to achieve that.
>>
>> David
>>
>>> Alex


From david.holmes at oracle.com  Tue Nov 13 03:47:32 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 13 Nov 2012 21:47:32 +1000
Subject: Compact JRE Profiles for Desktop?
In-Reply-To: <3F1F82C0-17F5-47EB-9B8B-D32FEDAFEAA0@gmail.com>
References: <CANbPsPyyxYos5K1EMKpg4EhLr31CpRxuryTX+fAB044uDzXvDg@mail.gmail.com>
	<50A1976C.7050308@oracle.com>
	<CANbPsPxycTyfcOtTWTMsjmyHX9zGrGn0vK2gkEKWbueRzuithw@mail.gmail.com>
	<50A21A7E.6030307@oracle.com>
	<3F1F82C0-17F5-47EB-9B8B-D32FEDAFEAA0@gmail.com>
Message-ID: <50A23354.9020300@oracle.com>

Quick note: the main thing Linux specific is the set of files that 
defines the profile contents - profile-includes.txt (IIRC). It used a 
Linux JRE as the starting point. Once I start looking at how different 
platforms have different files I may need a better higher-level way to 
express platform dependencies (some of it is hidden with things like 
LIB_SUFFIX etc).

Profiles are very simple:
- a reduced set of files in lib and bin
- a reduced set of APIs in rt.jar (and by association resources.jar)

David

On 13/11/2012 8:34 PM, Daniel Zwolenski wrote:
> Hi Alan,
>
> Thanks for your response. Contributing to the efforts for support on other platforms is something I am willing to have a crack at.
>
> I have signed the oracle contributors agreement and all that jazz, and I'm totally confident with all things java. The native, low level stuff might be a bit of a learning curve so I guess I'll just take a stab at it and see what happens. Any tips on how best to get started?
>
> Cheers,
> Dan
>
>
>
> On 13/11/2012, at 9:01 PM, Alan Bateman<Alan.Bateman at oracle.com>  wrote:
>
>> On 13/11/2012 02:00, Daniel Zwolenski wrote:
>>> :
>>> Is there anywhere good to ask these questions (other than the JFX forum
>>> where knowledge about this stuff is limited)?
>> There isn't a separate mailing list for the Compact Profiles effort. The changes are expected to be mostly build related so this is why the jdk8/profiles forest was setup to send the hg notifications here.
>>
>>> :
>>>
>>>
>>> Do you know who, what, where decides whether the profiles will be available
>>> for platforms other than linux? Is there anyone I can hit up to make this
>>> happen and/or offer whatever contribution I could make to this?
>> There's nothing platform specific in the proposal, it's just that we are only adding support to build the profiles on Linux at this time.
>>
>> I don't think it would take a huge amount of effort to add support for other building on other platforms and perhaps this is something that you or others would like to contribute?
>>
>> -Alan.


From Alan.Bateman at oracle.com  Tue Nov 13 04:00:45 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 13 Nov 2012 12:00:45 +0000
Subject: Building with a new javac flag
In-Reply-To: <50A190C4.2070105@oracle.com>
References: <50A16F70.5050107@oracle.com> <50A190C4.2070105@oracle.com>
Message-ID: <50A2366D.9000508@oracle.com>

On 13/11/2012 00:13, David Holmes wrote:
>
> But I also questioned whether it should be a configure option as you 
> can't make every possible tool flag be a configure option.
>
> The basic requirement is that the -parameters setting must be 
> customizable, so we need to decide the best way to achieve that.
This one may be significant enough to me to justify a configure option. 
On the other hand, "make images profiles" would mean all the resulting 
images (JDK, JRE, and Compact Profiles) would either all have/not the 
parameter names.

Alex's original mail brought up the embedded case but I could imagine 
having the same discussion on JDK vs JRE images. I'm not saying this is 
the right thing to do, esp. as it would mean usages of core reflection 
would behave differently, just bringing it up as a slightly different 
case to consider.

-Alan.


From erik.joelsson at oracle.com  Tue Nov 13 05:22:45 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 13 Nov 2012 13:22:45 +0000
Subject: hg: build-infra/jdk8: 8003327: build-infra: "/bin/sh: : cannot
	execute" on solaris
Message-ID: <20121113132245.C597647926@hg.openjdk.java.net>

Changeset: 092de7fab6a6
Author:    erikj
Date:      2012-11-13 14:22 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/092de7fab6a6

8003327: build-infra: "/bin/sh: : cannot execute" on solaris

! common/makefiles/MakeHelpers.gmk



From erik.joelsson at oracle.com  Tue Nov 13 06:58:28 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 13 Nov 2012 14:58:28 +0000
Subject: hg: build-infra/jdk8/jdk: 8001460: build-infra: Linker warnings on
	macosx
Message-ID: <20121113145850.95B3D47928@hg.openjdk.java.net>

Changeset: 1b42c7de72bf
Author:    erikj
Date:      2012-11-13 06:58 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/1b42c7de72bf

8001460: build-infra: Linker warnings on macosx

! makefiles/CompileNativeLibraries.gmk



From erik.joelsson at oracle.com  Tue Nov 13 06:59:06 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 13 Nov 2012 14:59:06 +0000
Subject: hg: build-infra/jdk8: 8001460: build-infra: Linker warnings on macosx
Message-ID: <20121113145906.B45CF47929@hg.openjdk.java.net>

Changeset: 539ffd9623ed
Author:    erikj
Date:      2012-11-13 06:58 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/539ffd9623ed

8001460: build-infra: Linker warnings on macosx

! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4



From alex.buckley at oracle.com  Tue Nov 13 12:50:24 2012
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 13 Nov 2012 12:50:24 -0800
Subject: Building with a new javac flag
In-Reply-To: <50A2366D.9000508@oracle.com>
References: <50A16F70.5050107@oracle.com> <50A190C4.2070105@oracle.com>
	<50A2366D.9000508@oracle.com>
Message-ID: <50A2B290.7040504@oracle.com>

On 11/13/2012 4:00 AM, Alan Bateman wrote:
> This one may be significant enough to me to justify a configure option.
> On the other hand, "make images profiles" would mean all the resulting
> images (JDK, JRE, and Compact Profiles) would either all have/not the
> parameter names.

The primary reason for storing parameter names in JDK8 class files is to 
help IDE vendors, so it's fine if only the JDK image has them. We are 
not making a general promise that any program will be able to find 
parameter names of core Java Java SE classes at runtime. (Again, please 
set aside concerns about footprint, compatibility, etc on this list.)

It sounds like a ./configure option of --enable-parameters could add an 
option to JAVAC_FLAGS - you say it would affect all images? But Erik 
said "the value of the option has different defaults depending on jdk 
variant/profile".

Where should we look at the new build, given that the parameter feature 
lives in the jdk8/tl forest?

Alex


From Alan.Bateman at oracle.com  Tue Nov 13 13:45:21 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 13 Nov 2012 21:45:21 +0000
Subject: Building with a new javac flag
In-Reply-To: <50A2B290.7040504@oracle.com>
References: <50A16F70.5050107@oracle.com> <50A190C4.2070105@oracle.com>
	<50A2366D.9000508@oracle.com> <50A2B290.7040504@oracle.com>
Message-ID: <50A2BF71.80504@oracle.com>

On 13/11/2012 20:50, Alex Buckley wrote:
>
> The primary reason for storing parameter names in JDK8 class files is 
> to help IDE vendors, so it's fine if only the JDK image has them. We 
> are not making a general promise that any program will be able to find 
> parameter names of core Java Java SE classes at runtime. (Again, 
> please set aside concerns about footprint, compatibility, etc on this 
> list.)
>
> It sounds like a ./configure option of --enable-parameters could add 
> an option to JAVAC_FLAGS - you say it would affect all images? But 
> Erik said "the value of the option has different defaults depending on 
> jdk variant/profile".
Suppose we do "configure --enable-paramater-names && make" then this 
would compile the classes and native libraries but at this point we 
don't have any images, rather it's just raw classes on the file system 
(no rt.jar).

A subsequent "make images" would create the j2sdk-image and j2re-image 
with the rt.jar and the layout that we are used to. I think, and Erik or 
David can correct me, is that the same class files end up in both 
images. Subsequent stripping of debug attributes from everything in 
rt.jar may happen later, at least where JRE download size is important.

So my point about the parameter names is that the same classes are used 
for all images. The "profiles" build is like "images", it's really just 
packaging up the already compiled bits and so would get the same class 
files, assuming of course that the JDK/JRE images and profiles images 
are coming from the same build.

When Erik used the term "variant" then I assume he meant the 
--with-jdk-variant and --with-jvm-variant options to configure normal or 
embedded, client or server VM and things like that. That's part of the 
configuration. If we are compiling classes differently then I suspect it 
may require a separate configuration.

>
> Where should we look at the new build, given that the parameter 
> feature lives in the jdk8/tl forest?
common/makefiles in the top-level repo, and makefiles directory in each 
of the other repos. Alternatively this guide:

http://openjdk.java.net/projects/build-infra/guide.html

-Alan.


From kelly.ohair at oracle.com  Tue Nov 13 15:11:02 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 13 Nov 2012 15:11:02 -0800
Subject: Building with a new javac flag
In-Reply-To: <50A2B290.7040504@oracle.com>
References: <50A16F70.5050107@oracle.com> <50A190C4.2070105@oracle.com>
	<50A2366D.9000508@oracle.com> <50A2B290.7040504@oracle.com>
Message-ID: <68D3C445-527B-4204-AD1F-0E68CD031840@oracle.com>

From an IDE perspective, does it make sense to have parameter names, but not line numbers?
Seems like if we just generate the parameter names all the time, and have pack200 strip them out
for the JRE, then we could just generate them all the time.
Then there is no need for an option, just a change to pack200 to remove a few attributes when it is told to
delete debug information in the jre runtime jars?

-kto

On Nov 13, 2012, at 12:50 PM, Alex Buckley wrote:

> On 11/13/2012 4:00 AM, Alan Bateman wrote:
>> This one may be significant enough to me to justify a configure option.
>> On the other hand, "make images profiles" would mean all the resulting
>> images (JDK, JRE, and Compact Profiles) would either all have/not the
>> parameter names.
> 
> The primary reason for storing parameter names in JDK8 class files is to help IDE vendors, so it's fine if only the JDK image has them. We are not making a general promise that any program will be able to find parameter names of core Java Java SE classes at runtime. (Again, please set aside concerns about footprint, compatibility, etc on this list.)
> 
> It sounds like a ./configure option of --enable-parameters could add an option to JAVAC_FLAGS - you say it would affect all images? But Erik said "the value of the option has different defaults depending on jdk variant/profile".
> 
> Where should we look at the new build, given that the parameter feature lives in the jdk8/tl forest?
> 
> Alex



From alex.buckley at oracle.com  Tue Nov 13 15:16:57 2012
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 13 Nov 2012 15:16:57 -0800
Subject: Building with a new javac flag
In-Reply-To: <68D3C445-527B-4204-AD1F-0E68CD031840@oracle.com>
References: <50A16F70.5050107@oracle.com> <50A190C4.2070105@oracle.com>
	<50A2366D.9000508@oracle.com> <50A2B290.7040504@oracle.com>
	<68D3C445-527B-4204-AD1F-0E68CD031840@oracle.com>
Message-ID: <50A2D4E9.10500@oracle.com>

An IDE is not trying to debug code in rt.jar; it's trying to build a 
directory of classes and methods therein for type-ahead and refactoring. 
Quoting Brian:

"For the JDK, exposing this information means that IDEs can harvest 
parameter information without parsing sources, which is used for 
"implement methods" code wizards.  (Compare what happens in IntelliJ 
when you implement a method from a JDK interface to what happens in 
Eclipse.  In IJ, you get the names from the source; in Eclipse, you get 
"foo(String s1, String s2, int i1)".)"

We don't want javac to generate parameter names all the time for reasons 
outlined in the spec PDF posted to the enhanced-metadata-spec-discuss 
list. Again, I am trying to keep policy decisions about the feature off 
build-infra-dev.

Alex

On 11/13/2012 3:11 PM, Kelly O'Hair wrote:
> From an IDE perspective, does it make sense to have parameter names,
> but not line numbers? Seems like if we just generate the parameter
> names all the time, and have pack200 strip them out for the JRE, then
> we could just generate them all the time. Then there is no need for
> an option, just a change to pack200 to remove a few attributes when
> it is told to delete debug information in the jre runtime jars?
>
> -kto
>
> On Nov 13, 2012, at 12:50 PM, Alex Buckley wrote:
>
>> On 11/13/2012 4:00 AM, Alan Bateman wrote:
>>> This one may be significant enough to me to justify a configure
>>> option. On the other hand, "make images profiles" would mean all
>>> the resulting images (JDK, JRE, and Compact Profiles) would
>>> either all have/not the parameter names.
>>
>> The primary reason for storing parameter names in JDK8 class files
>> is to help IDE vendors, so it's fine if only the JDK image has
>> them. We are not making a general promise that any program will be
>> able to find parameter names of core Java Java SE classes at
>> runtime. (Again, please set aside concerns about footprint,
>> compatibility, etc on this list.)
>>
>> It sounds like a ./configure option of --enable-parameters could
>> add an option to JAVAC_FLAGS - you say it would affect all images?
>> But Erik said "the value of the option has different defaults
>> depending on jdk variant/profile".
>>
>> Where should we look at the new build, given that the parameter
>> feature lives in the jdk8/tl forest?
>>
>> Alex
>


From david.holmes at oracle.com  Tue Nov 13 22:13:49 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 14 Nov 2012 16:13:49 +1000
Subject: Building with a new javac flag
In-Reply-To: <50A2BF71.80504@oracle.com>
References: <50A16F70.5050107@oracle.com> <50A190C4.2070105@oracle.com>
	<50A2366D.9000508@oracle.com> <50A2B290.7040504@oracle.com>
	<50A2BF71.80504@oracle.com>
Message-ID: <50A3369D.5090403@oracle.com>

Alan is correct. A configuration is a selection of a range of things 
including platform, JDK variant (normal or embedded), JVM variant 
(client, server, minimal), "release" (product or fastdebug). When you do 
a build the classes only get compiled once regardless of which jar they 
end up in, or which image the jar ends up in. So this javac option will 
be applied to all classes and hence to all build artifacts.

None of which forces the selection of this being a configure time option 
versus a "make" time option. The main issue with the latter is that it 
makes it easier to produce inconsistent build results if you do partial 
builds and change the value of the option each time.

David

On 14/11/2012 7:45 AM, Alan Bateman wrote:
> On 13/11/2012 20:50, Alex Buckley wrote:
>>
>> The primary reason for storing parameter names in JDK8 class files is
>> to help IDE vendors, so it's fine if only the JDK image has them. We
>> are not making a general promise that any program will be able to find
>> parameter names of core Java Java SE classes at runtime. (Again,
>> please set aside concerns about footprint, compatibility, etc on this
>> list.)
>>
>> It sounds like a ./configure option of --enable-parameters could add
>> an option to JAVAC_FLAGS - you say it would affect all images? But
>> Erik said "the value of the option has different defaults depending on
>> jdk variant/profile".
> Suppose we do "configure --enable-paramater-names && make" then this
> would compile the classes and native libraries but at this point we
> don't have any images, rather it's just raw classes on the file system
> (no rt.jar).
>
> A subsequent "make images" would create the j2sdk-image and j2re-image
> with the rt.jar and the layout that we are used to. I think, and Erik or
> David can correct me, is that the same class files end up in both
> images. Subsequent stripping of debug attributes from everything in
> rt.jar may happen later, at least where JRE download size is important.
>
> So my point about the parameter names is that the same classes are used
> for all images. The "profiles" build is like "images", it's really just
> packaging up the already compiled bits and so would get the same class
> files, assuming of course that the JDK/JRE images and profiles images
> are coming from the same build.
>
> When Erik used the term "variant" then I assume he meant the
> --with-jdk-variant and --with-jvm-variant options to configure normal or
> embedded, client or server VM and things like that. That's part of the
> configuration. If we are compiling classes differently then I suspect it
> may require a separate configuration.
>
>>
>> Where should we look at the new build, given that the parameter
>> feature lives in the jdk8/tl forest?
> common/makefiles in the top-level repo, and makefiles directory in each
> of the other repos. Alternatively this guide:
>
> http://openjdk.java.net/projects/build-infra/guide.html
>
> -Alan.


From erik.joelsson at oracle.com  Wed Nov 14 01:43:50 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 14 Nov 2012 10:43:50 +0100
Subject: Building with a new javac flag
In-Reply-To: <50A3369D.5090403@oracle.com>
References: <50A16F70.5050107@oracle.com>
	<50A190C4.2070105@oracle.com>	<50A2366D.9000508@oracle.com>
	<50A2B290.7040504@oracle.com>	<50A2BF71.80504@oracle.com>
	<50A3369D.5090403@oracle.com>
Message-ID: <50A367D6.40209@oracle.com>

Alan and David are correct regarding how the build currently works. To 
support the case of only providing this information in certain images or 
profiles (like the JDK but not the JRE) we would need to produce class 
files of both kinds at some point in the build. This could be 
accomplished either by compiling everything twice or by stripping out 
the information at some point.

If the case is just to have different defaults between embedded and 
normal, it should be rather straight forward to add a configure argument 
that adds to the JAVAC_FLAGS variable. I would suggest adding this 
somewhere in common/autoconf/toolchain.m4. If you just want to see the 
effects of adding this parameter on a single build, running "make 
JAVAC_FLAGS=-parameter" should do the trick.

/Erik

On 2012-11-14 07:13, David Holmes wrote:
> Alan is correct. A configuration is a selection of a range of things 
> including platform, JDK variant (normal or embedded), JVM variant 
> (client, server, minimal), "release" (product or fastdebug). When you 
> do a build the classes only get compiled once regardless of which jar 
> they end up in, or which image the jar ends up in. So this javac 
> option will be applied to all classes and hence to all build artifacts.
>
> None of which forces the selection of this being a configure time 
> option versus a "make" time option. The main issue with the latter is 
> that it makes it easier to produce inconsistent build results if you 
> do partial builds and change the value of the option each time.
>
> David
>
> On 14/11/2012 7:45 AM, Alan Bateman wrote:
>> On 13/11/2012 20:50, Alex Buckley wrote:
>>>
>>> The primary reason for storing parameter names in JDK8 class files is
>>> to help IDE vendors, so it's fine if only the JDK image has them. We
>>> are not making a general promise that any program will be able to find
>>> parameter names of core Java Java SE classes at runtime. (Again,
>>> please set aside concerns about footprint, compatibility, etc on this
>>> list.)
>>>
>>> It sounds like a ./configure option of --enable-parameters could add
>>> an option to JAVAC_FLAGS - you say it would affect all images? But
>>> Erik said "the value of the option has different defaults depending on
>>> jdk variant/profile".
>> Suppose we do "configure --enable-paramater-names && make" then this
>> would compile the classes and native libraries but at this point we
>> don't have any images, rather it's just raw classes on the file system
>> (no rt.jar).
>>
>> A subsequent "make images" would create the j2sdk-image and j2re-image
>> with the rt.jar and the layout that we are used to. I think, and Erik or
>> David can correct me, is that the same class files end up in both
>> images. Subsequent stripping of debug attributes from everything in
>> rt.jar may happen later, at least where JRE download size is important.
>>
>> So my point about the parameter names is that the same classes are used
>> for all images. The "profiles" build is like "images", it's really just
>> packaging up the already compiled bits and so would get the same class
>> files, assuming of course that the JDK/JRE images and profiles images
>> are coming from the same build.
>>
>> When Erik used the term "variant" then I assume he meant the
>> --with-jdk-variant and --with-jvm-variant options to configure normal or
>> embedded, client or server VM and things like that. That's part of the
>> configuration. If we are compiling classes differently then I suspect it
>> may require a separate configuration.
>>
>>>
>>> Where should we look at the new build, given that the parameter
>>> feature lives in the jdk8/tl forest?
>> common/makefiles in the top-level repo, and makefiles directory in each
>> of the other repos. Alternatively this guide:
>>
>> http://openjdk.java.net/projects/build-infra/guide.html
>>
>> -Alan.


From alan.bateman at oracle.com  Wed Nov 14 03:01:28 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Wed, 14 Nov 2012 11:01:28 +0000
Subject: hg: jdk8/profiles/jdk: Typo in Attribtues.Name.Profile javadoc
Message-ID: <20121114110206.C99E747969@hg.openjdk.java.net>

Changeset: 636d1439dcec
Author:    alanb
Date:      2012-11-14 10:59 +0000
URL:       http://hg.openjdk.java.net/jdk8/profiles/jdk/rev/636d1439dcec

Typo in Attribtues.Name.Profile javadoc

! src/share/classes/java/util/jar/Attributes.java



From kelly.ohair at oracle.com  Wed Nov 14 09:09:23 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 14 Nov 2012 09:09:23 -0800
Subject: Building with a new javac flag
In-Reply-To: <50A367D6.40209@oracle.com>
References: <50A16F70.5050107@oracle.com>
	<50A190C4.2070105@oracle.com>	<50A2366D.9000508@oracle.com>
	<50A2B290.7040504@oracle.com>	<50A2BF71.80504@oracle.com>
	<50A3369D.5090403@oracle.com> <50A367D6.40209@oracle.com>
Message-ID: <308159CD-23A3-4ED6-A293-0E40D8DE9ABF@oracle.com>

Seems like if we want this information a permanent aspect of certain builds, it needs a configure argument means of doing it.

That doesn't prevent the use of JAVAC_FLAGS for this or other things.

---
I'm getting concerned that we end up with too many variations here, for the typical developers they need simple
ways to get the standard configurations.

-kto

On Nov 14, 2012, at 1:43 AM, Erik Joelsson wrote:

> Alan and David are correct regarding how the build currently works. To support the case of only providing this information in certain images or profiles (like the JDK but not the JRE) we would need to produce class files of both kinds at some point in the build. This could be accomplished either by compiling everything twice or by stripping out the information at some point.
> 
> If the case is just to have different defaults between embedded and normal, it should be rather straight forward to add a configure argument that adds to the JAVAC_FLAGS variable. I would suggest adding this somewhere in common/autoconf/toolchain.m4. If you just want to see the effects of adding this parameter on a single build, running "make JAVAC_FLAGS=-parameter" should do the trick.
> 
> /Erik
> 
> On 2012-11-14 07:13, David Holmes wrote:
>> Alan is correct. A configuration is a selection of a range of things including platform, JDK variant (normal or embedded), JVM variant (client, server, minimal), "release" (product or fastdebug). When you do a build the classes only get compiled once regardless of which jar they end up in, or which image the jar ends up in. So this javac option will be applied to all classes and hence to all build artifacts.
>> 
>> None of which forces the selection of this being a configure time option versus a "make" time option. The main issue with the latter is that it makes it easier to produce inconsistent build results if you do partial builds and change the value of the option each time.
>> 
>> David
>> 
>> On 14/11/2012 7:45 AM, Alan Bateman wrote:
>>> On 13/11/2012 20:50, Alex Buckley wrote:
>>>> 
>>>> The primary reason for storing parameter names in JDK8 class files is
>>>> to help IDE vendors, so it's fine if only the JDK image has them. We
>>>> are not making a general promise that any program will be able to find
>>>> parameter names of core Java Java SE classes at runtime. (Again,
>>>> please set aside concerns about footprint, compatibility, etc on this
>>>> list.)
>>>> 
>>>> It sounds like a ./configure option of --enable-parameters could add
>>>> an option to JAVAC_FLAGS - you say it would affect all images? But
>>>> Erik said "the value of the option has different defaults depending on
>>>> jdk variant/profile".
>>> Suppose we do "configure --enable-paramater-names && make" then this
>>> would compile the classes and native libraries but at this point we
>>> don't have any images, rather it's just raw classes on the file system
>>> (no rt.jar).
>>> 
>>> A subsequent "make images" would create the j2sdk-image and j2re-image
>>> with the rt.jar and the layout that we are used to. I think, and Erik or
>>> David can correct me, is that the same class files end up in both
>>> images. Subsequent stripping of debug attributes from everything in
>>> rt.jar may happen later, at least where JRE download size is important.
>>> 
>>> So my point about the parameter names is that the same classes are used
>>> for all images. The "profiles" build is like "images", it's really just
>>> packaging up the already compiled bits and so would get the same class
>>> files, assuming of course that the JDK/JRE images and profiles images
>>> are coming from the same build.
>>> 
>>> When Erik used the term "variant" then I assume he meant the
>>> --with-jdk-variant and --with-jvm-variant options to configure normal or
>>> embedded, client or server VM and things like that. That's part of the
>>> configuration. If we are compiling classes differently then I suspect it
>>> may require a separate configuration.
>>> 
>>>> 
>>>> Where should we look at the new build, given that the parameter
>>>> feature lives in the jdk8/tl forest?
>>> common/makefiles in the top-level repo, and makefiles directory in each
>>> of the other repos. Alternatively this guide:
>>> 
>>> http://openjdk.java.net/projects/build-infra/guide.html
>>> 
>>> -Alan.



From kelly.ohair at oracle.com  Wed Nov 14 09:15:01 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 14 Nov 2012 09:15:01 -0800
Subject: Building with a new javac flag
In-Reply-To: <50A2D4E9.10500@oracle.com>
References: <50A16F70.5050107@oracle.com> <50A190C4.2070105@oracle.com>
	<50A2366D.9000508@oracle.com> <50A2B290.7040504@oracle.com>
	<68D3C445-527B-4204-AD1F-0E68CD031840@oracle.com>
	<50A2D4E9.10500@oracle.com>
Message-ID: <2214A671-39E9-4FB4-9DAA-E3A7B8250DC8@oracle.com>

Sorry, since I haven't been involved in the discussions, I was just trying to gain some understanding
of when this data is needed, and if we could just simplify things and generate it all the time.

The configure&&make style of building opens quite a few doors in terms of build variations, and
that comes with positives and negatives. So I look for places where things can just be defaulted to 'on all the time'
with a rarely/selectively used 'turn it off' setting.  At least that is my preference.

-kto

On Nov 13, 2012, at 3:16 PM, Alex Buckley wrote:

> An IDE is not trying to debug code in rt.jar; it's trying to build a directory of classes and methods therein for type-ahead and refactoring. Quoting Brian:
> 
> "For the JDK, exposing this information means that IDEs can harvest parameter information without parsing sources, which is used for "implement methods" code wizards.  (Compare what happens in IntelliJ when you implement a method from a JDK interface to what happens in Eclipse.  In IJ, you get the names from the source; in Eclipse, you get "foo(String s1, String s2, int i1)".)"
> 
> We don't want javac to generate parameter names all the time for reasons outlined in the spec PDF posted to the enhanced-metadata-spec-discuss list. Again, I am trying to keep policy decisions about the feature off build-infra-dev.
> 
> Alex
> 
> On 11/13/2012 3:11 PM, Kelly O'Hair wrote:
>> From an IDE perspective, does it make sense to have parameter names,
>> but not line numbers? Seems like if we just generate the parameter
>> names all the time, and have pack200 strip them out for the JRE, then
>> we could just generate them all the time. Then there is no need for
>> an option, just a change to pack200 to remove a few attributes when
>> it is told to delete debug information in the jre runtime jars?
>> 
>> -kto
>> 
>> On Nov 13, 2012, at 12:50 PM, Alex Buckley wrote:
>> 
>>> On 11/13/2012 4:00 AM, Alan Bateman wrote:
>>>> This one may be significant enough to me to justify a configure
>>>> option. On the other hand, "make images profiles" would mean all
>>>> the resulting images (JDK, JRE, and Compact Profiles) would
>>>> either all have/not the parameter names.
>>> 
>>> The primary reason for storing parameter names in JDK8 class files
>>> is to help IDE vendors, so it's fine if only the JDK image has
>>> them. We are not making a general promise that any program will be
>>> able to find parameter names of core Java Java SE classes at
>>> runtime. (Again, please set aside concerns about footprint,
>>> compatibility, etc on this list.)
>>> 
>>> It sounds like a ./configure option of --enable-parameters could
>>> add an option to JAVAC_FLAGS - you say it would affect all images?
>>> But Erik said "the value of the option has different defaults
>>> depending on jdk variant/profile".
>>> 
>>> Where should we look at the new build, given that the parameter
>>> feature lives in the jdk8/tl forest?
>>> 
>>> Alex
>> 



From jonathan.gibbons at oracle.com  Wed Nov 14 10:21:39 2012
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 14 Nov 2012 10:21:39 -0800
Subject: Building with a new javac flag
In-Reply-To: <308159CD-23A3-4ED6-A293-0E40D8DE9ABF@oracle.com>
References: <50A16F70.5050107@oracle.com>
	<50A190C4.2070105@oracle.com>	<50A2366D.9000508@oracle.com>
	<50A2B290.7040504@oracle.com>	<50A2BF71.80504@oracle.com>
	<50A3369D.5090403@oracle.com> <50A367D6.40209@oracle.com>
	<308159CD-23A3-4ED6-A293-0E40D8DE9ABF@oracle.com>
Message-ID: <50A3E133.4030906@oracle.com>

If we already have a configure option for "JDK variant (normal or 
embedded)",  why do we need any additional options for parameter names, 
if the decision whether or not to use parameter names is a function of 
the variant?

-- Jon



On 11/14/2012 09:09 AM, Kelly O'Hair wrote:
> Seems like if we want this information a permanent aspect of certain builds, it needs a configure argument means of doing it.
>
> That doesn't prevent the use of JAVAC_FLAGS for this or other things.
>
> ---
> I'm getting concerned that we end up with too many variations here, for the typical developers they need simple
> ways to get the standard configurations.
>
> -kto
>
> On Nov 14, 2012, at 1:43 AM, Erik Joelsson wrote:
>
>> Alan and David are correct regarding how the build currently works. To support the case of only providing this information in certain images or profiles (like the JDK but not the JRE) we would need to produce class files of both kinds at some point in the build. This could be accomplished either by compiling everything twice or by stripping out the information at some point.
>>
>> If the case is just to have different defaults between embedded and normal, it should be rather straight forward to add a configure argument that adds to the JAVAC_FLAGS variable. I would suggest adding this somewhere in common/autoconf/toolchain.m4. If you just want to see the effects of adding this parameter on a single build, running "make JAVAC_FLAGS=-parameter" should do the trick.
>>
>> /Erik
>>
>> On 2012-11-14 07:13, David Holmes wrote:
>>> Alan is correct. A configuration is a selection of a range of things including platform, JDK variant (normal or embedded), JVM variant (client, server, minimal), "release" (product or fastdebug). When you do a build the classes only get compiled once regardless of which jar they end up in, or which image the jar ends up in. So this javac option will be applied to all classes and hence to all build artifacts.
>>>
>>> None of which forces the selection of this being a configure time option versus a "make" time option. The main issue with the latter is that it makes it easier to produce inconsistent build results if you do partial builds and change the value of the option each time.
>>>
>>> David
>>>
>>> On 14/11/2012 7:45 AM, Alan Bateman wrote:
>>>> On 13/11/2012 20:50, Alex Buckley wrote:
>>>>> The primary reason for storing parameter names in JDK8 class files is
>>>>> to help IDE vendors, so it's fine if only the JDK image has them. We
>>>>> are not making a general promise that any program will be able to find
>>>>> parameter names of core Java Java SE classes at runtime. (Again,
>>>>> please set aside concerns about footprint, compatibility, etc on this
>>>>> list.)
>>>>>
>>>>> It sounds like a ./configure option of --enable-parameters could add
>>>>> an option to JAVAC_FLAGS - you say it would affect all images? But
>>>>> Erik said "the value of the option has different defaults depending on
>>>>> jdk variant/profile".
>>>> Suppose we do "configure --enable-paramater-names && make" then this
>>>> would compile the classes and native libraries but at this point we
>>>> don't have any images, rather it's just raw classes on the file system
>>>> (no rt.jar).
>>>>
>>>> A subsequent "make images" would create the j2sdk-image and j2re-image
>>>> with the rt.jar and the layout that we are used to. I think, and Erik or
>>>> David can correct me, is that the same class files end up in both
>>>> images. Subsequent stripping of debug attributes from everything in
>>>> rt.jar may happen later, at least where JRE download size is important.
>>>>
>>>> So my point about the parameter names is that the same classes are used
>>>> for all images. The "profiles" build is like "images", it's really just
>>>> packaging up the already compiled bits and so would get the same class
>>>> files, assuming of course that the JDK/JRE images and profiles images
>>>> are coming from the same build.
>>>>
>>>> When Erik used the term "variant" then I assume he meant the
>>>> --with-jdk-variant and --with-jvm-variant options to configure normal or
>>>> embedded, client or server VM and things like that. That's part of the
>>>> configuration. If we are compiling classes differently then I suspect it
>>>> may require a separate configuration.
>>>>
>>>>> Where should we look at the new build, given that the parameter
>>>>> feature lives in the jdk8/tl forest?
>>>> common/makefiles in the top-level repo, and makefiles directory in each
>>>> of the other repos. Alternatively this guide:
>>>>
>>>> http://openjdk.java.net/projects/build-infra/guide.html
>>>>
>>>> -Alan.



From alex.buckley at oracle.com  Wed Nov 14 11:35:03 2012
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 14 Nov 2012 11:35:03 -0800
Subject: Building with a new javac flag
In-Reply-To: <50A3E133.4030906@oracle.com>
References: <50A16F70.5050107@oracle.com>
	<50A190C4.2070105@oracle.com>	<50A2366D.9000508@oracle.com>
	<50A2B290.7040504@oracle.com>	<50A2BF71.80504@oracle.com>
	<50A3369D.5090403@oracle.com> <50A367D6.40209@oracle.com>
	<308159CD-23A3-4ED6-A293-0E40D8DE9ABF@oracle.com>
	<50A3E133.4030906@oracle.com>
Message-ID: <50A3F267.6010901@oracle.com>

It sounds like the jdk-variant option would perfectly dominate the 
enable-parameters option, if we wanted parameters in the normal 
variant's JDK image and the normal variant's JRE image and the normal 
variant's Compact Profiles image.

But we would like parameters in only the normal variant's JDK image, not 
the other images, because IDEs only run on the biggest fattest JDK.

Alex

On 11/14/2012 10:21 AM, Jonathan Gibbons wrote:
> If we already have a configure option for "JDK variant (normal or
> embedded)",  why do we need any additional options for parameter names,
> if the decision whether or not to use parameter names is a function of
> the variant?
>
> -- Jon
>
>
>
> On 11/14/2012 09:09 AM, Kelly O'Hair wrote:
>> Seems like if we want this information a permanent aspect of certain
>> builds, it needs a configure argument means of doing it.
>>
>> That doesn't prevent the use of JAVAC_FLAGS for this or other things.
>>
>> ---
>> I'm getting concerned that we end up with too many variations here,
>> for the typical developers they need simple
>> ways to get the standard configurations.
>>
>> -kto
>>
>> On Nov 14, 2012, at 1:43 AM, Erik Joelsson wrote:
>>
>>> Alan and David are correct regarding how the build currently works.
>>> To support the case of only providing this information in certain
>>> images or profiles (like the JDK but not the JRE) we would need to
>>> produce class files of both kinds at some point in the build. This
>>> could be accomplished either by compiling everything twice or by
>>> stripping out the information at some point.
>>>
>>> If the case is just to have different defaults between embedded and
>>> normal, it should be rather straight forward to add a configure
>>> argument that adds to the JAVAC_FLAGS variable. I would suggest
>>> adding this somewhere in common/autoconf/toolchain.m4. If you just
>>> want to see the effects of adding this parameter on a single build,
>>> running "make JAVAC_FLAGS=-parameter" should do the trick.
>>>
>>> /Erik
>>>
>>> On 2012-11-14 07:13, David Holmes wrote:
>>>> Alan is correct. A configuration is a selection of a range of things
>>>> including platform, JDK variant (normal or embedded), JVM variant
>>>> (client, server, minimal), "release" (product or fastdebug). When
>>>> you do a build the classes only get compiled once regardless of
>>>> which jar they end up in, or which image the jar ends up in. So this
>>>> javac option will be applied to all classes and hence to all build
>>>> artifacts.
>>>>
>>>> None of which forces the selection of this being a configure time
>>>> option versus a "make" time option. The main issue with the latter
>>>> is that it makes it easier to produce inconsistent build results if
>>>> you do partial builds and change the value of the option each time.
>>>>
>>>> David
>>>>
>>>> On 14/11/2012 7:45 AM, Alan Bateman wrote:
>>>>> On 13/11/2012 20:50, Alex Buckley wrote:
>>>>>> The primary reason for storing parameter names in JDK8 class files is
>>>>>> to help IDE vendors, so it's fine if only the JDK image has them. We
>>>>>> are not making a general promise that any program will be able to
>>>>>> find
>>>>>> parameter names of core Java Java SE classes at runtime. (Again,
>>>>>> please set aside concerns about footprint, compatibility, etc on this
>>>>>> list.)
>>>>>>
>>>>>> It sounds like a ./configure option of --enable-parameters could add
>>>>>> an option to JAVAC_FLAGS - you say it would affect all images? But
>>>>>> Erik said "the value of the option has different defaults
>>>>>> depending on
>>>>>> jdk variant/profile".
>>>>> Suppose we do "configure --enable-paramater-names && make" then this
>>>>> would compile the classes and native libraries but at this point we
>>>>> don't have any images, rather it's just raw classes on the file system
>>>>> (no rt.jar).
>>>>>
>>>>> A subsequent "make images" would create the j2sdk-image and j2re-image
>>>>> with the rt.jar and the layout that we are used to. I think, and
>>>>> Erik or
>>>>> David can correct me, is that the same class files end up in both
>>>>> images. Subsequent stripping of debug attributes from everything in
>>>>> rt.jar may happen later, at least where JRE download size is
>>>>> important.
>>>>>
>>>>> So my point about the parameter names is that the same classes are
>>>>> used
>>>>> for all images. The "profiles" build is like "images", it's really
>>>>> just
>>>>> packaging up the already compiled bits and so would get the same class
>>>>> files, assuming of course that the JDK/JRE images and profiles images
>>>>> are coming from the same build.
>>>>>
>>>>> When Erik used the term "variant" then I assume he meant the
>>>>> --with-jdk-variant and --with-jvm-variant options to configure
>>>>> normal or
>>>>> embedded, client or server VM and things like that. That's part of the
>>>>> configuration. If we are compiling classes differently then I
>>>>> suspect it
>>>>> may require a separate configuration.
>>>>>
>>>>>> Where should we look at the new build, given that the parameter
>>>>>> feature lives in the jdk8/tl forest?
>>>>> common/makefiles in the top-level repo, and makefiles directory in
>>>>> each
>>>>> of the other repos. Alternatively this guide:
>>>>>
>>>>> http://openjdk.java.net/projects/build-infra/guide.html
>>>>>
>>>>> -Alan.
>


From jonathan.gibbons at oracle.com  Wed Nov 14 11:39:01 2012
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 14 Nov 2012 11:39:01 -0800
Subject: Building with a new javac flag
In-Reply-To: <50A3F267.6010901@oracle.com>
References: <50A16F70.5050107@oracle.com>
	<50A190C4.2070105@oracle.com>	<50A2366D.9000508@oracle.com>
	<50A2B290.7040504@oracle.com>	<50A2BF71.80504@oracle.com>
	<50A3369D.5090403@oracle.com> <50A367D6.40209@oracle.com>
	<308159CD-23A3-4ED6-A293-0E40D8DE9ABF@oracle.com>
	<50A3E133.4030906@oracle.com> <50A3F267.6010901@oracle.com>
Message-ID: <50A3F355.9010200@oracle.com>

OK, but it still sounds like the policy of when to include the 
parameters can be determined without requiring extra configuration 
parameters.

(Which is separate from whether we should have parameters to override 
the default determination.)

-- Jon


On 11/14/2012 11:35 AM, Alex Buckley wrote:
> It sounds like the jdk-variant option would perfectly dominate the 
> enable-parameters option, if we wanted parameters in the normal 
> variant's JDK image and the normal variant's JRE image and the normal 
> variant's Compact Profiles image.
>
> But we would like parameters in only the normal variant's JDK image, 
> not the other images, because IDEs only run on the biggest fattest JDK.
>
> Alex
>
> On 11/14/2012 10:21 AM, Jonathan Gibbons wrote:
>> If we already have a configure option for "JDK variant (normal or
>> embedded)",  why do we need any additional options for parameter names,
>> if the decision whether or not to use parameter names is a function of
>> the variant?
>>
>> -- Jon
>>
>>
>>
>> On 11/14/2012 09:09 AM, Kelly O'Hair wrote:
>>> Seems like if we want this information a permanent aspect of certain
>>> builds, it needs a configure argument means of doing it.
>>>
>>> That doesn't prevent the use of JAVAC_FLAGS for this or other things.
>>>
>>> ---
>>> I'm getting concerned that we end up with too many variations here,
>>> for the typical developers they need simple
>>> ways to get the standard configurations.
>>>
>>> -kto
>>>
>>> On Nov 14, 2012, at 1:43 AM, Erik Joelsson wrote:
>>>
>>>> Alan and David are correct regarding how the build currently works.
>>>> To support the case of only providing this information in certain
>>>> images or profiles (like the JDK but not the JRE) we would need to
>>>> produce class files of both kinds at some point in the build. This
>>>> could be accomplished either by compiling everything twice or by
>>>> stripping out the information at some point.
>>>>
>>>> If the case is just to have different defaults between embedded and
>>>> normal, it should be rather straight forward to add a configure
>>>> argument that adds to the JAVAC_FLAGS variable. I would suggest
>>>> adding this somewhere in common/autoconf/toolchain.m4. If you just
>>>> want to see the effects of adding this parameter on a single build,
>>>> running "make JAVAC_FLAGS=-parameter" should do the trick.
>>>>
>>>> /Erik
>>>>
>>>> On 2012-11-14 07:13, David Holmes wrote:
>>>>> Alan is correct. A configuration is a selection of a range of things
>>>>> including platform, JDK variant (normal or embedded), JVM variant
>>>>> (client, server, minimal), "release" (product or fastdebug). When
>>>>> you do a build the classes only get compiled once regardless of
>>>>> which jar they end up in, or which image the jar ends up in. So this
>>>>> javac option will be applied to all classes and hence to all build
>>>>> artifacts.
>>>>>
>>>>> None of which forces the selection of this being a configure time
>>>>> option versus a "make" time option. The main issue with the latter
>>>>> is that it makes it easier to produce inconsistent build results if
>>>>> you do partial builds and change the value of the option each time.
>>>>>
>>>>> David
>>>>>
>>>>> On 14/11/2012 7:45 AM, Alan Bateman wrote:
>>>>>> On 13/11/2012 20:50, Alex Buckley wrote:
>>>>>>> The primary reason for storing parameter names in JDK8 class 
>>>>>>> files is
>>>>>>> to help IDE vendors, so it's fine if only the JDK image has 
>>>>>>> them. We
>>>>>>> are not making a general promise that any program will be able to
>>>>>>> find
>>>>>>> parameter names of core Java Java SE classes at runtime. (Again,
>>>>>>> please set aside concerns about footprint, compatibility, etc on 
>>>>>>> this
>>>>>>> list.)
>>>>>>>
>>>>>>> It sounds like a ./configure option of --enable-parameters could 
>>>>>>> add
>>>>>>> an option to JAVAC_FLAGS - you say it would affect all images? But
>>>>>>> Erik said "the value of the option has different defaults
>>>>>>> depending on
>>>>>>> jdk variant/profile".
>>>>>> Suppose we do "configure --enable-paramater-names && make" then this
>>>>>> would compile the classes and native libraries but at this point we
>>>>>> don't have any images, rather it's just raw classes on the file 
>>>>>> system
>>>>>> (no rt.jar).
>>>>>>
>>>>>> A subsequent "make images" would create the j2sdk-image and 
>>>>>> j2re-image
>>>>>> with the rt.jar and the layout that we are used to. I think, and
>>>>>> Erik or
>>>>>> David can correct me, is that the same class files end up in both
>>>>>> images. Subsequent stripping of debug attributes from everything in
>>>>>> rt.jar may happen later, at least where JRE download size is
>>>>>> important.
>>>>>>
>>>>>> So my point about the parameter names is that the same classes are
>>>>>> used
>>>>>> for all images. The "profiles" build is like "images", it's really
>>>>>> just
>>>>>> packaging up the already compiled bits and so would get the same 
>>>>>> class
>>>>>> files, assuming of course that the JDK/JRE images and profiles 
>>>>>> images
>>>>>> are coming from the same build.
>>>>>>
>>>>>> When Erik used the term "variant" then I assume he meant the
>>>>>> --with-jdk-variant and --with-jvm-variant options to configure
>>>>>> normal or
>>>>>> embedded, client or server VM and things like that. That's part 
>>>>>> of the
>>>>>> configuration. If we are compiling classes differently then I
>>>>>> suspect it
>>>>>> may require a separate configuration.
>>>>>>
>>>>>>> Where should we look at the new build, given that the parameter
>>>>>>> feature lives in the jdk8/tl forest?
>>>>>> common/makefiles in the top-level repo, and makefiles directory in
>>>>>> each
>>>>>> of the other repos. Alternatively this guide:
>>>>>>
>>>>>> http://openjdk.java.net/projects/build-infra/guide.html
>>>>>>
>>>>>> -Alan.
>>



From alex.buckley at oracle.com  Wed Nov 14 12:07:56 2012
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 14 Nov 2012 12:07:56 -0800
Subject: Building with a new javac flag
In-Reply-To: <50A3F355.9010200@oracle.com>
References: <50A16F70.5050107@oracle.com>
	<50A190C4.2070105@oracle.com>	<50A2366D.9000508@oracle.com>
	<50A2B290.7040504@oracle.com>	<50A2BF71.80504@oracle.com>
	<50A3369D.5090403@oracle.com> <50A367D6.40209@oracle.com>
	<308159CD-23A3-4ED6-A293-0E40D8DE9ABF@oracle.com>
	<50A3E133.4030906@oracle.com> <50A3F267.6010901@oracle.com>
	<50A3F355.9010200@oracle.com>
Message-ID: <50A3FA1C.4080402@oracle.com>

Yes. We want parameters when jdk-variant=normal, so we'll include 
-parameters in the JAVAC_FLAGS for that configure option/value combo. 
Then the make targets for 'images' and 'profiles' will invoke pack200 to 
strip the parameter attributes except for the j2sdk-image.

Eric McCorkle will have a javac capable of emitting the attribute this 
week, so we'll try it out on his local forest.

Alex

On 11/14/2012 11:39 AM, Jonathan Gibbons wrote:
> OK, but it still sounds like the policy of when to include the
> parameters can be determined without requiring extra configuration
> parameters.
>
> (Which is separate from whether we should have parameters to override
> the default determination.)
>
> -- Jon
>
>
> On 11/14/2012 11:35 AM, Alex Buckley wrote:
>> It sounds like the jdk-variant option would perfectly dominate the
>> enable-parameters option, if we wanted parameters in the normal
>> variant's JDK image and the normal variant's JRE image and the normal
>> variant's Compact Profiles image.
>>
>> But we would like parameters in only the normal variant's JDK image,
>> not the other images, because IDEs only run on the biggest fattest JDK.
>>
>> Alex
>>
>> On 11/14/2012 10:21 AM, Jonathan Gibbons wrote:
>>> If we already have a configure option for "JDK variant (normal or
>>> embedded)",  why do we need any additional options for parameter names,
>>> if the decision whether or not to use parameter names is a function of
>>> the variant?
>>>
>>> -- Jon
>>>
>>>
>>>
>>> On 11/14/2012 09:09 AM, Kelly O'Hair wrote:
>>>> Seems like if we want this information a permanent aspect of certain
>>>> builds, it needs a configure argument means of doing it.
>>>>
>>>> That doesn't prevent the use of JAVAC_FLAGS for this or other things.
>>>>
>>>> ---
>>>> I'm getting concerned that we end up with too many variations here,
>>>> for the typical developers they need simple
>>>> ways to get the standard configurations.
>>>>
>>>> -kto
>>>>
>>>> On Nov 14, 2012, at 1:43 AM, Erik Joelsson wrote:
>>>>
>>>>> Alan and David are correct regarding how the build currently works.
>>>>> To support the case of only providing this information in certain
>>>>> images or profiles (like the JDK but not the JRE) we would need to
>>>>> produce class files of both kinds at some point in the build. This
>>>>> could be accomplished either by compiling everything twice or by
>>>>> stripping out the information at some point.
>>>>>
>>>>> If the case is just to have different defaults between embedded and
>>>>> normal, it should be rather straight forward to add a configure
>>>>> argument that adds to the JAVAC_FLAGS variable. I would suggest
>>>>> adding this somewhere in common/autoconf/toolchain.m4. If you just
>>>>> want to see the effects of adding this parameter on a single build,
>>>>> running "make JAVAC_FLAGS=-parameter" should do the trick.
>>>>>
>>>>> /Erik
>>>>>
>>>>> On 2012-11-14 07:13, David Holmes wrote:
>>>>>> Alan is correct. A configuration is a selection of a range of things
>>>>>> including platform, JDK variant (normal or embedded), JVM variant
>>>>>> (client, server, minimal), "release" (product or fastdebug). When
>>>>>> you do a build the classes only get compiled once regardless of
>>>>>> which jar they end up in, or which image the jar ends up in. So this
>>>>>> javac option will be applied to all classes and hence to all build
>>>>>> artifacts.
>>>>>>
>>>>>> None of which forces the selection of this being a configure time
>>>>>> option versus a "make" time option. The main issue with the latter
>>>>>> is that it makes it easier to produce inconsistent build results if
>>>>>> you do partial builds and change the value of the option each time.
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On 14/11/2012 7:45 AM, Alan Bateman wrote:
>>>>>>> On 13/11/2012 20:50, Alex Buckley wrote:
>>>>>>>> The primary reason for storing parameter names in JDK8 class
>>>>>>>> files is
>>>>>>>> to help IDE vendors, so it's fine if only the JDK image has
>>>>>>>> them. We
>>>>>>>> are not making a general promise that any program will be able to
>>>>>>>> find
>>>>>>>> parameter names of core Java Java SE classes at runtime. (Again,
>>>>>>>> please set aside concerns about footprint, compatibility, etc on
>>>>>>>> this
>>>>>>>> list.)
>>>>>>>>
>>>>>>>> It sounds like a ./configure option of --enable-parameters could
>>>>>>>> add
>>>>>>>> an option to JAVAC_FLAGS - you say it would affect all images? But
>>>>>>>> Erik said "the value of the option has different defaults
>>>>>>>> depending on
>>>>>>>> jdk variant/profile".
>>>>>>> Suppose we do "configure --enable-paramater-names && make" then this
>>>>>>> would compile the classes and native libraries but at this point we
>>>>>>> don't have any images, rather it's just raw classes on the file
>>>>>>> system
>>>>>>> (no rt.jar).
>>>>>>>
>>>>>>> A subsequent "make images" would create the j2sdk-image and
>>>>>>> j2re-image
>>>>>>> with the rt.jar and the layout that we are used to. I think, and
>>>>>>> Erik or
>>>>>>> David can correct me, is that the same class files end up in both
>>>>>>> images. Subsequent stripping of debug attributes from everything in
>>>>>>> rt.jar may happen later, at least where JRE download size is
>>>>>>> important.
>>>>>>>
>>>>>>> So my point about the parameter names is that the same classes are
>>>>>>> used
>>>>>>> for all images. The "profiles" build is like "images", it's really
>>>>>>> just
>>>>>>> packaging up the already compiled bits and so would get the same
>>>>>>> class
>>>>>>> files, assuming of course that the JDK/JRE images and profiles
>>>>>>> images
>>>>>>> are coming from the same build.
>>>>>>>
>>>>>>> When Erik used the term "variant" then I assume he meant the
>>>>>>> --with-jdk-variant and --with-jvm-variant options to configure
>>>>>>> normal or
>>>>>>> embedded, client or server VM and things like that. That's part
>>>>>>> of the
>>>>>>> configuration. If we are compiling classes differently then I
>>>>>>> suspect it
>>>>>>> may require a separate configuration.
>>>>>>>
>>>>>>>> Where should we look at the new build, given that the parameter
>>>>>>>> feature lives in the jdk8/tl forest?
>>>>>>> common/makefiles in the top-level repo, and makefiles directory in
>>>>>>> each
>>>>>>> of the other repos. Alternatively this guide:
>>>>>>>
>>>>>>> http://openjdk.java.net/projects/build-infra/guide.html
>>>>>>>
>>>>>>> -Alan.
>>>
>


From james.holmlund at oracle.com  Wed Nov 14 13:02:44 2012
From: james.holmlund at oracle.com (Jim Holmlund)
Date: Wed, 14 Nov 2012 13:02:44 -0800
Subject: cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
	error in build-infra build ('old' build works OK)
In-Reply-To: <50A02E86.6080002@oracle.com>
References: <CAP7YuAT+X+BfcsFm=tZk3orEHyFh=_eK07B1KUPmJ106CnREyw@mail.gmail.com>
	<50A02E86.6080002@oracle.com>
Message-ID: <50A406F4.8010109@oracle.com>



On 11/11/2012 3:02 PM, David Holmes wrote:
> Hi Martijn,
>
> Known issue fixed a couple of days ago:
>
> http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/1e79fec4a01f
>
I see this building tl also.
I guess this means that the new infra is broken in tl until the above fix wends its way up to jdk 
master and then back down into tl?

- jjh

> David
>
> On 12/11/2012 8:45 AM, Martijn Verburg wrote:
>> Hi all,
>>
>> Building jdk8_tl on Ubuntu 12.04 with OpenJDK Runtime Environment (IcedTea7
>> 2.3.3) (7u9-2.3.3-0ubuntu1~12.04.1)
>> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode). I get the following
>> compilation error using build-infra (but not the 'old' build).
>>
>> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:
>> In function `UnrollHalfToFloat':
>> cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
>> cmspack.c:(.text+0x27c6): undefined reference to `_cmsHalf2Float'
>> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:
>> In function `UnrollHalfTo16':
>> cmspack.c:(.text+0x2953): undefined reference to `_cmsHalf2Float'
>> cmspack.c:(.text+0x29fa): undefined reference to `_cmsHalf2Float'
>> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:
>> In function `PackHalfFromFloat':
>> cmspack.c:(.text+0x2baf): undefined reference to `_cmsFloat2Half'
>> cmspack.c:(.text+0x2c10): undefined reference to `_cmsFloat2Half'
>> cmspack.c:(.text+0x2ccb): undefined reference to `_cmsFloat2Half'
>> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:
>> In function `PackHalfFrom16':
>> cmspack.c:(.text+0x2de7): undefined reference to `_cmsFloat2Half'
>> cmspack.c:(.text+0x2e4d): undefined reference to `_cmsFloat2Half'
>> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:cmspack.c:(.text+0x2f01): 
>>
>> more undefined references to `_cmsFloat2Half' follow
>> collect2: ld returned 1 exit status
>> make[2]: ***
>> [/home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/lib/amd64/liblcms.so]
>> Error 1
>> make[1]: *** [libs-only] Error 2
>> make: *** [jdk-only] Error 2
>>
>> Haven't tracked it down any further than this yet, but thought I should
>> report it in :-).
>>
>> Cheers,
>> Martijn


From henry.jen at oracle.com  Wed Nov 14 13:26:57 2012
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 14 Nov 2012 13:26:57 -0800
Subject: cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
	error in build-infra build ('old' build works OK)
In-Reply-To: <50A406F4.8010109@oracle.com>
References: <CAP7YuAT+X+BfcsFm=tZk3orEHyFh=_eK07B1KUPmJ106CnREyw@mail.gmail.com>
	<50A02E86.6080002@oracle.com> <50A406F4.8010109@oracle.com>
Message-ID: <50A40CA1.1040509@oracle.com>

On 11/14/2012 01:02 PM, Jim Holmlund wrote:
> 
> 
> On 11/11/2012 3:02 PM, David Holmes wrote:
>> Hi Martijn,
>>
>> Known issue fixed a couple of days ago:
>>
>> http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/1e79fec4a01f
>>
> I see this building tl also.
> I guess this means that the new infra is broken in tl until the above
> fix wends its way up to jdk master and then back down into tl?
>

Yes, I have to fix two things in TL.

Another is to redo a297b0e14605 for hotspot in TL.

Cheers,
Henry


> - jjh
> 
>> David
>>
>> On 12/11/2012 8:45 AM, Martijn Verburg wrote:
>>> Hi all,
>>>
>>> Building jdk8_tl on Ubuntu 12.04 with OpenJDK Runtime Environment
>>> (IcedTea7
>>> 2.3.3) (7u9-2.3.3-0ubuntu1~12.04.1)
>>> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode). I get the
>>> following
>>> compilation error using build-infra (but not the 'old' build).
>>>
>>> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:
>>>
>>> In function `UnrollHalfToFloat':
>>> cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
>>> cmspack.c:(.text+0x27c6): undefined reference to `_cmsHalf2Float'
>>> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:
>>>
>>> In function `UnrollHalfTo16':
>>> cmspack.c:(.text+0x2953): undefined reference to `_cmsHalf2Float'
>>> cmspack.c:(.text+0x29fa): undefined reference to `_cmsHalf2Float'
>>> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:
>>>
>>> In function `PackHalfFromFloat':
>>> cmspack.c:(.text+0x2baf): undefined reference to `_cmsFloat2Half'
>>> cmspack.c:(.text+0x2c10): undefined reference to `_cmsFloat2Half'
>>> cmspack.c:(.text+0x2ccb): undefined reference to `_cmsFloat2Half'
>>> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:
>>>
>>> In function `PackHalfFrom16':
>>> cmspack.c:(.text+0x2de7): undefined reference to `_cmsFloat2Half'
>>> cmspack.c:(.text+0x2e4d): undefined reference to `_cmsFloat2Half'
>>> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:cmspack.c:(.text+0x2f01):
>>>
>>> more undefined references to `_cmsFloat2Half' follow
>>> collect2: ld returned 1 exit status
>>> make[2]: ***
>>> [/home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/lib/amd64/liblcms.so]
>>>
>>> Error 1
>>> make[1]: *** [libs-only] Error 2
>>> make: *** [jdk-only] Error 2
>>>
>>> Haven't tracked it down any further than this yet, but thought I should
>>> report it in :-).
>>>
>>> Cheers,
>>> Martijn



From philip.race at oracle.com  Wed Nov 14 14:03:45 2012
From: philip.race at oracle.com (Phil Race)
Date: Wed, 14 Nov 2012 14:03:45 -0800
Subject: cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
	error in build-infra build ('old' build works OK)
In-Reply-To: <50A02E86.6080002@oracle.com>
References: <CAP7YuAT+X+BfcsFm=tZk3orEHyFh=_eK07B1KUPmJ106CnREyw@mail.gmail.com>
	<50A02E86.6080002@oracle.com>
Message-ID: <50A41541.7020606@oracle.com>

Ah .. I guess we (2d) broke that when we added the new file from LCMS 2.4 to
FILES_c_unix.gmk but had no clue this other new top-level file existed.
Kelly said get Makefile changes reviewed but didn't mention file lists.

So in the new build system is *everything* centralised like this?
Monolithic files rather than including area specific ones ?
I'm not sure what the supposed advantage might be?

-phil.

On 11/11/12 3:02 PM, David Holmes wrote:
> Hi Martijn,
>
> Known issue fixed a couple of days ago:
>
> http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/1e79fec4a01f
>
> David
>
> On 12/11/2012 8:45 AM, Martijn Verburg wrote:
>> Hi all,
>>
>> Building jdk8_tl on Ubuntu 12.04 with OpenJDK Runtime Environment 
>> (IcedTea7
>> 2.3.3) (7u9-2.3.3-0ubuntu1~12.04.1)
>> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode). I get the 
>> following
>> compilation error using build-infra (but not the 'old' build).
>>
>> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o: 
>>
>> In function `UnrollHalfToFloat':
>> cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
>> cmspack.c:(.text+0x27c6): undefined reference to `_cmsHalf2Float'
>> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o: 
>>
>> In function `UnrollHalfTo16':
>> cmspack.c:(.text+0x2953): undefined reference to `_cmsHalf2Float'
>> cmspack.c:(.text+0x29fa): undefined reference to `_cmsHalf2Float'
>> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o: 
>>
>> In function `PackHalfFromFloat':
>> cmspack.c:(.text+0x2baf): undefined reference to `_cmsFloat2Half'
>> cmspack.c:(.text+0x2c10): undefined reference to `_cmsFloat2Half'
>> cmspack.c:(.text+0x2ccb): undefined reference to `_cmsFloat2Half'
>> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o: 
>>
>> In function `PackHalfFrom16':
>> cmspack.c:(.text+0x2de7): undefined reference to `_cmsFloat2Half'
>> cmspack.c:(.text+0x2e4d): undefined reference to `_cmsFloat2Half'
>> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:cmspack.c:(.text+0x2f01): 
>>
>> more undefined references to `_cmsFloat2Half' follow
>> collect2: ld returned 1 exit status
>> make[2]: ***
>> [/home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/lib/amd64/liblcms.so] 
>>
>> Error 1
>> make[1]: *** [libs-only] Error 2
>> make: *** [jdk-only] Error 2
>>
>> Haven't tracked it down any further than this yet, but thought I should
>> report it in :-).
>>
>> Cheers,
>> Martijn



From kelly.ohair at oracle.com  Wed Nov 14 15:23:08 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 14 Nov 2012 15:23:08 -0800
Subject: cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
	error in build-infra build ('old' build works OK)
In-Reply-To: <50A41541.7020606@oracle.com>
References: <CAP7YuAT+X+BfcsFm=tZk3orEHyFh=_eK07B1KUPmJ106CnREyw@mail.gmail.com>
	<50A02E86.6080002@oracle.com> <50A41541.7020606@oracle.com>
Message-ID: <ADEF6951-8294-4C7E-A326-B62389AB7014@oracle.com>


On Nov 14, 2012, at 2:03 PM, Phil Race wrote:

> Ah .. I guess we (2d) broke that when we added the new file from LCMS 2.4 to
> FILES_c_unix.gmk but had no clue this other new top-level file existed.
> Kelly said get Makefile changes reviewed but didn't mention file lists.

I stated that anything in the make/ directories needed to be run by us.

> 
> So in the new build system is *everything* centralised like this?

Yes.

> Monolithic files rather than including area specific ones ?

Yes.

> I'm not sure what the supposed advantage might be?

It's ONE make process, and all dependencies are defined in one make process.
That's what allows us to do builds with the GNU make -j N option and gets us faster builds.
It only works when we have one make process that has all the dependencies.

Organization wise, we may split these included makefiles up, but not as separate "Makefiles".
For now, it's best to keep them all together until we clean up all the differences.
Much of the ugliness here is due to unnecessary differences, special cases, and sometimes incorrect make logic that
has been living in the old makefiles for a long time, for now we want to match the old makefile
behaviors, but at some point we will need to do some clean up here.

-kto

> 
> -phil.
> 
> On 11/11/12 3:02 PM, David Holmes wrote:
>> Hi Martijn,
>> 
>> Known issue fixed a couple of days ago:
>> 
>> http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/1e79fec4a01f
>> 
>> David
>> 
>> On 12/11/2012 8:45 AM, Martijn Verburg wrote:
>>> Hi all,
>>> 
>>> Building jdk8_tl on Ubuntu 12.04 with OpenJDK Runtime Environment (IcedTea7
>>> 2.3.3) (7u9-2.3.3-0ubuntu1~12.04.1)
>>> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode). I get the following
>>> compilation error using build-infra (but not the 'old' build).
>>> 
>>> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o: 
>>> In function `UnrollHalfToFloat':
>>> cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
>>> cmspack.c:(.text+0x27c6): undefined reference to `_cmsHalf2Float'
>>> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o: 
>>> In function `UnrollHalfTo16':
>>> cmspack.c:(.text+0x2953): undefined reference to `_cmsHalf2Float'
>>> cmspack.c:(.text+0x29fa): undefined reference to `_cmsHalf2Float'
>>> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o: 
>>> In function `PackHalfFromFloat':
>>> cmspack.c:(.text+0x2baf): undefined reference to `_cmsFloat2Half'
>>> cmspack.c:(.text+0x2c10): undefined reference to `_cmsFloat2Half'
>>> cmspack.c:(.text+0x2ccb): undefined reference to `_cmsFloat2Half'
>>> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o: 
>>> In function `PackHalfFrom16':
>>> cmspack.c:(.text+0x2de7): undefined reference to `_cmsFloat2Half'
>>> cmspack.c:(.text+0x2e4d): undefined reference to `_cmsFloat2Half'
>>> /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:cmspack.c:(.text+0x2f01): 
>>> more undefined references to `_cmsFloat2Half' follow
>>> collect2: ld returned 1 exit status
>>> make[2]: ***
>>> [/home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/lib/amd64/liblcms.so] 
>>> Error 1
>>> make[1]: *** [libs-only] Error 2
>>> make: *** [jdk-only] Error 2
>>> 
>>> Haven't tracked it down any further than this yet, but thought I should
>>> report it in :-).
>>> 
>>> Cheers,
>>> Martijn
> 



From philip.race at oracle.com  Wed Nov 14 21:01:40 2012
From: philip.race at oracle.com (Phil Race)
Date: Wed, 14 Nov 2012 21:01:40 -0800
Subject: cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
	error in build-infra build ('old' build works OK)
In-Reply-To: <ADEF6951-8294-4C7E-A326-B62389AB7014@oracle.com>
References: <CAP7YuAT+X+BfcsFm=tZk3orEHyFh=_eK07B1KUPmJ106CnREyw@mail.gmail.com>
	<50A02E86.6080002@oracle.com> <50A41541.7020606@oracle.com>
	<ADEF6951-8294-4C7E-A326-B62389AB7014@oracle.com>
Message-ID: <50A47734.2010602@oracle.com>

On 11/14/12 3:23 PM, Kelly O'Hair wrote:
> On Nov 14, 2012, at 2:03 PM, Phil Race wrote:
>
>> Ah .. I guess we (2d) broke that when we added the new file from LCMS 2.4 to
>> FILES_c_unix.gmk but had no clue this other new top-level file existed.
>> Kelly said get Makefile changes reviewed but didn't mention file lists.
> I stated that anything in the make/ directories needed to be run by us.

Can I quote what you said .. its not quite so clear :-


-------- Original Message --------
Subject: 	Makefile changes
Date: 	Thu, 18 Oct 2012 10:47:35 -0700
From: 	Kelly O'Hair <kelly.ohair at oracle.com>
To: 	jdk8-dev <jdk8-dev at openjdk.java.net>
CC: 	build-dev build-dev <build-dev at openjdk.java.net>



If you are making any changes to the Makefiles or build process in jdk8, please let us know in the build group
build-dev at openjdk.java.net. We will need to review and approve ALL Makefile and build changes from now
until we change over to the new build-infra Makefiles.
The build-infra team can help you determine the equivalent change needed in the new build-infra Makefiles.

-kto


-----------------------

As for the rest, I don't have anything concrete but it just seems like
the pendulum swinging to build time at all costs


-phil.




From david.holmes at oracle.com  Wed Nov 14 21:12:15 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 15 Nov 2012 15:12:15 +1000
Subject: Building with a new javac flag
In-Reply-To: <50A3FA1C.4080402@oracle.com>
References: <50A16F70.5050107@oracle.com>
	<50A190C4.2070105@oracle.com>	<50A2366D.9000508@oracle.com>
	<50A2B290.7040504@oracle.com>	<50A2BF71.80504@oracle.com>
	<50A3369D.5090403@oracle.com> <50A367D6.40209@oracle.com>
	<308159CD-23A3-4ED6-A293-0E40D8DE9ABF@oracle.com>
	<50A3E133.4030906@oracle.com> <50A3F267.6010901@oracle.com>
	<50A3F355.9010200@oracle.com> <50A3FA1C.4080402@oracle.com>
Message-ID: <50A479AF.3060005@oracle.com>

On 15/11/2012 6:07 AM, Alex Buckley wrote:
> Yes. We want parameters when jdk-variant=normal, so we'll include
> -parameters in the JAVAC_FLAGS for that configure option/value combo.
> Then the make targets for 'images' and 'profiles' will invoke pack200 to
> strip the parameter attributes except for the j2sdk-image.

In that case we don't need any new configure options as this approach 
also works for embedded as it doesn't care about the full JDK.

Though we might want to conditionalize this on whether OPENJDK is true 
or not. There are some concerns about Oracle JDK build requirements 
being applied by default to OpenJDK builds.

Also how does the stripping work - does it mean that we will have to 
copy all the .class files first, or can it be applied when creating the 
jar files?

David

> Eric McCorkle will have a javac capable of emitting the attribute this
> week, so we'll try it out on his local forest.
>
> Alex
>
> On 11/14/2012 11:39 AM, Jonathan Gibbons wrote:
>> OK, but it still sounds like the policy of when to include the
>> parameters can be determined without requiring extra configuration
>> parameters.
>>
>> (Which is separate from whether we should have parameters to override
>> the default determination.)
>>
>> -- Jon
>>
>>
>> On 11/14/2012 11:35 AM, Alex Buckley wrote:
>>> It sounds like the jdk-variant option would perfectly dominate the
>>> enable-parameters option, if we wanted parameters in the normal
>>> variant's JDK image and the normal variant's JRE image and the normal
>>> variant's Compact Profiles image.
>>>
>>> But we would like parameters in only the normal variant's JDK image,
>>> not the other images, because IDEs only run on the biggest fattest JDK.
>>>
>>> Alex
>>>
>>> On 11/14/2012 10:21 AM, Jonathan Gibbons wrote:
>>>> If we already have a configure option for "JDK variant (normal or
>>>> embedded)", why do we need any additional options for parameter names,
>>>> if the decision whether or not to use parameter names is a function of
>>>> the variant?
>>>>
>>>> -- Jon
>>>>
>>>>
>>>>
>>>> On 11/14/2012 09:09 AM, Kelly O'Hair wrote:
>>>>> Seems like if we want this information a permanent aspect of certain
>>>>> builds, it needs a configure argument means of doing it.
>>>>>
>>>>> That doesn't prevent the use of JAVAC_FLAGS for this or other things.
>>>>>
>>>>> ---
>>>>> I'm getting concerned that we end up with too many variations here,
>>>>> for the typical developers they need simple
>>>>> ways to get the standard configurations.
>>>>>
>>>>> -kto
>>>>>
>>>>> On Nov 14, 2012, at 1:43 AM, Erik Joelsson wrote:
>>>>>
>>>>>> Alan and David are correct regarding how the build currently works.
>>>>>> To support the case of only providing this information in certain
>>>>>> images or profiles (like the JDK but not the JRE) we would need to
>>>>>> produce class files of both kinds at some point in the build. This
>>>>>> could be accomplished either by compiling everything twice or by
>>>>>> stripping out the information at some point.
>>>>>>
>>>>>> If the case is just to have different defaults between embedded and
>>>>>> normal, it should be rather straight forward to add a configure
>>>>>> argument that adds to the JAVAC_FLAGS variable. I would suggest
>>>>>> adding this somewhere in common/autoconf/toolchain.m4. If you just
>>>>>> want to see the effects of adding this parameter on a single build,
>>>>>> running "make JAVAC_FLAGS=-parameter" should do the trick.
>>>>>>
>>>>>> /Erik
>>>>>>
>>>>>> On 2012-11-14 07:13, David Holmes wrote:
>>>>>>> Alan is correct. A configuration is a selection of a range of things
>>>>>>> including platform, JDK variant (normal or embedded), JVM variant
>>>>>>> (client, server, minimal), "release" (product or fastdebug). When
>>>>>>> you do a build the classes only get compiled once regardless of
>>>>>>> which jar they end up in, or which image the jar ends up in. So this
>>>>>>> javac option will be applied to all classes and hence to all build
>>>>>>> artifacts.
>>>>>>>
>>>>>>> None of which forces the selection of this being a configure time
>>>>>>> option versus a "make" time option. The main issue with the latter
>>>>>>> is that it makes it easier to produce inconsistent build results if
>>>>>>> you do partial builds and change the value of the option each time.
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>> On 14/11/2012 7:45 AM, Alan Bateman wrote:
>>>>>>>> On 13/11/2012 20:50, Alex Buckley wrote:
>>>>>>>>> The primary reason for storing parameter names in JDK8 class
>>>>>>>>> files is
>>>>>>>>> to help IDE vendors, so it's fine if only the JDK image has
>>>>>>>>> them. We
>>>>>>>>> are not making a general promise that any program will be able to
>>>>>>>>> find
>>>>>>>>> parameter names of core Java Java SE classes at runtime. (Again,
>>>>>>>>> please set aside concerns about footprint, compatibility, etc on
>>>>>>>>> this
>>>>>>>>> list.)
>>>>>>>>>
>>>>>>>>> It sounds like a ./configure option of --enable-parameters could
>>>>>>>>> add
>>>>>>>>> an option to JAVAC_FLAGS - you say it would affect all images? But
>>>>>>>>> Erik said "the value of the option has different defaults
>>>>>>>>> depending on
>>>>>>>>> jdk variant/profile".
>>>>>>>> Suppose we do "configure --enable-paramater-names && make" then
>>>>>>>> this
>>>>>>>> would compile the classes and native libraries but at this point we
>>>>>>>> don't have any images, rather it's just raw classes on the file
>>>>>>>> system
>>>>>>>> (no rt.jar).
>>>>>>>>
>>>>>>>> A subsequent "make images" would create the j2sdk-image and
>>>>>>>> j2re-image
>>>>>>>> with the rt.jar and the layout that we are used to. I think, and
>>>>>>>> Erik or
>>>>>>>> David can correct me, is that the same class files end up in both
>>>>>>>> images. Subsequent stripping of debug attributes from everything in
>>>>>>>> rt.jar may happen later, at least where JRE download size is
>>>>>>>> important.
>>>>>>>>
>>>>>>>> So my point about the parameter names is that the same classes are
>>>>>>>> used
>>>>>>>> for all images. The "profiles" build is like "images", it's really
>>>>>>>> just
>>>>>>>> packaging up the already compiled bits and so would get the same
>>>>>>>> class
>>>>>>>> files, assuming of course that the JDK/JRE images and profiles
>>>>>>>> images
>>>>>>>> are coming from the same build.
>>>>>>>>
>>>>>>>> When Erik used the term "variant" then I assume he meant the
>>>>>>>> --with-jdk-variant and --with-jvm-variant options to configure
>>>>>>>> normal or
>>>>>>>> embedded, client or server VM and things like that. That's part
>>>>>>>> of the
>>>>>>>> configuration. If we are compiling classes differently then I
>>>>>>>> suspect it
>>>>>>>> may require a separate configuration.
>>>>>>>>
>>>>>>>>> Where should we look at the new build, given that the parameter
>>>>>>>>> feature lives in the jdk8/tl forest?
>>>>>>>> common/makefiles in the top-level repo, and makefiles directory in
>>>>>>>> each
>>>>>>>> of the other repos. Alternatively this guide:
>>>>>>>>
>>>>>>>> http://openjdk.java.net/projects/build-infra/guide.html
>>>>>>>>
>>>>>>>> -Alan.
>>>>
>>


From jonathan.gibbons at oracle.com  Wed Nov 14 21:14:34 2012
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 14 Nov 2012 21:14:34 -0800
Subject: Building with a new javac flag
In-Reply-To: <50A479AF.3060005@oracle.com>
References: <50A16F70.5050107@oracle.com>
	<50A190C4.2070105@oracle.com>	<50A2366D.9000508@oracle.com>
	<50A2B290.7040504@oracle.com>	<50A2BF71.80504@oracle.com>
	<50A3369D.5090403@oracle.com> <50A367D6.40209@oracle.com>
	<308159CD-23A3-4ED6-A293-0E40D8DE9ABF@oracle.com>
	<50A3E133.4030906@oracle.com> <50A3F267.6010901@oracle.com>
	<50A3F355.9010200@oracle.com> <50A3FA1C.4080402@oracle.com>
	<50A479AF.3060005@oracle.com>
Message-ID: <50A47A3A.7000706@oracle.com>

I believe the plan would be to use pack200 to strip the attribute.

-- Jon

On 11/14/2012 09:12 PM, David Holmes wrote:
> On 15/11/2012 6:07 AM, Alex Buckley wrote:
>> Yes. We want parameters when jdk-variant=normal, so we'll include
>> -parameters in the JAVAC_FLAGS for that configure option/value combo.
>> Then the make targets for 'images' and 'profiles' will invoke pack200 to
>> strip the parameter attributes except for the j2sdk-image.
>
> In that case we don't need any new configure options as this approach 
> also works for embedded as it doesn't care about the full JDK.
>
> Though we might want to conditionalize this on whether OPENJDK is true 
> or not. There are some concerns about Oracle JDK build requirements 
> being applied by default to OpenJDK builds.
>
> Also how does the stripping work - does it mean that we will have to 
> copy all the .class files first, or can it be applied when creating 
> the jar files?
>
> David
>
>> Eric McCorkle will have a javac capable of emitting the attribute this
>> week, so we'll try it out on his local forest.
>>
>> Alex
>>
>> On 11/14/2012 11:39 AM, Jonathan Gibbons wrote:
>>> OK, but it still sounds like the policy of when to include the
>>> parameters can be determined without requiring extra configuration
>>> parameters.
>>>
>>> (Which is separate from whether we should have parameters to override
>>> the default determination.)
>>>
>>> -- Jon
>>>
>>>
>>> On 11/14/2012 11:35 AM, Alex Buckley wrote:
>>>> It sounds like the jdk-variant option would perfectly dominate the
>>>> enable-parameters option, if we wanted parameters in the normal
>>>> variant's JDK image and the normal variant's JRE image and the normal
>>>> variant's Compact Profiles image.
>>>>
>>>> But we would like parameters in only the normal variant's JDK image,
>>>> not the other images, because IDEs only run on the biggest fattest 
>>>> JDK.
>>>>
>>>> Alex
>>>>
>>>> On 11/14/2012 10:21 AM, Jonathan Gibbons wrote:
>>>>> If we already have a configure option for "JDK variant (normal or
>>>>> embedded)", why do we need any additional options for parameter 
>>>>> names,
>>>>> if the decision whether or not to use parameter names is a 
>>>>> function of
>>>>> the variant?
>>>>>
>>>>> -- Jon
>>>>>
>>>>>
>>>>>
>>>>> On 11/14/2012 09:09 AM, Kelly O'Hair wrote:
>>>>>> Seems like if we want this information a permanent aspect of certain
>>>>>> builds, it needs a configure argument means of doing it.
>>>>>>
>>>>>> That doesn't prevent the use of JAVAC_FLAGS for this or other 
>>>>>> things.
>>>>>>
>>>>>> ---
>>>>>> I'm getting concerned that we end up with too many variations here,
>>>>>> for the typical developers they need simple
>>>>>> ways to get the standard configurations.
>>>>>>
>>>>>> -kto
>>>>>>
>>>>>> On Nov 14, 2012, at 1:43 AM, Erik Joelsson wrote:
>>>>>>
>>>>>>> Alan and David are correct regarding how the build currently works.
>>>>>>> To support the case of only providing this information in certain
>>>>>>> images or profiles (like the JDK but not the JRE) we would need to
>>>>>>> produce class files of both kinds at some point in the build. This
>>>>>>> could be accomplished either by compiling everything twice or by
>>>>>>> stripping out the information at some point.
>>>>>>>
>>>>>>> If the case is just to have different defaults between embedded and
>>>>>>> normal, it should be rather straight forward to add a configure
>>>>>>> argument that adds to the JAVAC_FLAGS variable. I would suggest
>>>>>>> adding this somewhere in common/autoconf/toolchain.m4. If you just
>>>>>>> want to see the effects of adding this parameter on a single build,
>>>>>>> running "make JAVAC_FLAGS=-parameter" should do the trick.
>>>>>>>
>>>>>>> /Erik
>>>>>>>
>>>>>>> On 2012-11-14 07:13, David Holmes wrote:
>>>>>>>> Alan is correct. A configuration is a selection of a range of 
>>>>>>>> things
>>>>>>>> including platform, JDK variant (normal or embedded), JVM variant
>>>>>>>> (client, server, minimal), "release" (product or fastdebug). When
>>>>>>>> you do a build the classes only get compiled once regardless of
>>>>>>>> which jar they end up in, or which image the jar ends up in. So 
>>>>>>>> this
>>>>>>>> javac option will be applied to all classes and hence to all build
>>>>>>>> artifacts.
>>>>>>>>
>>>>>>>> None of which forces the selection of this being a configure time
>>>>>>>> option versus a "make" time option. The main issue with the latter
>>>>>>>> is that it makes it easier to produce inconsistent build 
>>>>>>>> results if
>>>>>>>> you do partial builds and change the value of the option each 
>>>>>>>> time.
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 14/11/2012 7:45 AM, Alan Bateman wrote:
>>>>>>>>> On 13/11/2012 20:50, Alex Buckley wrote:
>>>>>>>>>> The primary reason for storing parameter names in JDK8 class
>>>>>>>>>> files is
>>>>>>>>>> to help IDE vendors, so it's fine if only the JDK image has
>>>>>>>>>> them. We
>>>>>>>>>> are not making a general promise that any program will be 
>>>>>>>>>> able to
>>>>>>>>>> find
>>>>>>>>>> parameter names of core Java Java SE classes at runtime. (Again,
>>>>>>>>>> please set aside concerns about footprint, compatibility, etc on
>>>>>>>>>> this
>>>>>>>>>> list.)
>>>>>>>>>>
>>>>>>>>>> It sounds like a ./configure option of --enable-parameters could
>>>>>>>>>> add
>>>>>>>>>> an option to JAVAC_FLAGS - you say it would affect all 
>>>>>>>>>> images? But
>>>>>>>>>> Erik said "the value of the option has different defaults
>>>>>>>>>> depending on
>>>>>>>>>> jdk variant/profile".
>>>>>>>>> Suppose we do "configure --enable-paramater-names && make" then
>>>>>>>>> this
>>>>>>>>> would compile the classes and native libraries but at this 
>>>>>>>>> point we
>>>>>>>>> don't have any images, rather it's just raw classes on the file
>>>>>>>>> system
>>>>>>>>> (no rt.jar).
>>>>>>>>>
>>>>>>>>> A subsequent "make images" would create the j2sdk-image and
>>>>>>>>> j2re-image
>>>>>>>>> with the rt.jar and the layout that we are used to. I think, and
>>>>>>>>> Erik or
>>>>>>>>> David can correct me, is that the same class files end up in both
>>>>>>>>> images. Subsequent stripping of debug attributes from 
>>>>>>>>> everything in
>>>>>>>>> rt.jar may happen later, at least where JRE download size is
>>>>>>>>> important.
>>>>>>>>>
>>>>>>>>> So my point about the parameter names is that the same classes 
>>>>>>>>> are
>>>>>>>>> used
>>>>>>>>> for all images. The "profiles" build is like "images", it's 
>>>>>>>>> really
>>>>>>>>> just
>>>>>>>>> packaging up the already compiled bits and so would get the same
>>>>>>>>> class
>>>>>>>>> files, assuming of course that the JDK/JRE images and profiles
>>>>>>>>> images
>>>>>>>>> are coming from the same build.
>>>>>>>>>
>>>>>>>>> When Erik used the term "variant" then I assume he meant the
>>>>>>>>> --with-jdk-variant and --with-jvm-variant options to configure
>>>>>>>>> normal or
>>>>>>>>> embedded, client or server VM and things like that. That's part
>>>>>>>>> of the
>>>>>>>>> configuration. If we are compiling classes differently then I
>>>>>>>>> suspect it
>>>>>>>>> may require a separate configuration.
>>>>>>>>>
>>>>>>>>>> Where should we look at the new build, given that the parameter
>>>>>>>>>> feature lives in the jdk8/tl forest?
>>>>>>>>> common/makefiles in the top-level repo, and makefiles 
>>>>>>>>> directory in
>>>>>>>>> each
>>>>>>>>> of the other repos. Alternatively this guide:
>>>>>>>>>
>>>>>>>>> http://openjdk.java.net/projects/build-infra/guide.html
>>>>>>>>>
>>>>>>>>> -Alan.
>>>>>
>>>



From david.holmes at oracle.com  Wed Nov 14 22:11:52 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 15 Nov 2012 16:11:52 +1000
Subject: Building with a new javac flag
In-Reply-To: <50A47A3A.7000706@oracle.com>
References: <50A16F70.5050107@oracle.com>
	<50A190C4.2070105@oracle.com>	<50A2366D.9000508@oracle.com>
	<50A2B290.7040504@oracle.com>	<50A2BF71.80504@oracle.com>
	<50A3369D.5090403@oracle.com> <50A367D6.40209@oracle.com>
	<308159CD-23A3-4ED6-A293-0E40D8DE9ABF@oracle.com>
	<50A3E133.4030906@oracle.com> <50A3F267.6010901@oracle.com>
	<50A3F355.9010200@oracle.com> <50A3FA1C.4080402@oracle.com>
	<50A479AF.3060005@oracle.com> <50A47A3A.7000706@oracle.com>
Message-ID: <50A487A8.4070200@oracle.com>

On 15/11/2012 3:14 PM, Jonathan Gibbons wrote:
> I believe the plan would be to use pack200 to strip the attribute.

I don't know exactly what that means. Does it strip the attribute out of 
the existing class file, or does it create a copy without the attribute 
in it? Either way it means we need two copies of the .class files. If it 
could be stripped as part of the jarring process we'd only need a 
temporary copy of each file. There is about 160MB of .class files in a 
build.

David

> -- Jon
>
> On 11/14/2012 09:12 PM, David Holmes wrote:
>> On 15/11/2012 6:07 AM, Alex Buckley wrote:
>>> Yes. We want parameters when jdk-variant=normal, so we'll include
>>> -parameters in the JAVAC_FLAGS for that configure option/value combo.
>>> Then the make targets for 'images' and 'profiles' will invoke pack200 to
>>> strip the parameter attributes except for the j2sdk-image.
>>
>> In that case we don't need any new configure options as this approach
>> also works for embedded as it doesn't care about the full JDK.
>>
>> Though we might want to conditionalize this on whether OPENJDK is true
>> or not. There are some concerns about Oracle JDK build requirements
>> being applied by default to OpenJDK builds.
>>
>> Also how does the stripping work - does it mean that we will have to
>> copy all the .class files first, or can it be applied when creating
>> the jar files?
>>
>> David
>>
>>> Eric McCorkle will have a javac capable of emitting the attribute this
>>> week, so we'll try it out on his local forest.
>>>
>>> Alex
>>>
>>> On 11/14/2012 11:39 AM, Jonathan Gibbons wrote:
>>>> OK, but it still sounds like the policy of when to include the
>>>> parameters can be determined without requiring extra configuration
>>>> parameters.
>>>>
>>>> (Which is separate from whether we should have parameters to override
>>>> the default determination.)
>>>>
>>>> -- Jon
>>>>
>>>>
>>>> On 11/14/2012 11:35 AM, Alex Buckley wrote:
>>>>> It sounds like the jdk-variant option would perfectly dominate the
>>>>> enable-parameters option, if we wanted parameters in the normal
>>>>> variant's JDK image and the normal variant's JRE image and the normal
>>>>> variant's Compact Profiles image.
>>>>>
>>>>> But we would like parameters in only the normal variant's JDK image,
>>>>> not the other images, because IDEs only run on the biggest fattest
>>>>> JDK.
>>>>>
>>>>> Alex
>>>>>
>>>>> On 11/14/2012 10:21 AM, Jonathan Gibbons wrote:
>>>>>> If we already have a configure option for "JDK variant (normal or
>>>>>> embedded)", why do we need any additional options for parameter
>>>>>> names,
>>>>>> if the decision whether or not to use parameter names is a
>>>>>> function of
>>>>>> the variant?
>>>>>>
>>>>>> -- Jon
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 11/14/2012 09:09 AM, Kelly O'Hair wrote:
>>>>>>> Seems like if we want this information a permanent aspect of certain
>>>>>>> builds, it needs a configure argument means of doing it.
>>>>>>>
>>>>>>> That doesn't prevent the use of JAVAC_FLAGS for this or other
>>>>>>> things.
>>>>>>>
>>>>>>> ---
>>>>>>> I'm getting concerned that we end up with too many variations here,
>>>>>>> for the typical developers they need simple
>>>>>>> ways to get the standard configurations.
>>>>>>>
>>>>>>> -kto
>>>>>>>
>>>>>>> On Nov 14, 2012, at 1:43 AM, Erik Joelsson wrote:
>>>>>>>
>>>>>>>> Alan and David are correct regarding how the build currently works.
>>>>>>>> To support the case of only providing this information in certain
>>>>>>>> images or profiles (like the JDK but not the JRE) we would need to
>>>>>>>> produce class files of both kinds at some point in the build. This
>>>>>>>> could be accomplished either by compiling everything twice or by
>>>>>>>> stripping out the information at some point.
>>>>>>>>
>>>>>>>> If the case is just to have different defaults between embedded and
>>>>>>>> normal, it should be rather straight forward to add a configure
>>>>>>>> argument that adds to the JAVAC_FLAGS variable. I would suggest
>>>>>>>> adding this somewhere in common/autoconf/toolchain.m4. If you just
>>>>>>>> want to see the effects of adding this parameter on a single build,
>>>>>>>> running "make JAVAC_FLAGS=-parameter" should do the trick.
>>>>>>>>
>>>>>>>> /Erik
>>>>>>>>
>>>>>>>> On 2012-11-14 07:13, David Holmes wrote:
>>>>>>>>> Alan is correct. A configuration is a selection of a range of
>>>>>>>>> things
>>>>>>>>> including platform, JDK variant (normal or embedded), JVM variant
>>>>>>>>> (client, server, minimal), "release" (product or fastdebug). When
>>>>>>>>> you do a build the classes only get compiled once regardless of
>>>>>>>>> which jar they end up in, or which image the jar ends up in. So
>>>>>>>>> this
>>>>>>>>> javac option will be applied to all classes and hence to all build
>>>>>>>>> artifacts.
>>>>>>>>>
>>>>>>>>> None of which forces the selection of this being a configure time
>>>>>>>>> option versus a "make" time option. The main issue with the latter
>>>>>>>>> is that it makes it easier to produce inconsistent build
>>>>>>>>> results if
>>>>>>>>> you do partial builds and change the value of the option each
>>>>>>>>> time.
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>> On 14/11/2012 7:45 AM, Alan Bateman wrote:
>>>>>>>>>> On 13/11/2012 20:50, Alex Buckley wrote:
>>>>>>>>>>> The primary reason for storing parameter names in JDK8 class
>>>>>>>>>>> files is
>>>>>>>>>>> to help IDE vendors, so it's fine if only the JDK image has
>>>>>>>>>>> them. We
>>>>>>>>>>> are not making a general promise that any program will be
>>>>>>>>>>> able to
>>>>>>>>>>> find
>>>>>>>>>>> parameter names of core Java Java SE classes at runtime. (Again,
>>>>>>>>>>> please set aside concerns about footprint, compatibility, etc on
>>>>>>>>>>> this
>>>>>>>>>>> list.)
>>>>>>>>>>>
>>>>>>>>>>> It sounds like a ./configure option of --enable-parameters could
>>>>>>>>>>> add
>>>>>>>>>>> an option to JAVAC_FLAGS - you say it would affect all
>>>>>>>>>>> images? But
>>>>>>>>>>> Erik said "the value of the option has different defaults
>>>>>>>>>>> depending on
>>>>>>>>>>> jdk variant/profile".
>>>>>>>>>> Suppose we do "configure --enable-paramater-names && make" then
>>>>>>>>>> this
>>>>>>>>>> would compile the classes and native libraries but at this
>>>>>>>>>> point we
>>>>>>>>>> don't have any images, rather it's just raw classes on the file
>>>>>>>>>> system
>>>>>>>>>> (no rt.jar).
>>>>>>>>>>
>>>>>>>>>> A subsequent "make images" would create the j2sdk-image and
>>>>>>>>>> j2re-image
>>>>>>>>>> with the rt.jar and the layout that we are used to. I think, and
>>>>>>>>>> Erik or
>>>>>>>>>> David can correct me, is that the same class files end up in both
>>>>>>>>>> images. Subsequent stripping of debug attributes from
>>>>>>>>>> everything in
>>>>>>>>>> rt.jar may happen later, at least where JRE download size is
>>>>>>>>>> important.
>>>>>>>>>>
>>>>>>>>>> So my point about the parameter names is that the same classes
>>>>>>>>>> are
>>>>>>>>>> used
>>>>>>>>>> for all images. The "profiles" build is like "images", it's
>>>>>>>>>> really
>>>>>>>>>> just
>>>>>>>>>> packaging up the already compiled bits and so would get the same
>>>>>>>>>> class
>>>>>>>>>> files, assuming of course that the JDK/JRE images and profiles
>>>>>>>>>> images
>>>>>>>>>> are coming from the same build.
>>>>>>>>>>
>>>>>>>>>> When Erik used the term "variant" then I assume he meant the
>>>>>>>>>> --with-jdk-variant and --with-jvm-variant options to configure
>>>>>>>>>> normal or
>>>>>>>>>> embedded, client or server VM and things like that. That's part
>>>>>>>>>> of the
>>>>>>>>>> configuration. If we are compiling classes differently then I
>>>>>>>>>> suspect it
>>>>>>>>>> may require a separate configuration.
>>>>>>>>>>
>>>>>>>>>>> Where should we look at the new build, given that the parameter
>>>>>>>>>>> feature lives in the jdk8/tl forest?
>>>>>>>>>> common/makefiles in the top-level repo, and makefiles
>>>>>>>>>> directory in
>>>>>>>>>> each
>>>>>>>>>> of the other repos. Alternatively this guide:
>>>>>>>>>>
>>>>>>>>>> http://openjdk.java.net/projects/build-infra/guide.html
>>>>>>>>>>
>>>>>>>>>> -Alan.
>>>>>>
>>>>
>


From Alan.Bateman at oracle.com  Thu Nov 15 01:42:24 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 15 Nov 2012 09:42:24 +0000
Subject: cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
	error in build-infra build ('old' build works OK)
In-Reply-To: <50A47734.2010602@oracle.com>
References: <CAP7YuAT+X+BfcsFm=tZk3orEHyFh=_eK07B1KUPmJ106CnREyw@mail.gmail.com>
	<50A02E86.6080002@oracle.com> <50A41541.7020606@oracle.com>
	<ADEF6951-8294-4C7E-A326-B62389AB7014@oracle.com>
	<50A47734.2010602@oracle.com>
Message-ID: <50A4B900.9070706@oracle.com>

On 15/11/2012 05:01, Phil Race wrote:
> On 11/14/12 3:23 PM, Kelly O'Hair wrote:
>> On Nov 14, 2012, at 2:03 PM, Phil Race wrote:
>>
>>> Ah .. I guess we (2d) broke that when we added the new file from 
>>> LCMS 2.4 to
>>> FILES_c_unix.gmk but had no clue this other new top-level file existed.
>>> Kelly said get Makefile changes reviewed but didn't mention file lists.
>> I stated that anything in the make/ directories needed to be run by us.
>
> Can I quote what you said .. its not quite so clear :-
I don't think it's worth spending time on this, instead we just need to 
get the message out again that we have to live with two build systems 
for a transitional period and that it's easy to break the one that you 
aren't using.

Some people that push to jdk8/tl are using the old build system, some 
are using the new build system. The latter group have had their builds 
broken several times recently, almost always after changes from master 
were pulled down to jdk8/tl. There have been one or two local breakages 
too but they are easy to fix quickly, it's the changes from distant 
planets (jdk8/awt and jdk8/2d in particular) that hurt as the lag to get 
the fixes through is just too long.

Lana Steuck does most of the integrations and sync up of the jdk8 
forests, she's going to do sanity builds with the new build prior to 
integrating, and I think perhaps prior to pulling too, so that should at 
least reduce the instances of breakage until the transition is done and 
the old build is 5 foot under.

-Alan


From martijnverburg at gmail.com  Thu Nov 15 01:47:28 2012
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Thu, 15 Nov 2012 09:47:28 +0000
Subject: cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
	error in build-infra build ('old' build works OK)
In-Reply-To: <50A4B900.9070706@oracle.com>
References: <CAP7YuAT+X+BfcsFm=tZk3orEHyFh=_eK07B1KUPmJ106CnREyw@mail.gmail.com>
	<50A02E86.6080002@oracle.com> <50A41541.7020606@oracle.com>
	<ADEF6951-8294-4C7E-A326-B62389AB7014@oracle.com>
	<50A47734.2010602@oracle.com> <50A4B900.9070706@oracle.com>
Message-ID: <CAP7YuATFLw8UHHzdB0v1sG3eua3-iM08Adx+hLOpJQr7k2EtxA@mail.gmail.com>

Hi Alan,

The sanity checking step is good to hear. We had a bit of an informal BOF
here at Devoxx about it after some labs using build-infra ran into these
types of build issues.

So thanks Lana for running these going forwards!

Cheers,
Martijn

On Thursday, 15 November 2012, Alan Bateman wrote:

> On 15/11/2012 05:01, Phil Race wrote:
>
>> On 11/14/12 3:23 PM, Kelly O'Hair wrote:
>>
>>> On Nov 14, 2012, at 2:03 PM, Phil Race wrote:
>>>
>>>  Ah .. I guess we (2d) broke that when we added the new file from LCMS
>>>> 2.4 to
>>>> FILES_c_unix.gmk but had no clue this other new top-level file existed.
>>>> Kelly said get Makefile changes reviewed but didn't mention file lists.
>>>>
>>> I stated that anything in the make/ directories needed to be run by us.
>>>
>>
>> Can I quote what you said .. its not quite so clear :-
>>
> I don't think it's worth spending time on this, instead we just need to
> get the message out again that we have to live with two build systems for a
> transitional period and that it's easy to break the one that you aren't
> using.
>
> Some people that push to jdk8/tl are using the old build system, some are
> using the new build system. The latter group have had their builds broken
> several times recently, almost always after changes from master were pulled
> down to jdk8/tl. There have been one or two local breakages too but they
> are easy to fix quickly, it's the changes from distant planets (jdk8/awt
> and jdk8/2d in particular) that hurt as the lag to get the fixes through is
> just too long.
>
> Lana Steuck does most of the integrations and sync up of the jdk8 forests,
> she's going to do sanity builds with the new build prior to integrating,
> and I think perhaps prior to pulling too, so that should at least reduce
> the instances of breakage until the transition is done and the old build is
> 5 foot under.
>
> -Alan
>


From Alan.Bateman at oracle.com  Thu Nov 15 02:14:27 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 15 Nov 2012 10:14:27 +0000
Subject: Building with a new javac flag
In-Reply-To: <50A3F267.6010901@oracle.com>
References: <50A16F70.5050107@oracle.com>
	<50A190C4.2070105@oracle.com>	<50A2366D.9000508@oracle.com>
	<50A2B290.7040504@oracle.com>	<50A2BF71.80504@oracle.com>
	<50A3369D.5090403@oracle.com> <50A367D6.40209@oracle.com>
	<308159CD-23A3-4ED6-A293-0E40D8DE9ABF@oracle.com>
	<50A3E133.4030906@oracle.com> <50A3F267.6010901@oracle.com>
Message-ID: <50A4C083.6010202@oracle.com>

On 14/11/2012 19:35, Alex Buckley wrote:
> :
>
> But we would like parameters in only the normal variant's JDK image, 
> not the other images, because IDEs only run on the biggest fattest JDK.
This probably lends weight to the proposal to enhance javac with an 
option to specify the intended target profile too.

-Alan


From oehrstroem at gmail.com  Thu Nov 15 02:15:20 2012
From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=)
Date: Thu, 15 Nov 2012 11:15:20 +0100
Subject: cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
	error in build-infra build ('old' build works OK)
In-Reply-To: <50A41541.7020606@oracle.com>
References: <CAP7YuAT+X+BfcsFm=tZk3orEHyFh=_eK07B1KUPmJ106CnREyw@mail.gmail.com>
	<50A02E86.6080002@oracle.com> <50A41541.7020606@oracle.com>
Message-ID: <CALZT+jBmP8_DR=enW0uSuyP5ywfC5yqcdWvuSMEqirYjZha+bQ@mail.gmail.com>

Den onsdagen den 14:e november 2012 skrev Phil Race:
>
> So in the new build system is *everything* centralised like this?
> Monolithic files rather than including area specific ones ?
> I'm not sure what the supposed advantage might be?
>
> Normally in the new build system, adding new source files do not require
changing
the makefile. This particular library has its sources mixed up with
something else
in the same source directory, thus the need to list source files explicitly.

perha
 It should be easy to fix I suppose..... and generally a goodthing. :-)

//Fredrik

-phil.
>
> On 11/11/12 3:02 PM, David Holmes wrote:
>
>> Hi Martijn,
>>
>> Known issue fixed a couple of days ago:
>>
>> http://hg.openjdk.java.net/**build-infra/jdk8/jdk/rev/**1e79fec4a01f<http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/1e79fec4a01f>
>>
>> David
>>
>> On 12/11/2012 8:45 AM, Martijn Verburg wrote:
>>
>>> Hi all,
>>>
>>> Building jdk8_tl on Ubuntu 12.04 with OpenJDK Runtime Environment
>>> (IcedTea7
>>> 2.3.3) (7u9-2.3.3-0ubuntu1~12.04.1)
>>> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode). I get the
>>> following
>>> compilation error using build-infra (but not the 'old' build).
>>>
>>> /home/openjdk/sources/jdk8_tl/**build/linux-x86_64-normal-**
>>> server-release/jdk/objs/**liblcms/cmspack.o:
>>> In function `UnrollHalfToFloat':
>>> cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
>>> cmspack.c:(.text+0x27c6): undefined reference to `_cmsHalf2Float'
>>> /home/openjdk/sources/jdk8_tl/**build/linux-x86_64-normal-**
>>> server-release/jdk/objs/**liblcms/cmspack.o:
>>> In function `UnrollHalfTo16':
>>> cmspack.c:(.text+0x2953): undefined reference to `_cmsHalf2Float'
>>> cmspack.c:(.text+0x29fa): undefined reference to `_cmsHalf2Float'
>>> /home/openjdk/sources/jdk8_tl/**build/linux-x86_64-normal-**
>>> server-release/jdk/objs/**liblcms/cmspack.o:
>>> In function `PackHalfFromFloat':
>>> cmspack.c:(.text+0x2baf): undefined reference to `_cmsFloat2Half'
>>> cmspack.c:(.text+0x2c10): undefined reference to `_cmsFloat2Half'
>>> cmspack.c:(.text+0x2ccb): undefined reference to `_cmsFloat2Half'
>>> /home/openjdk/sources/jdk8_tl/**build/linux-x86_64-normal-**
>>> server-release/jdk/objs/**liblcms/cmspack.o:
>>> In function `PackHalfFrom16':
>>> cmspack.c:(.text+0x2de7): undefined reference to `_cmsFloat2Half'
>>> cmspack.c:(.text+0x2e4d): undefined reference to `_cmsFloat2Half'
>>> /home/openjdk/sources/jdk8_tl/**build/linux-x86_64-normal-**
>>> server-release/jdk/objs/**liblcms/cmspack.o:cmspack.c:(.**text+0x2f01):
>>> more undefined references to `_cmsFloat2Half' follow
>>> collect2: ld returned 1 exit status
>>> make[2]: ***
>>> [/home/openjdk/sources/jdk8_**tl/build/linux-x86_64-normal-**
>>> server-release/jdk/lib/amd64/**liblcms.so]
>>> Error 1
>>> make[1]: *** [libs-only] Error 2
>>> make: *** [jdk-only] Error 2
>>>
>>> Haven't tracked it down any further than this yet, but thought I should
>>> report it in :-).
>>>
>>> Cheers,
>>> Martijn
>>>
>>
>


From erik.joelsson at oracle.com  Thu Nov 15 03:00:44 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 15 Nov 2012 11:00:44 +0000
Subject: hg: build-infra/jdk8: 12 new changesets
Message-ID: <20121115110046.A204C479A3@hg.openjdk.java.net>

Changeset: 78bb27faf889
Author:    tbell
Date:      2012-11-12 12:34 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/78bb27faf889

8002028: build-infra: need no-hotspot partial build
Summary: Added configure option --with-import-hotspot=/path/to/j2sdkimage
Reviewed-by: dholmes, tbell
Contributed-by: erik.joelsson at oracle.com

! common/autoconf/generated-configure.sh
! common/autoconf/source-dirs.m4
! common/autoconf/spec.gmk.in
! common/makefiles/Main.gmk

Changeset: f2ac4d0edaae
Author:    tbell
Date:      2012-11-13 15:54 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/f2ac4d0edaae

8003274: build-infra: Makefile changes needed for sjavac
Summary: changes left in build-infra that are related to sjavac
Reviewed-by: ohair, tbell
Contributed-by: erik.joelsson at oracle.com, fredrik.ohrstrom at oracle.com

! common/autoconf/spec.gmk.in
! common/makefiles/JavaCompilation.gmk
! common/makefiles/MakeHelpers.gmk

Changeset: 838a64965131
Author:    katleman
Date:      2012-11-08 11:50 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/838a64965131

Added tag jdk8-b64 for changeset 1c8370a55b30

! .hgtags

Changeset: b772de306dc2
Author:    katleman
Date:      2012-11-14 12:28 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/b772de306dc2

Merge


Changeset: a2df4ee40ecb
Author:    tbell
Date:      2012-11-14 10:05 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/a2df4ee40ecb

8002026: build-infra: deploy repository building
Summary: Change the compare script to handle deploy build artifacts.
Reviewed-by: ohair, tbell
Contributed-by: erik.joelsson at oracle.com

! common/bin/compare.sh
! common/bin/compare_exceptions.sh.incl

Changeset: c81c4a5d8b50
Author:    tbell
Date:      2012-11-14 10:13 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/c81c4a5d8b50

8001875: build-infra: We must be able to force static linking of stdc++
Summary: Ensure that we build with static linking when requested, or do not build at all
Reviewed-by: ohair, tbell
Contributed-by: erik.joelsson at oracle.com

! common/autoconf/generated-configure.sh
! common/autoconf/libraries.m4

Changeset: 582c696033f5
Author:    tbell
Date:      2012-11-14 10:16 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/582c696033f5

8001941: build-infra: --disable-precompiled-headers does not seem to work
Summary: With this fix the flag will do what it advertises
Reviewed-by: ohair, tbell
Contributed-by: erik.joelsson at oracle.com

! common/autoconf/build-performance.m4
! common/autoconf/generated-configure.sh
! common/autoconf/hotspot-spec.gmk.in

Changeset: f59a07f85125
Author:    tbell
Date:      2012-11-14 10:18 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/f59a07f85125

8003317: build-infra: Configure fails when current dir is part of a symlink
Summary: Call macro for removing symbolic links on a copy of the CURDIR variable before comparing
Reviewed-by: ohair, tbell
Contributed-by: erik.joelsson at oracle.com

! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh

Changeset: e69396d6d3e8
Author:    tbell
Date:      2012-11-14 10:20 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/e69396d6d3e8

8003327: build-infra: "/bin/sh: : cannot execute" on solaris
Summary: Fix quoting inside cut command used in the pipeline
Reviewed-by: ohair, tbell
Contributed-by: erik.joelsson at oracle.com

! common/makefiles/MakeHelpers.gmk

Changeset: 06f146c05f49
Author:    tbell
Date:      2012-11-15 00:54 +0000
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/06f146c05f49

Merge


Changeset: 21854e79761d
Author:    erikj
Date:      2012-11-15 11:31 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/21854e79761d

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/source-dirs.m4
! common/autoconf/spec.gmk.in
! common/makefiles/JavaCompilation.gmk
! common/makefiles/Main.gmk
! common/makefiles/MakeHelpers.gmk

Changeset: 56590a67aed2
Author:    erikj
Date:      2012-11-15 11:34 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/56590a67aed2

Merge

! common/autoconf/basics.m4
! common/autoconf/build-performance.m4
! common/autoconf/generated-configure.sh
! common/autoconf/hotspot-spec.gmk.in
! common/autoconf/libraries.m4
! common/bin/compare.sh
! common/bin/compare_exceptions.sh.incl
! common/makefiles/MakeHelpers.gmk



From erik.joelsson at oracle.com  Thu Nov 15 03:00:44 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 15 Nov 2012 11:00:44 +0000
Subject: hg: build-infra/jdk8/corba: 2 new changesets
Message-ID: <20121115110049.5D529479A4@hg.openjdk.java.net>

Changeset: 5132f7900a8f
Author:    katleman
Date:      2012-11-08 11:50 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/corba/rev/5132f7900a8f

Added tag jdk8-b64 for changeset 54d599a5b4aa

! .hgtags

Changeset: d8674b338986
Author:    erikj
Date:      2012-11-15 11:33 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/corba/rev/d8674b338986

Merge




From erik.joelsson at oracle.com  Thu Nov 15 03:00:44 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 15 Nov 2012 11:00:44 +0000
Subject: hg: build-infra/jdk8/jaxws: 2 new changesets
Message-ID: <20121115110055.70D7F479A5@hg.openjdk.java.net>

Changeset: fbe54291c9d3
Author:    katleman
Date:      2012-11-08 11:51 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jaxws/rev/fbe54291c9d3

Added tag jdk8-b64 for changeset 5ded18a14bcc

! .hgtags

Changeset: ab123b7ef6b0
Author:    erikj
Date:      2012-11-15 11:33 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jaxws/rev/ab123b7ef6b0

Merge




From erik.joelsson at oracle.com  Thu Nov 15 03:00:44 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 15 Nov 2012 11:00:44 +0000
Subject: hg: build-infra/jdk8/jaxp: 2 new changesets
Message-ID: <20121115110059.D5349479A6@hg.openjdk.java.net>

Changeset: 5cf3c69a93d6
Author:    katleman
Date:      2012-11-08 11:51 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jaxp/rev/5cf3c69a93d6

Added tag jdk8-b64 for changeset 27ab79568c34

! .hgtags

Changeset: b0cbebd099f2
Author:    erikj
Date:      2012-11-15 11:33 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jaxp/rev/b0cbebd099f2

Merge




From erik.joelsson at oracle.com  Thu Nov 15 03:00:44 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 15 Nov 2012 11:00:44 +0000
Subject: hg: build-infra/jdk8/hotspot: 19 new changesets
Message-ID: <20121115110134.6A6EE479A7@hg.openjdk.java.net>

Changeset: 49bc14aaadcc
Author:    katleman
Date:      2012-11-08 11:51 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/49bc14aaadcc

Added tag jdk8-b64 for changeset 5920f72e799c

! .hgtags

Changeset: ca8168203393
Author:    amurillo
Date:      2012-11-02 07:44 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/ca8168203393

8002181: new hotspot build - hs25-b09
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 857f3ce858dd
Author:    dholmes
Date:      2012-11-05 19:33 -0500
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/857f3ce858dd

8002034: Allow Full Debug Symbols when cross-compiling
8001756: Hotspot makefiles report missing OBJCOPY command in the wrong circumstances
Reviewed-by: dcubed, dsamersoff, erikj, collins

! make/linux/makefiles/defs.make
! make/linux/makefiles/vm.make
! make/solaris/makefiles/defs.make
! make/windows/makefiles/defs.make

Changeset: 3d701c802d01
Author:    minqi
Date:      2012-11-02 13:30 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/3d701c802d01

8000489: older builds of hsdis don't work anymore after 6879063
Summary: The old function not defined properly, need a definition for export in dll. Also changes made to let new jvm work with old hsdis.
Reviewed-by: jrose, sspitsyn, kmo
Contributed-by: yumin.qi at oracle.com

! src/share/tools/hsdis/hsdis-demo.c
! src/share/tools/hsdis/hsdis.c
! src/share/tools/hsdis/hsdis.h
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/compiler/disassembler.hpp

Changeset: 4735d2c84362
Author:    kamg
Date:      2012-10-11 12:25 -0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/4735d2c84362

7200776: Implement default methods in interfaces
Summary: Add generic type analysis and default method selection algorithms
Reviewed-by: coleenp, acorn

+ src/share/vm/classfile/bytecodeAssembler.cpp
+ src/share/vm/classfile/bytecodeAssembler.hpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
+ src/share/vm/classfile/defaultMethods.cpp
+ src/share/vm/classfile/defaultMethods.hpp
+ src/share/vm/classfile/genericSignatures.cpp
+ src/share/vm/classfile/genericSignatures.hpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/verifier.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/code/dependencies.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/oops/constMethod.cpp
! src/share/vm/oops/constMethod.hpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/klassVtable.cpp
! src/share/vm/oops/klassVtable.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/reflection.cpp
! src/share/vm/utilities/growableArray.hpp
+ src/share/vm/utilities/pair.hpp
+ src/share/vm/utilities/resourceHash.hpp

Changeset: ec204374e626
Author:    kamg
Date:      2012-11-02 16:09 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/ec204374e626

Merge

! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/runtime/globals.hpp
- test/runtime/7158800/BadUtf8.java
- test/runtime/7158800/InternTest.java
- test/runtime/7158800/Test7158800.sh
- test/runtime/7158800/badstrings.txt

Changeset: 9cc901118f6b
Author:    kamg
Date:      2012-11-02 17:18 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/9cc901118f6b

Merge


Changeset: 69ad7823b1ca
Author:    zgu
Date:      2012-11-05 15:30 -0500
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/69ad7823b1ca

8001591: NMT: assertion failed: assert(rec->addr() + rec->size() <= cur->base()) failed: Can not overlap in memSnapshot.cpp
Summary: NMT should allow overlapping committed regions as long as they belong to the same reserved region
Reviewed-by: dholmes, coleenp

! src/share/vm/services/memPtr.hpp
! src/share/vm/services/memSnapshot.cpp

Changeset: 8940ddc1036f
Author:    zgu
Date:      2012-11-05 13:55 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/8940ddc1036f

Merge

- test/runtime/7158800/BadUtf8.java
- test/runtime/7158800/InternTest.java
- test/runtime/7158800/Test7158800.sh
- test/runtime/7158800/badstrings.txt

Changeset: c284cf4781f0
Author:    rbackman
Date:      2012-10-04 14:55 +0200
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/c284cf4781f0

7127792: Add the ability to change an existing PeriodicTask's execution interval
Summary: Enables dynamic enrollment / disenrollment from the PeriodicTasks in WatcherThread.
Reviewed-by: dholmes, mgronlun

! src/share/vm/runtime/mutexLocker.cpp
! src/share/vm/runtime/mutexLocker.hpp
! src/share/vm/runtime/task.cpp
! src/share/vm/runtime/task.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp

Changeset: 18fb7da42534
Author:    coleenp
Date:      2012-11-06 15:09 -0500
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/18fb7da42534

8000725: NPG: method_holder() and pool_holder() and pool_holder field should be InstanceKlass
Summary: Change types of above methods and field to InstanceKlass and remove unneeded casts from the source files.
Reviewed-by: dholmes, coleenp, zgu
Contributed-by: harold.seigel at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/verifier.cpp
! src/share/vm/classfile/vmSymbols.cpp
! src/share/vm/code/compiledIC.cpp
! src/share/vm/code/dependencies.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/oops/constMethod.cpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp
! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/klassVtable.cpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvmtiClassFileReconstituter.cpp
! src/share/vm/prims/jvmtiEnv.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/nativeLookup.cpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/fieldDescriptor.cpp
! src/share/vm/runtime/fieldDescriptor.hpp
! src/share/vm/runtime/javaCalls.cpp
! src/share/vm/runtime/reflection.cpp
! src/share/vm/runtime/vframe.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/services/heapDumper.cpp

Changeset: ead8852dd4ef
Author:    coleenp
Date:      2012-11-07 16:09 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/ead8852dd4ef

Merge


Changeset: 64672b22ef05
Author:    twisti
Date:      2012-11-02 12:30 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/64672b22ef05

8001658: No need to pass resolved_references as argument to ConstantPoolCacheEntry::set_method_handle_common
Reviewed-by: twisti
Contributed-by: Bharadwaj Yadavalli <bharadwaj.yadavalli at oracle.com>

! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/cpCache.hpp

Changeset: dbeaeee28bc2
Author:    kvn
Date:      2012-11-06 09:22 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/dbeaeee28bc2

8002294: assert(VM_Version::supports_ssse3()) failed
Summary: Add missing UseSSE check for AES intrinsics.
Reviewed-by: roland, twisti

! src/cpu/x86/vm/vm_version_x86.cpp

Changeset: f3da5ff1514c
Author:    kvn
Date:      2012-11-06 15:16 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/f3da5ff1514c

8002069: Assert failed in C2: assert(field->edge_count() > 0) failed: sanity
Summary: Added missed type check of initializing store in ConnectionGraph::find_init_values().
Reviewed-by: roland, twisti, vlivanov

! src/share/vm/opto/escape.cpp
+ test/compiler/8002069/Test8002069.java

Changeset: a4e1bd941ded
Author:    neliasso
Date:      2012-11-08 22:39 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/a4e1bd941ded

Merge

! src/share/vm/oops/cpCache.cpp

Changeset: b4ee7b773144
Author:    amurillo
Date:      2012-11-09 08:20 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/b4ee7b773144

Merge


Changeset: 0f7290a03b24
Author:    amurillo
Date:      2012-11-09 08:20 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/0f7290a03b24

Added tag hs25-b09 for changeset b4ee7b773144

! .hgtags

Changeset: a691f4465054
Author:    erikj
Date:      2012-11-15 11:33 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/a691f4465054

Merge

! make/linux/makefiles/defs.make
! make/linux/makefiles/vm.make
! make/solaris/makefiles/defs.make
! make/windows/makefiles/defs.make



From erik.joelsson at oracle.com  Thu Nov 15 03:00:44 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 15 Nov 2012 11:00:44 +0000
Subject: hg: build-infra/jdk8/jdk: 33 new changesets
Message-ID: <20121115110749.920DC479A8@hg.openjdk.java.net>

Changeset: 170e8ccfbc4f
Author:    tbell
Date:      2012-11-12 10:20 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/170e8ccfbc4f

8002365: build-infra: Build-infra fails on solaris 11.1 on sparc.
Summary: Add '-lc' to LDFLAGS for native libraries in CompileNativeLibraries.gmk
Reviewed-by: ohair, tbell
Contributed-by: erik.joelsson at oracle.com

! makefiles/CompileNativeLibraries.gmk

Changeset: 2fc142843a93
Author:    tbell
Date:      2012-11-12 10:49 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/2fc142843a93

8003177: build-infra: Compare reports diff in LocaleDataMetaInfo.class
Summary: Remove spurious space in the locale lists
Reviewed-by: naoto, ohair, tbell
Contributed-by: erik.joelsson at oracle.com

! makefiles/GensrcLocaleDataMetaInfo.gmk

Changeset: e9e8a5852690
Author:    tbell
Date:      2012-11-12 12:35 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/e9e8a5852690

8002028: build-infra: need no-hotspot partial build
Summary: Added configure option --with-import-hotspot=/path/to/j2sdkimage
Reviewed-by: dholmes, tbell
Contributed-by: erik.joelsson at oracle.com

! makefiles/Import.gmk

Changeset: 84f0439ccaab
Author:    tbell
Date:      2012-11-13 13:46 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/84f0439ccaab

8001965: build-infra: Large compare diffs between new and old on mac
Summary: The wrong icon source file was used when building closed
Reviewed-by: ohair, tbell
Contributed-by: erik.joelsson at oracle.com

! makefiles/GensrcIcons.gmk

Changeset: ad5c1d6b1e16
Author:    katleman
Date:      2012-11-08 11:52 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/ad5c1d6b1e16

Added tag jdk8-b64 for changeset 26dbd73fb766

! .hgtags

Changeset: bc09a1591629
Author:    alanb
Date:      2012-11-04 14:07 +0000
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/bc09a1591629

8000330: (fc) FileChannel.truncate issues when given size > file size
8002180: (fc) FileChannel.map does not throw NPE if MapMode specified as null
Reviewed-by: chegar

! src/share/classes/sun/nio/ch/FileChannelImpl.java
! test/java/nio/channels/FileChannel/MapTest.java
! test/java/nio/channels/FileChannel/Truncate.java

Changeset: 46b24eb85b86
Author:    mullan
Date:      2012-11-05 10:30 -0500
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/46b24eb85b86

7171570: JEP 124 Potential API Changes
Reviewed-by: vinnie, xuelei

! src/share/classes/java/security/cert/CertPathBuilder.java
! src/share/classes/java/security/cert/CertPathValidator.java
! src/share/classes/java/security/cert/PKIXRevocationChecker.java
! src/share/classes/sun/security/provider/certpath/RevocationChecker.java
! test/java/security/cert/PKIXRevocationChecker/UnitTest.java

Changeset: 4770b0a49675
Author:    mullan
Date:      2012-11-05 10:33 -0500
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/4770b0a49675

Merge

- make/sun/jdbc/Makefile
- src/share/classes/sun/net/www/protocol/gopher/GopherClient.java
- src/share/classes/sun/net/www/protocol/gopher/Handler.java
- src/solaris/native/java/io/FileSystem_md.c
- src/windows/native/java/io/FileSystem_md.c

Changeset: 510cb3671f14
Author:    mullan
Date:      2012-11-05 12:08 -0500
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/510cb3671f14

Merge


Changeset: 519f4c9ebf8d
Author:    vinnie
Date:      2012-11-05 20:18 +0000
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/519f4c9ebf8d

6383200: PBE: need new algorithm support in password based encryption
Reviewed-by: valeriep

! src/share/classes/com/sun/crypto/provider/PBEKeyFactory.java
! src/share/classes/com/sun/crypto/provider/PBEParameters.java
+ src/share/classes/com/sun/crypto/provider/PBES1Core.java
+ src/share/classes/com/sun/crypto/provider/PBES2Core.java
+ src/share/classes/com/sun/crypto/provider/PBES2Parameters.java
! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndDESCipher.java
! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndTripleDESCipher.java
+ src/share/classes/com/sun/crypto/provider/PBKDF2Core.java
+ src/share/classes/com/sun/crypto/provider/PBMAC1Core.java
! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java
! src/share/classes/com/sun/crypto/provider/SunJCE.java
! src/share/classes/javax/crypto/spec/PBEParameterSpec.java
! test/com/sun/crypto/provider/Cipher/PBE/PBEInvalidParamsTest.java
! test/com/sun/crypto/provider/Cipher/PBE/PBEKeysAlgorithmNames.java
! test/com/sun/crypto/provider/Cipher/PBE/PBEParametersTest.java
+ test/com/sun/crypto/provider/Cipher/PBE/PBES2Test.java
! test/com/sun/crypto/provider/Cipher/PBE/PKCS12Cipher.java
! test/com/sun/crypto/provider/Cipher/PBE/PKCS12Oid.java
! test/com/sun/crypto/provider/Mac/HmacPBESHA1.java
! test/com/sun/crypto/provider/Mac/HmacSaltLengths.java

Changeset: 798292c71419
Author:    ksrini
Date:      2012-11-05 14:53 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/798292c71419

8001191: use -source 8 -target 8 when compiling the JDK
Reviewed-by: chegar, dholmes, erikj, jgish

! make/common/shared/Defs-control.gmk
! make/common/shared/Defs-java.gmk
! make/java/invoke/Makefile
! makefiles/Setup.gmk
! src/share/classes/sun/tools/java/RuntimeConstants.java
! src/share/native/java/lang/System.c
! test/ProblemList.txt

Changeset: 8222e6eac651
Author:    ksrini
Date:      2012-11-05 15:00 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/8222e6eac651

7050936: (pack200) Support version 52.0 class files in langtools
Reviewed-by: dholmes

! src/share/classes/com/sun/java/util/jar/pack/Constants.java
! src/share/native/com/sun/java/util/jar/pack/constants.h

Changeset: cb65e3315b27
Author:    jiangli
Date:      2012-11-05 12:51 -0500
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/cb65e3315b27

7197210: java/lang/invoke/CallSiteTest.java failing on armsflt.
Summary: Reduce work load and set longer timeout for java/lang/invoke tests.
Reviewed-by: kvn, twisti

! test/java/lang/invoke/BigArityTest.java
! test/java/lang/invoke/CallSiteTest.java
! test/java/lang/invoke/MethodHandlesTest.java
! test/java/lang/invoke/RicochetTest.java

Changeset: d90714aec287
Author:    lancea
Date:      2012-11-06 14:59 -0500
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/d90714aec287

8002212: adding read/writeObject to additional SerialXXX classes
Reviewed-by: naoto, forax

! src/share/classes/javax/sql/rowset/serial/SerialArray.java
! src/share/classes/javax/sql/rowset/serial/SerialDatalink.java
! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java
! src/share/classes/javax/sql/rowset/serial/SerialRef.java
! src/share/classes/javax/sql/rowset/serial/SerialStruct.java

Changeset: 157506182fa7
Author:    chegar
Date:      2012-11-06 21:01 +0000
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/157506182fa7

8002297: sun/net/www/protocol/http/StackTraceTest.java fails intermittently
Reviewed-by: alanb, dsamersoff

! test/sun/net/www/protocol/http/StackTraceTest.java

Changeset: bff9db7ca352
Author:    peytoia
Date:      2012-11-07 09:58 +0900
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/bff9db7ca352

7198195: Support Unicode 6.2.0
Reviewed-by: okutsu

! make/tools/GenerateCharacter/CharacterData01.java.template
! make/tools/UnicodeData/PropList.txt
! make/tools/UnicodeData/Scripts.txt
! make/tools/UnicodeData/SpecialCasing.txt
! make/tools/UnicodeData/UnicodeData.txt
! make/tools/UnicodeData/VERSION
! src/share/classes/java/lang/Character.java
! test/java/lang/Character/CheckProp.java
! test/java/lang/Character/CheckScript.java
! test/java/lang/Character/PropList.txt
! test/java/lang/Character/PropertyValueAliases.txt
! test/java/lang/Character/Scripts.txt

Changeset: c9fd61d23dbe
Author:    lana
Date:      2012-11-06 18:41 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/c9fd61d23dbe

Merge

- makefiles/docs/CORE_PKGS.gmk
- makefiles/docs/Makefile
- makefiles/docs/NON_CORE_PKGS.gmk
- makefiles/docs/Notes.html
- makefiles/mapfiles/launchers/mapfile-amd64
- makefiles/mapfiles/launchers/mapfile-i586
- makefiles/mapfiles/libawt_headless/reorder-i586
- makefiles/mapfiles/libjava/reorder-i586
- makefiles/mapfiles/libjpeg/reorder-i586
- makefiles/mapfiles/libnio/mapfile-bsd
- makefiles/mapfiles/libnio/reorder-i586
- makefiles/mapfiles/libverify/reorder-i586
- makefiles/mapfiles/libzip/reorder-i586
- makefiles/sun/xawt/ToBin.java

Changeset: a1bbb8805e22
Author:    weijun
Date:      2012-11-07 14:13 +0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/a1bbb8805e22

6355584: Introduce constrained Kerberos delegation
Reviewed-by: valeriep

+ src/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java
! src/share/classes/sun/security/jgss/GSSCaller.java
! src/share/classes/sun/security/jgss/GSSCredentialImpl.java
! src/share/classes/sun/security/jgss/HttpCaller.java
! src/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java
! src/share/classes/sun/security/jgss/krb5/Krb5Context.java
! src/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java
+ src/share/classes/sun/security/jgss/krb5/Krb5ProxyCredential.java
! src/share/classes/sun/security/jgss/krb5/Krb5Util.java
! src/share/classes/sun/security/jgss/spi/GSSCredentialSpi.java
! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java
! src/share/classes/sun/security/jgss/spnego/SpNegoCredElement.java
! src/share/classes/sun/security/jgss/wrapper/GSSCredElement.java
! src/share/classes/sun/security/krb5/Credentials.java
! src/share/classes/sun/security/krb5/EncryptedData.java
! src/share/classes/sun/security/krb5/KrbApReq.java
! src/share/classes/sun/security/krb5/KrbKdcRep.java
! src/share/classes/sun/security/krb5/KrbTgsRep.java
! src/share/classes/sun/security/krb5/KrbTgsReq.java
! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java
! src/share/classes/sun/security/krb5/internal/EncKDCRepPart.java
! src/share/classes/sun/security/krb5/internal/KDCOptions.java
! src/share/classes/sun/security/krb5/internal/Krb5.java
! src/share/classes/sun/security/krb5/internal/PAData.java
+ src/share/classes/sun/security/krb5/internal/PAForUserEnc.java
! src/share/classes/sun/security/krb5/internal/crypto/KeyUsage.java
! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java
! test/sun/security/krb5/auto/Basic.java
! test/sun/security/krb5/auto/Context.java
! test/sun/security/krb5/auto/CrossRealm.java
! test/sun/security/krb5/auto/KDC.java
! test/sun/security/krb5/auto/OkAsDelegate.java
+ test/sun/security/krb5/auto/S4U2proxy.java
+ test/sun/security/krb5/auto/S4U2proxyGSS.java
+ test/sun/security/krb5/auto/S4U2self.java
+ test/sun/security/krb5/auto/S4U2selfAsServer.java
+ test/sun/security/krb5/auto/S4U2selfAsServerGSS.java
+ test/sun/security/krb5/auto/S4U2selfGSS.java

Changeset: 59e88d3b9b17
Author:    jzavgren
Date:      2012-11-07 10:49 +0000
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/59e88d3b9b17

8001579: Cleanup warnings in security native code
Reviewed-by: chegar, alanb, vinnie

! src/share/native/sun/security/jgss/wrapper/GSSLibStub.c
! src/share/native/sun/security/jgss/wrapper/NativeUtil.c
! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c
! src/share/native/sun/security/pkcs11/wrapper/p11_crypt.c
! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c
! src/share/native/sun/security/pkcs11/wrapper/p11_general.c
! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c
! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c
! src/share/native/sun/security/pkcs11/wrapper/p11_util.c
! src/solaris/native/sun/security/pkcs11/j2secmod_md.c
! src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c

Changeset: 9e013ce42dd7
Author:    dfuchs
Date:      2012-11-07 13:24 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/9e013ce42dd7

6720349: (ch) Channels tests depending on hosts inside Sun
Summary: This changeset make the nio tests start small TCP or UDP servers from within the tests, instead of relying on external services.
Reviewed-by: alanb

! test/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java
! test/java/nio/channels/DatagramChannel/IsBound.java
! test/java/nio/channels/DatagramChannel/IsConnected.java
! test/java/nio/channels/Selector/Alias.java
! test/java/nio/channels/Selector/BasicConnect.java
! test/java/nio/channels/Selector/Connect.java
! test/java/nio/channels/Selector/ConnectWrite.java
! test/java/nio/channels/Selector/KeysReady.java
! test/java/nio/channels/SocketChannel/AdaptSocket.java
! test/java/nio/channels/SocketChannel/Basic.java
! test/java/nio/channels/SocketChannel/BufferSize.java
! test/java/nio/channels/SocketChannel/Connect.java
! test/java/nio/channels/SocketChannel/ConnectState.java
! test/java/nio/channels/SocketChannel/FinishConnect.java
! test/java/nio/channels/SocketChannel/IsConnectable.java
! test/java/nio/channels/SocketChannel/LocalAddress.java
! test/java/nio/channels/SocketChannel/Stream.java
! test/java/nio/channels/SocketChannel/VectorParams.java
+ test/java/nio/channels/TestServers.java
! test/java/nio/channels/TestUtil.java

Changeset: 7d50ff0e2d44
Author:    coffeys
Date:      2012-11-07 18:48 +0000
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/7d50ff0e2d44

8002227: (tz) Support tzdata2012i
Reviewed-by: peytoia, asaha

! make/sun/javazic/tzdata/VERSION
! make/sun/javazic/tzdata/africa
! make/sun/javazic/tzdata/asia
! make/sun/javazic/tzdata/australasia
! make/sun/javazic/tzdata/europe
! make/sun/javazic/tzdata/leapseconds
! make/sun/javazic/tzdata/northamerica
! make/sun/javazic/tzdata/southamerica
! makefiles/GendataTimeZone.gmk

Changeset: f51943263267
Author:    andrew
Date:      2012-11-07 16:07 -0500
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/f51943263267

8003120: ResourceManager.getApplicationResources() does not close InputStreams
Summary: Add finally blocks to close the InputStream instances
Reviewed-by: lancea

! src/share/classes/com/sun/naming/internal/ResourceManager.java

Changeset: cc325832469c
Author:    naoto
Date:      2012-11-07 15:08 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/cc325832469c

8001205: Calendar.getDisplayName(...): Returns null when provider is SPI but there is no SPI implementation
8001562: Collator.getAvailableLocales() doesn't return all locales for which localized instances are available
Reviewed-by: okutsu

! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java
+ test/java/util/Locale/Bug8001562.java
! test/java/util/PluggableLocale/BreakIteratorProviderTest.java
! test/java/util/PluggableLocale/CollatorProviderTest.java
! test/java/util/PluggableLocale/DateFormatProviderTest.java
! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java
! test/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.java
! test/java/util/PluggableLocale/GenericTest.java
! test/java/util/PluggableLocale/NumberFormatProviderTest.java

Changeset: 599f231cba97
Author:    jfranck
Date:      2012-11-07 17:39 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/599f231cba97

8001598: Augment ElementType enum for JSR 308
Reviewed-by: darcy

! src/share/classes/java/lang/annotation/ElementType.java

Changeset: cdf02b372956
Author:    sherman
Date:      2012-11-07 20:50 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/cdf02b372956

6282196: There should be Math.mod(number, modulo) methods
Summary: added the requested methods
Reviewed-by: darcy, emcmanus, alanb
Contributed-by: roger.riggs at oracle.com

! src/share/classes/java/lang/Math.java
! src/share/classes/java/lang/StrictMath.java
+ test/java/lang/Math/DivModTests.java

Changeset: 1e7dd9e05ce2
Author:    mullan
Date:      2012-11-08 12:51 -0500
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/1e7dd9e05ce2

7198416: CertificateIssuerName and CertificateSubjectName are redundant
Reviewed-by: mullan
Contributed-by: jason.uh at oracle.com

! src/share/classes/sun/security/pkcs/PKCS7.java
! src/share/classes/sun/security/tools/jarsigner/Main.java
! src/share/classes/sun/security/tools/keytool/CertAndKeyGen.java
! src/share/classes/sun/security/tools/keytool/Main.java
! src/share/classes/sun/security/x509/X509CertImpl.java
! src/share/classes/sun/security/x509/X509CertInfo.java
! src/share/classes/sun/security/x509/certAttributes.html
! test/sun/security/pkcs11/rsa/GenKeyStore.java
! test/sun/security/provider/X509Factory/BigCRL.java
! test/sun/security/rsa/GenKeyStore.java

Changeset: 9edfa0e761b9
Author:    xuelei
Date:      2012-11-09 01:15 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/9edfa0e761b9

8001569: Regression test GetPeerHost uses static port number
Reviewed-by: weijun

! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHost.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHostClient.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHostServer.java

Changeset: 220d2458ce4b
Author:    lana
Date:      2012-11-09 14:46 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/220d2458ce4b

Merge


Changeset: 130d3a54d28b
Author:    katleman
Date:      2012-11-14 12:29 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/130d3a54d28b

Merge


Changeset: ccff3b663797
Author:    tbell
Date:      2012-11-14 10:21 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/ccff3b663797

8001906: build-infra: warning: [path] bad path element on Solaris
Summary: Remove unnecesary -cp parameter from compile line
Reviewed-by: ohair, tbell
Contributed-by: erik.joelsson at oracle.com

! makefiles/CompileDemos.gmk

Changeset: 716efc201640
Author:    tbell
Date:      2012-11-15 00:55 +0000
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/716efc201640

Merge


Changeset: 0adaa7a854e8
Author:    erikj
Date:      2012-11-15 11:31 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/0adaa7a854e8

Merge

! makefiles/CompileNativeLibraries.gmk
! makefiles/GensrcIcons.gmk
! makefiles/GensrcLocaleDataMetaInfo.gmk
! makefiles/Import.gmk

Changeset: d334fdf31add
Author:    erikj
Date:      2012-11-15 11:33 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/d334fdf31add

Merge

! makefiles/CompileDemos.gmk
! makefiles/GendataTimeZone.gmk
! makefiles/Setup.gmk



From erik.joelsson at oracle.com  Thu Nov 15 03:41:28 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 15 Nov 2012 12:41:28 +0100
Subject: cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
	error in build-infra build ('old' build works OK)
In-Reply-To: <CALZT+jBmP8_DR=enW0uSuyP5ywfC5yqcdWvuSMEqirYjZha+bQ@mail.gmail.com>
References: <CAP7YuAT+X+BfcsFm=tZk3orEHyFh=_eK07B1KUPmJ106CnREyw@mail.gmail.com>	<50A02E86.6080002@oracle.com>
	<50A41541.7020606@oracle.com>
	<CALZT+jBmP8_DR=enW0uSuyP5ywfC5yqcdWvuSMEqirYjZha+bQ@mail.gmail.com>
Message-ID: <50A4D4E8.1000408@oracle.com>

Actually, we are needlessly listing source files explicitly for a number 
of libraries, including liblcms.so, in CompileNativeLibraries.gmk. I'm 
looking through them now and removing the obvious ones.

/Erik

On 2012-11-15 11:15, Fredrik ?hrstr?m wrote:
> Den onsdagen den 14:e november 2012 skrev Phil Race:
>> So in the new build system is *everything* centralised like this?
>> Monolithic files rather than including area specific ones ?
>> I'm not sure what the supposed advantage might be?
>>
>> Normally in the new build system, adding new source files do not require
> changing
> the makefile. This particular library has its sources mixed up with
> something else
> in the same source directory, thus the need to list source files explicitly.
>
> perha
>   It should be easy to fix I suppose..... and generally a goodthing. :-)
>
> //Fredrik
>
> -phil.
>> On 11/11/12 3:02 PM, David Holmes wrote:
>>
>>> Hi Martijn,
>>>
>>> Known issue fixed a couple of days ago:
>>>
>>> http://hg.openjdk.java.net/**build-infra/jdk8/jdk/rev/**1e79fec4a01f<http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/1e79fec4a01f>
>>>
>>> David
>>>
>>> On 12/11/2012 8:45 AM, Martijn Verburg wrote:
>>>
>>>> Hi all,
>>>>
>>>> Building jdk8_tl on Ubuntu 12.04 with OpenJDK Runtime Environment
>>>> (IcedTea7
>>>> 2.3.3) (7u9-2.3.3-0ubuntu1~12.04.1)
>>>> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode). I get the
>>>> following
>>>> compilation error using build-infra (but not the 'old' build).
>>>>
>>>> /home/openjdk/sources/jdk8_tl/**build/linux-x86_64-normal-**
>>>> server-release/jdk/objs/**liblcms/cmspack.o:
>>>> In function `UnrollHalfToFloat':
>>>> cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
>>>> cmspack.c:(.text+0x27c6): undefined reference to `_cmsHalf2Float'
>>>> /home/openjdk/sources/jdk8_tl/**build/linux-x86_64-normal-**
>>>> server-release/jdk/objs/**liblcms/cmspack.o:
>>>> In function `UnrollHalfTo16':
>>>> cmspack.c:(.text+0x2953): undefined reference to `_cmsHalf2Float'
>>>> cmspack.c:(.text+0x29fa): undefined reference to `_cmsHalf2Float'
>>>> /home/openjdk/sources/jdk8_tl/**build/linux-x86_64-normal-**
>>>> server-release/jdk/objs/**liblcms/cmspack.o:
>>>> In function `PackHalfFromFloat':
>>>> cmspack.c:(.text+0x2baf): undefined reference to `_cmsFloat2Half'
>>>> cmspack.c:(.text+0x2c10): undefined reference to `_cmsFloat2Half'
>>>> cmspack.c:(.text+0x2ccb): undefined reference to `_cmsFloat2Half'
>>>> /home/openjdk/sources/jdk8_tl/**build/linux-x86_64-normal-**
>>>> server-release/jdk/objs/**liblcms/cmspack.o:
>>>> In function `PackHalfFrom16':
>>>> cmspack.c:(.text+0x2de7): undefined reference to `_cmsFloat2Half'
>>>> cmspack.c:(.text+0x2e4d): undefined reference to `_cmsFloat2Half'
>>>> /home/openjdk/sources/jdk8_tl/**build/linux-x86_64-normal-**
>>>> server-release/jdk/objs/**liblcms/cmspack.o:cmspack.c:(.**text+0x2f01):
>>>> more undefined references to `_cmsFloat2Half' follow
>>>> collect2: ld returned 1 exit status
>>>> make[2]: ***
>>>> [/home/openjdk/sources/jdk8_**tl/build/linux-x86_64-normal-**
>>>> server-release/jdk/lib/amd64/**liblcms.so]
>>>> Error 1
>>>> make[1]: *** [libs-only] Error 2
>>>> make: *** [jdk-only] Error 2
>>>>
>>>> Haven't tracked it down any further than this yet, but thought I should
>>>> report it in :-).
>>>>
>>>> Cheers,
>>>> Martijn
>>>>


From erik.joelsson at oracle.com  Thu Nov 15 04:50:31 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 15 Nov 2012 12:50:31 +0000
Subject: hg: build-infra/jdk8/jdk: 8003477: build-infra: Remove explicit
	source file listings for libs when possible
Message-ID: <20121115125043.A3B55479A9@hg.openjdk.java.net>

Changeset: 1233ea81d80c
Author:    erikj
Date:      2012-11-15 13:49 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/1233ea81d80c

8003477: build-infra: Remove explicit source file listings for libs when possible

! makefiles/CompileNativeLibraries.gmk



From oehrstroem at gmail.com  Thu Nov 15 05:00:58 2012
From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=)
Date: Thu, 15 Nov 2012 14:00:58 +0100
Subject: hg: build-infra/jdk8/jdk: 8003477: build-infra: Remove explicit
	source file listings for libs when possible
In-Reply-To: <20121115125043.A3B55479A9@hg.openjdk.java.net>
References: <20121115125043.A3B55479A9@hg.openjdk.java.net>
Message-ID: <CALZT+jDiQjE_4vg88ujkByn8eo-XLndpNjWXwNFyC=FkYmSrPA@mail.gmail.com>

Nice!

2012/11/15  <erik.joelsson at oracle.com>:
> Changeset: 1233ea81d80c
> Author:    erikj
> Date:      2012-11-15 13:49 +0100
> URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/1233ea81d80c
>
> 8003477: build-infra: Remove explicit source file listings for libs when possible
>
> ! makefiles/CompileNativeLibraries.gmk
>


From fredrik.ohrstrom at oracle.com  Thu Nov 15 05:42:12 2012
From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com)
Date: Thu, 15 Nov 2012 13:42:12 +0000
Subject: hg: build-infra/jdk8/langtools: Synced with jdk8/tl/langtools
Message-ID: <20121115134216.68F60479AA@hg.openjdk.java.net>

Changeset: e1d64167a2d3
Author:    ohrstrom
Date:      2012-11-15 14:40 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/langtools/rev/e1d64167a2d3

Synced with jdk8/tl/langtools

+ src/share/classes/com/sun/source/doctree/AttributeTree.java
+ src/share/classes/com/sun/source/doctree/AuthorTree.java
+ src/share/classes/com/sun/source/doctree/BlockTagTree.java
+ src/share/classes/com/sun/source/doctree/CommentTree.java
+ src/share/classes/com/sun/source/doctree/DeprecatedTree.java
+ src/share/classes/com/sun/source/doctree/DocCommentTree.java
+ src/share/classes/com/sun/source/doctree/DocRootTree.java
+ src/share/classes/com/sun/source/doctree/DocTree.java
+ src/share/classes/com/sun/source/doctree/DocTreeVisitor.java
+ src/share/classes/com/sun/source/doctree/EndElementTree.java
+ src/share/classes/com/sun/source/doctree/EntityTree.java
+ src/share/classes/com/sun/source/doctree/ErroneousTree.java
+ src/share/classes/com/sun/source/doctree/IdentifierTree.java
+ src/share/classes/com/sun/source/doctree/InheritDocTree.java
+ src/share/classes/com/sun/source/doctree/InlineTagTree.java
+ src/share/classes/com/sun/source/doctree/LinkTree.java
+ src/share/classes/com/sun/source/doctree/LiteralTree.java
+ src/share/classes/com/sun/source/doctree/ParamTree.java
+ src/share/classes/com/sun/source/doctree/ReferenceTree.java
+ src/share/classes/com/sun/source/doctree/ReturnTree.java
+ src/share/classes/com/sun/source/doctree/SeeTree.java
+ src/share/classes/com/sun/source/doctree/SerialDataTree.java
+ src/share/classes/com/sun/source/doctree/SerialFieldTree.java
+ src/share/classes/com/sun/source/doctree/SerialTree.java
+ src/share/classes/com/sun/source/doctree/SinceTree.java
+ src/share/classes/com/sun/source/doctree/StartElementTree.java
+ src/share/classes/com/sun/source/doctree/TextTree.java
+ src/share/classes/com/sun/source/doctree/ThrowsTree.java
+ src/share/classes/com/sun/source/doctree/UnknownBlockTagTree.java
+ src/share/classes/com/sun/source/doctree/UnknownInlineTagTree.java
+ src/share/classes/com/sun/source/doctree/ValueTree.java
+ src/share/classes/com/sun/source/doctree/VersionTree.java
+ src/share/classes/com/sun/source/doctree/package-info.java
! src/share/classes/com/sun/source/tree/Tree.java
+ src/share/classes/com/sun/source/util/DocTreeScanner.java
+ src/share/classes/com/sun/source/util/DocTrees.java
+ src/share/classes/com/sun/source/util/SimpleDocTreeVisitor.java
! src/share/classes/com/sun/source/util/Trees.java
! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java
! src/share/classes/com/sun/tools/javac/api/JavacTool.java
! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/AttrContext.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Env.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/jvm/CRTable.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/Items.java
! src/share/classes/com/sun/tools/javac/jvm/JNIWriter.java
! src/share/classes/com/sun/tools/javac/jvm/Target.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/main/Main.java
+ src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java
+ src/share/classes/com/sun/tools/javac/parser/LazyDocCommentTable.java
! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java
- src/share/classes/com/sun/tools/javac/parser/SimpleDocCommentTable.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ src/share/classes/com/sun/tools/javac/tree/DCTree.java
! src/share/classes/com/sun/tools/javac/tree/DocCommentTable.java
+ src/share/classes/com/sun/tools/javac/tree/DocPretty.java
+ src/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java
! src/share/classes/com/sun/tools/javac/util/Log.java
! src/share/classes/com/sun/tools/javadoc/DocEnv.java
! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java
! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java
! src/share/classes/com/sun/tools/javadoc/Start.java
! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties



From erik.joelsson at oracle.com  Thu Nov 15 05:59:07 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 15 Nov 2012 13:59:07 +0000
Subject: hg: build-infra/jdk8/jdk: 8003482: build-infra: Use correct manifest
	in security jars
Message-ID: <20121115135919.23C41479AC@hg.openjdk.java.net>

Changeset: c43f1f377815
Author:    erikj
Date:      2012-11-15 14:58 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/c43f1f377815

8003482: build-infra: Use correct manifest in security jars

! makefiles/CreateJars.gmk



From erik.joelsson at oracle.com  Thu Nov 15 06:56:06 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 15 Nov 2012 14:56:06 +0000
Subject: hg: build-infra/jdk8/jdk: 2 new changesets
Message-ID: <20121115145628.22E00479AD@hg.openjdk.java.net>

Changeset: 9eea5c6c529c
Author:    erikj
Date:      2012-11-15 06:58 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/9eea5c6c529c

8003477: build-infra: Remove explicit source file listings for libs when possible
Summary: Libzip now works when using system zlib.

! makefiles/CompileNativeLibraries.gmk

Changeset: f5ba01626426
Author:    erikj
Date:      2012-11-15 06:58 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/f5ba01626426

Merge




From erik.joelsson at oracle.com  Thu Nov 15 07:15:33 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 15 Nov 2012 15:15:33 +0000
Subject: hg: build-infra/jdk8/jdk: 8003477: build-infra: Remove explicit
	source file listings for libs when possible
Message-ID: <20121115151544.63CE9479AE@hg.openjdk.java.net>

Changeset: bc7415d7e323
Author:    erikj
Date:      2012-11-15 16:15 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/bc7415d7e323

8003477: build-infra: Remove explicit source file listings for libs when possible
Summary: Fixed libsplashscreen and libjli when using bundles zlib.

! makefiles/CompileNativeLibraries.gmk



From kelly.ohair at oracle.com  Thu Nov 15 10:14:25 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Thu, 15 Nov 2012 10:14:25 -0800
Subject: Building with a new javac flag
In-Reply-To: <50A487A8.4070200@oracle.com>
References: <50A16F70.5050107@oracle.com>
	<50A190C4.2070105@oracle.com>	<50A2366D.9000508@oracle.com>
	<50A2B290.7040504@oracle.com>	<50A2BF71.80504@oracle.com>
	<50A3369D.5090403@oracle.com> <50A367D6.40209@oracle.com>
	<308159CD-23A3-4ED6-A293-0E40D8DE9ABF@oracle.com>
	<50A3E133.4030906@oracle.com> <50A3F267.6010901@oracle.com>
	<50A3F355.9010200@oracle.com> <50A3FA1C.4080402@oracle.com>
	<50A479AF.3060005@oracle.com> <50A47A3A.7000706@oracle.com>
	<50A487A8.4070200@oracle.com>
Message-ID: <CFC04DD5-B0A1-43FD-BD98-D540F5F086BC@oracle.com>

Kumar explained to me that the stripping of debug information (option passed to pack200) is done as the
packing is done, I don't think the class files on disk are modified.
HOWEVER, pack200 does not strip out this new special attribute for parameter names, as far as I know.

So I was saying in theory pack200 could do this parameter attribute stripping, but it would require changes to pack200.

-kto

On Nov 14, 2012, at 10:11 PM, David Holmes wrote:

> On 15/11/2012 3:14 PM, Jonathan Gibbons wrote:
>> I believe the plan would be to use pack200 to strip the attribute.
> 
> I don't know exactly what that means. Does it strip the attribute out of the existing class file, or does it create a copy without the attribute in it? Either way it means we need two copies of the .class files. If it could be stripped as part of the jarring process we'd only need a temporary copy of each file. There is about 160MB of .class files in a build.
> 
> David
> 
>> -- Jon
>> 
>> On 11/14/2012 09:12 PM, David Holmes wrote:
>>> On 15/11/2012 6:07 AM, Alex Buckley wrote:
>>>> Yes. We want parameters when jdk-variant=normal, so we'll include
>>>> -parameters in the JAVAC_FLAGS for that configure option/value combo.
>>>> Then the make targets for 'images' and 'profiles' will invoke pack200 to
>>>> strip the parameter attributes except for the j2sdk-image.
>>> 
>>> In that case we don't need any new configure options as this approach
>>> also works for embedded as it doesn't care about the full JDK.
>>> 
>>> Though we might want to conditionalize this on whether OPENJDK is true
>>> or not. There are some concerns about Oracle JDK build requirements
>>> being applied by default to OpenJDK builds.
>>> 
>>> Also how does the stripping work - does it mean that we will have to
>>> copy all the .class files first, or can it be applied when creating
>>> the jar files?
>>> 
>>> David
>>> 
>>>> Eric McCorkle will have a javac capable of emitting the attribute this
>>>> week, so we'll try it out on his local forest.
>>>> 
>>>> Alex
>>>> 
>>>> On 11/14/2012 11:39 AM, Jonathan Gibbons wrote:
>>>>> OK, but it still sounds like the policy of when to include the
>>>>> parameters can be determined without requiring extra configuration
>>>>> parameters.
>>>>> 
>>>>> (Which is separate from whether we should have parameters to override
>>>>> the default determination.)
>>>>> 
>>>>> -- Jon
>>>>> 
>>>>> 
>>>>> On 11/14/2012 11:35 AM, Alex Buckley wrote:
>>>>>> It sounds like the jdk-variant option would perfectly dominate the
>>>>>> enable-parameters option, if we wanted parameters in the normal
>>>>>> variant's JDK image and the normal variant's JRE image and the normal
>>>>>> variant's Compact Profiles image.
>>>>>> 
>>>>>> But we would like parameters in only the normal variant's JDK image,
>>>>>> not the other images, because IDEs only run on the biggest fattest
>>>>>> JDK.
>>>>>> 
>>>>>> Alex
>>>>>> 
>>>>>> On 11/14/2012 10:21 AM, Jonathan Gibbons wrote:
>>>>>>> If we already have a configure option for "JDK variant (normal or
>>>>>>> embedded)", why do we need any additional options for parameter
>>>>>>> names,
>>>>>>> if the decision whether or not to use parameter names is a
>>>>>>> function of
>>>>>>> the variant?
>>>>>>> 
>>>>>>> -- Jon
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 11/14/2012 09:09 AM, Kelly O'Hair wrote:
>>>>>>>> Seems like if we want this information a permanent aspect of certain
>>>>>>>> builds, it needs a configure argument means of doing it.
>>>>>>>> 
>>>>>>>> That doesn't prevent the use of JAVAC_FLAGS for this or other
>>>>>>>> things.
>>>>>>>> 
>>>>>>>> ---
>>>>>>>> I'm getting concerned that we end up with too many variations here,
>>>>>>>> for the typical developers they need simple
>>>>>>>> ways to get the standard configurations.
>>>>>>>> 
>>>>>>>> -kto
>>>>>>>> 
>>>>>>>> On Nov 14, 2012, at 1:43 AM, Erik Joelsson wrote:
>>>>>>>> 
>>>>>>>>> Alan and David are correct regarding how the build currently works.
>>>>>>>>> To support the case of only providing this information in certain
>>>>>>>>> images or profiles (like the JDK but not the JRE) we would need to
>>>>>>>>> produce class files of both kinds at some point in the build. This
>>>>>>>>> could be accomplished either by compiling everything twice or by
>>>>>>>>> stripping out the information at some point.
>>>>>>>>> 
>>>>>>>>> If the case is just to have different defaults between embedded and
>>>>>>>>> normal, it should be rather straight forward to add a configure
>>>>>>>>> argument that adds to the JAVAC_FLAGS variable. I would suggest
>>>>>>>>> adding this somewhere in common/autoconf/toolchain.m4. If you just
>>>>>>>>> want to see the effects of adding this parameter on a single build,
>>>>>>>>> running "make JAVAC_FLAGS=-parameter" should do the trick.
>>>>>>>>> 
>>>>>>>>> /Erik
>>>>>>>>> 
>>>>>>>>> On 2012-11-14 07:13, David Holmes wrote:
>>>>>>>>>> Alan is correct. A configuration is a selection of a range of
>>>>>>>>>> things
>>>>>>>>>> including platform, JDK variant (normal or embedded), JVM variant
>>>>>>>>>> (client, server, minimal), "release" (product or fastdebug). When
>>>>>>>>>> you do a build the classes only get compiled once regardless of
>>>>>>>>>> which jar they end up in, or which image the jar ends up in. So
>>>>>>>>>> this
>>>>>>>>>> javac option will be applied to all classes and hence to all build
>>>>>>>>>> artifacts.
>>>>>>>>>> 
>>>>>>>>>> None of which forces the selection of this being a configure time
>>>>>>>>>> option versus a "make" time option. The main issue with the latter
>>>>>>>>>> is that it makes it easier to produce inconsistent build
>>>>>>>>>> results if
>>>>>>>>>> you do partial builds and change the value of the option each
>>>>>>>>>> time.
>>>>>>>>>> 
>>>>>>>>>> David
>>>>>>>>>> 
>>>>>>>>>> On 14/11/2012 7:45 AM, Alan Bateman wrote:
>>>>>>>>>>> On 13/11/2012 20:50, Alex Buckley wrote:
>>>>>>>>>>>> The primary reason for storing parameter names in JDK8 class
>>>>>>>>>>>> files is
>>>>>>>>>>>> to help IDE vendors, so it's fine if only the JDK image has
>>>>>>>>>>>> them. We
>>>>>>>>>>>> are not making a general promise that any program will be
>>>>>>>>>>>> able to
>>>>>>>>>>>> find
>>>>>>>>>>>> parameter names of core Java Java SE classes at runtime. (Again,
>>>>>>>>>>>> please set aside concerns about footprint, compatibility, etc on
>>>>>>>>>>>> this
>>>>>>>>>>>> list.)
>>>>>>>>>>>> 
>>>>>>>>>>>> It sounds like a ./configure option of --enable-parameters could
>>>>>>>>>>>> add
>>>>>>>>>>>> an option to JAVAC_FLAGS - you say it would affect all
>>>>>>>>>>>> images? But
>>>>>>>>>>>> Erik said "the value of the option has different defaults
>>>>>>>>>>>> depending on
>>>>>>>>>>>> jdk variant/profile".
>>>>>>>>>>> Suppose we do "configure --enable-paramater-names && make" then
>>>>>>>>>>> this
>>>>>>>>>>> would compile the classes and native libraries but at this
>>>>>>>>>>> point we
>>>>>>>>>>> don't have any images, rather it's just raw classes on the file
>>>>>>>>>>> system
>>>>>>>>>>> (no rt.jar).
>>>>>>>>>>> 
>>>>>>>>>>> A subsequent "make images" would create the j2sdk-image and
>>>>>>>>>>> j2re-image
>>>>>>>>>>> with the rt.jar and the layout that we are used to. I think, and
>>>>>>>>>>> Erik or
>>>>>>>>>>> David can correct me, is that the same class files end up in both
>>>>>>>>>>> images. Subsequent stripping of debug attributes from
>>>>>>>>>>> everything in
>>>>>>>>>>> rt.jar may happen later, at least where JRE download size is
>>>>>>>>>>> important.
>>>>>>>>>>> 
>>>>>>>>>>> So my point about the parameter names is that the same classes
>>>>>>>>>>> are
>>>>>>>>>>> used
>>>>>>>>>>> for all images. The "profiles" build is like "images", it's
>>>>>>>>>>> really
>>>>>>>>>>> just
>>>>>>>>>>> packaging up the already compiled bits and so would get the same
>>>>>>>>>>> class
>>>>>>>>>>> files, assuming of course that the JDK/JRE images and profiles
>>>>>>>>>>> images
>>>>>>>>>>> are coming from the same build.
>>>>>>>>>>> 
>>>>>>>>>>> When Erik used the term "variant" then I assume he meant the
>>>>>>>>>>> --with-jdk-variant and --with-jvm-variant options to configure
>>>>>>>>>>> normal or
>>>>>>>>>>> embedded, client or server VM and things like that. That's part
>>>>>>>>>>> of the
>>>>>>>>>>> configuration. If we are compiling classes differently then I
>>>>>>>>>>> suspect it
>>>>>>>>>>> may require a separate configuration.
>>>>>>>>>>> 
>>>>>>>>>>>> Where should we look at the new build, given that the parameter
>>>>>>>>>>>> feature lives in the jdk8/tl forest?
>>>>>>>>>>> common/makefiles in the top-level repo, and makefiles
>>>>>>>>>>> directory in
>>>>>>>>>>> each
>>>>>>>>>>> of the other repos. Alternatively this guide:
>>>>>>>>>>> 
>>>>>>>>>>> http://openjdk.java.net/projects/build-infra/guide.html
>>>>>>>>>>> 
>>>>>>>>>>> -Alan.
>>>>>>> 
>>>>> 
>> 



From kelly.ohair at oracle.com  Thu Nov 15 10:36:30 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Thu, 15 Nov 2012 10:36:30 -0800
Subject: cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
	error in build-infra build ('old' build works OK)
In-Reply-To: <50A4D4E8.1000408@oracle.com>
References: <CAP7YuAT+X+BfcsFm=tZk3orEHyFh=_eK07B1KUPmJ106CnREyw@mail.gmail.com>	<50A02E86.6080002@oracle.com>
	<50A41541.7020606@oracle.com>
	<CALZT+jBmP8_DR=enW0uSuyP5ywfC5yqcdWvuSMEqirYjZha+bQ@mail.gmail.com>
	<50A4D4E8.1000408@oracle.com>
Message-ID: <17EB71DD-1B3A-47C6-868D-F306EE5CE350@oracle.com>

Thanks Erik.

This is a good point to make.

Our intent with the new makefiles is that adding sources, java or native, should not require a developer
to change any build logic.  But that means that the sources need to be organized in a way that makes it
easy for us to just compile all the sources in a directory.

Anyone that creates testcases in the source area or leaves random sources around may find this disturbing.

-kto

On Nov 15, 2012, at 3:41 AM, Erik Joelsson wrote:

> Actually, we are needlessly listing source files explicitly for a number of libraries, including liblcms.so, in CompileNativeLibraries.gmk. I'm looking through them now and removing the obvious ones.
> 
> /Erik
> 
> On 2012-11-15 11:15, Fredrik ?hrstr?m wrote:
>> Den onsdagen den 14:e november 2012 skrev Phil Race:
>>> So in the new build system is *everything* centralised like this?
>>> Monolithic files rather than including area specific ones ?
>>> I'm not sure what the supposed advantage might be?
>>> 
>>> Normally in the new build system, adding new source files do not require
>> changing
>> the makefile. This particular library has its sources mixed up with
>> something else
>> in the same source directory, thus the need to list source files explicitly.
>> 
>> perha
>>  It should be easy to fix I suppose..... and generally a goodthing. :-)
>> 
>> //Fredrik
>> 
>> -phil.
>>> On 11/11/12 3:02 PM, David Holmes wrote:
>>> 
>>>> Hi Martijn,
>>>> 
>>>> Known issue fixed a couple of days ago:
>>>> 
>>>> http://hg.openjdk.java.net/**build-infra/jdk8/jdk/rev/**1e79fec4a01f<http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/1e79fec4a01f>
>>>> 
>>>> David
>>>> 
>>>> On 12/11/2012 8:45 AM, Martijn Verburg wrote:
>>>> 
>>>>> Hi all,
>>>>> 
>>>>> Building jdk8_tl on Ubuntu 12.04 with OpenJDK Runtime Environment
>>>>> (IcedTea7
>>>>> 2.3.3) (7u9-2.3.3-0ubuntu1~12.04.1)
>>>>> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode). I get the
>>>>> following
>>>>> compilation error using build-infra (but not the 'old' build).
>>>>> 
>>>>> /home/openjdk/sources/jdk8_tl/**build/linux-x86_64-normal-**
>>>>> server-release/jdk/objs/**liblcms/cmspack.o:
>>>>> In function `UnrollHalfToFloat':
>>>>> cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
>>>>> cmspack.c:(.text+0x27c6): undefined reference to `_cmsHalf2Float'
>>>>> /home/openjdk/sources/jdk8_tl/**build/linux-x86_64-normal-**
>>>>> server-release/jdk/objs/**liblcms/cmspack.o:
>>>>> In function `UnrollHalfTo16':
>>>>> cmspack.c:(.text+0x2953): undefined reference to `_cmsHalf2Float'
>>>>> cmspack.c:(.text+0x29fa): undefined reference to `_cmsHalf2Float'
>>>>> /home/openjdk/sources/jdk8_tl/**build/linux-x86_64-normal-**
>>>>> server-release/jdk/objs/**liblcms/cmspack.o:
>>>>> In function `PackHalfFromFloat':
>>>>> cmspack.c:(.text+0x2baf): undefined reference to `_cmsFloat2Half'
>>>>> cmspack.c:(.text+0x2c10): undefined reference to `_cmsFloat2Half'
>>>>> cmspack.c:(.text+0x2ccb): undefined reference to `_cmsFloat2Half'
>>>>> /home/openjdk/sources/jdk8_tl/**build/linux-x86_64-normal-**
>>>>> server-release/jdk/objs/**liblcms/cmspack.o:
>>>>> In function `PackHalfFrom16':
>>>>> cmspack.c:(.text+0x2de7): undefined reference to `_cmsFloat2Half'
>>>>> cmspack.c:(.text+0x2e4d): undefined reference to `_cmsFloat2Half'
>>>>> /home/openjdk/sources/jdk8_tl/**build/linux-x86_64-normal-**
>>>>> server-release/jdk/objs/**liblcms/cmspack.o:cmspack.c:(.**text+0x2f01):
>>>>> more undefined references to `_cmsFloat2Half' follow
>>>>> collect2: ld returned 1 exit status
>>>>> make[2]: ***
>>>>> [/home/openjdk/sources/jdk8_**tl/build/linux-x86_64-normal-**
>>>>> server-release/jdk/lib/amd64/**liblcms.so]
>>>>> Error 1
>>>>> make[1]: *** [libs-only] Error 2
>>>>> make: *** [jdk-only] Error 2
>>>>> 
>>>>> Haven't tracked it down any further than this yet, but thought I should
>>>>> report it in :-).
>>>>> 
>>>>> Cheers,
>>>>> Martijn
>>>>> 



From alex.buckley at oracle.com  Thu Nov 15 14:21:16 2012
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 15 Nov 2012 14:21:16 -0800
Subject: Building with a new javac flag
In-Reply-To: <50A3F355.9010200@oracle.com>
References: <50A16F70.5050107@oracle.com> <50A190C4.2070105@oracle.com>
	<50A2366D.9000508@oracle.com> <50A2B290.7040504@oracle.com>
	<50A2BF71.80504@oracle.com> <50A3369D.5090403@oracle.com>
	<50A367D6.40209@oracle.com>
	<308159CD-23A3-4ED6-A293-0E40D8DE9ABF@oracle.com>
	<50A3E133.4030906@oracle.com> <50A3F267.6010901@oracle.com>
	<50A3F355.9010200@oracle.com>
Message-ID: <50A56ADC.1070002@oracle.com>

The pack200 tool knows that some attributes, e.g. LocalVariableTable, 
are deemed by the JVM Spec to exist for debugging purposes. 
--strip-debug will remove them. To remove a new non-debug attribute 
like MethodParameters, the invocation is:

pack200 --method-attribute=MethodParameters=strip -r rt.jar

(This will repack an existing jar, but I'll take up that point with 
David elsewhere in the thread.)

Alex

On Wednesday, November 14, 2012 11:39:01 AM, Jonathan Gibbons wrote:
> OK, but it still sounds like the policy of when to include the
> parameters can be determined without requiring extra configuration
> parameters.
>
> (Which is separate from whether we should have parameters to override
> the default determination.)
>
> -- Jon
>
>
> On 11/14/2012 11:35 AM, Alex Buckley wrote:
>> It sounds like the jdk-variant option would perfectly dominate the
>> enable-parameters option, if we wanted parameters in the normal
>> variant's JDK image and the normal variant's JRE image and the normal
>> variant's Compact Profiles image.
>>
>> But we would like parameters in only the normal variant's JDK image,
>> not the other images, because IDEs only run on the biggest fattest JDK.
>>
>> Alex
>>
>> On 11/14/2012 10:21 AM, Jonathan Gibbons wrote:
>>> If we already have a configure option for "JDK variant (normal or
>>> embedded)",  why do we need any additional options for parameter names,
>>> if the decision whether or not to use parameter names is a function of
>>> the variant?
>>>
>>> -- Jon
>>>
>>>
>>>
>>> On 11/14/2012 09:09 AM, Kelly O'Hair wrote:
>>>> Seems like if we want this information a permanent aspect of certain
>>>> builds, it needs a configure argument means of doing it.
>>>>
>>>> That doesn't prevent the use of JAVAC_FLAGS for this or other things.
>>>>
>>>> ---
>>>> I'm getting concerned that we end up with too many variations here,
>>>> for the typical developers they need simple
>>>> ways to get the standard configurations.
>>>>
>>>> -kto
>>>>
>>>> On Nov 14, 2012, at 1:43 AM, Erik Joelsson wrote:
>>>>
>>>>> Alan and David are correct regarding how the build currently works.
>>>>> To support the case of only providing this information in certain
>>>>> images or profiles (like the JDK but not the JRE) we would need to
>>>>> produce class files of both kinds at some point in the build. This
>>>>> could be accomplished either by compiling everything twice or by
>>>>> stripping out the information at some point.
>>>>>
>>>>> If the case is just to have different defaults between embedded and
>>>>> normal, it should be rather straight forward to add a configure
>>>>> argument that adds to the JAVAC_FLAGS variable. I would suggest
>>>>> adding this somewhere in common/autoconf/toolchain.m4. If you just
>>>>> want to see the effects of adding this parameter on a single build,
>>>>> running "make JAVAC_FLAGS=-parameter" should do the trick.
>>>>>
>>>>> /Erik
>>>>>
>>>>> On 2012-11-14 07:13, David Holmes wrote:
>>>>>> Alan is correct. A configuration is a selection of a range of things
>>>>>> including platform, JDK variant (normal or embedded), JVM variant
>>>>>> (client, server, minimal), "release" (product or fastdebug). When
>>>>>> you do a build the classes only get compiled once regardless of
>>>>>> which jar they end up in, or which image the jar ends up in. So this
>>>>>> javac option will be applied to all classes and hence to all build
>>>>>> artifacts.
>>>>>>
>>>>>> None of which forces the selection of this being a configure time
>>>>>> option versus a "make" time option. The main issue with the latter
>>>>>> is that it makes it easier to produce inconsistent build results if
>>>>>> you do partial builds and change the value of the option each time.
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On 14/11/2012 7:45 AM, Alan Bateman wrote:
>>>>>>> On 13/11/2012 20:50, Alex Buckley wrote:
>>>>>>>> The primary reason for storing parameter names in JDK8 class
>>>>>>>> files is
>>>>>>>> to help IDE vendors, so it's fine if only the JDK image has
>>>>>>>> them. We
>>>>>>>> are not making a general promise that any program will be able to
>>>>>>>> find
>>>>>>>> parameter names of core Java Java SE classes at runtime. (Again,
>>>>>>>> please set aside concerns about footprint, compatibility, etc
>>>>>>>> on this
>>>>>>>> list.)
>>>>>>>>
>>>>>>>> It sounds like a ./configure option of --enable-parameters
>>>>>>>> could add
>>>>>>>> an option to JAVAC_FLAGS - you say it would affect all images? But
>>>>>>>> Erik said "the value of the option has different defaults
>>>>>>>> depending on
>>>>>>>> jdk variant/profile".
>>>>>>> Suppose we do "configure --enable-paramater-names && make" then
>>>>>>> this
>>>>>>> would compile the classes and native libraries but at this point we
>>>>>>> don't have any images, rather it's just raw classes on the file
>>>>>>> system
>>>>>>> (no rt.jar).
>>>>>>>
>>>>>>> A subsequent "make images" would create the j2sdk-image and
>>>>>>> j2re-image
>>>>>>> with the rt.jar and the layout that we are used to. I think, and
>>>>>>> Erik or
>>>>>>> David can correct me, is that the same class files end up in both
>>>>>>> images. Subsequent stripping of debug attributes from everything in
>>>>>>> rt.jar may happen later, at least where JRE download size is
>>>>>>> important.
>>>>>>>
>>>>>>> So my point about the parameter names is that the same classes are
>>>>>>> used
>>>>>>> for all images. The "profiles" build is like "images", it's really
>>>>>>> just
>>>>>>> packaging up the already compiled bits and so would get the same
>>>>>>> class
>>>>>>> files, assuming of course that the JDK/JRE images and profiles
>>>>>>> images
>>>>>>> are coming from the same build.
>>>>>>>
>>>>>>> When Erik used the term "variant" then I assume he meant the
>>>>>>> --with-jdk-variant and --with-jvm-variant options to configure
>>>>>>> normal or
>>>>>>> embedded, client or server VM and things like that. That's part
>>>>>>> of the
>>>>>>> configuration. If we are compiling classes differently then I
>>>>>>> suspect it
>>>>>>> may require a separate configuration.
>>>>>>>
>>>>>>>> Where should we look at the new build, given that the parameter
>>>>>>>> feature lives in the jdk8/tl forest?
>>>>>>> common/makefiles in the top-level repo, and makefiles directory in
>>>>>>> each
>>>>>>> of the other repos. Alternatively this guide:
>>>>>>>
>>>>>>> http://openjdk.java.net/projects/build-infra/guide.html
>>>>>>>
>>>>>>> -Alan.
>>>
>


From alex.buckley at oracle.com  Thu Nov 15 14:24:14 2012
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 15 Nov 2012 14:24:14 -0800
Subject: Building with a new javac flag
In-Reply-To: <50A56ADC.1070002@oracle.com>
References: <50A16F70.5050107@oracle.com> <50A190C4.2070105@oracle.com>
	<50A2366D.9000508@oracle.com> <50A2B290.7040504@oracle.com>
	<50A2BF71.80504@oracle.com> <50A3369D.5090403@oracle.com>
	<50A367D6.40209@oracle.com>
	<308159CD-23A3-4ED6-A293-0E40D8DE9ABF@oracle.com>
	<50A3E133.4030906@oracle.com> <50A3F267.6010901@oracle.com>
	<50A3F355.9010200@oracle.com> <50A56ADC.1070002@oracle.com>
Message-ID: <50A56B8E.8030407@oracle.com>

Not sure how I replied to your mail here, it was intended to reply to 
Kelly.

On Thursday, November 15, 2012 2:21:16 PM, Alex Buckley wrote:
> The pack200 tool knows that some attributes, e.g. LocalVariableTable,
> are deemed by the JVM Spec to exist for debugging purposes.
> --strip-debug will remove them. To remove a new non-debug attribute
> like MethodParameters, the invocation is:



From alex.buckley at oracle.com  Thu Nov 15 14:24:27 2012
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 15 Nov 2012 14:24:27 -0800
Subject: Building with a new javac flag
In-Reply-To: <CFC04DD5-B0A1-43FD-BD98-D540F5F086BC@oracle.com>
References: <50A16F70.5050107@oracle.com>
	<50A190C4.2070105@oracle.com>	<50A2366D.9000508@oracle.com>
	<50A2B290.7040504@oracle.com>	<50A2BF71.80504@oracle.com>
	<50A3369D.5090403@oracle.com> <50A367D6.40209@oracle.com>
	<308159CD-23A3-4ED6-A293-0E40D8DE9ABF@oracle.com>
	<50A3E133.4030906@oracle.com> <50A3F267.6010901@oracle.com>
	<50A3F355.9010200@oracle.com> <50A3FA1C.4080402@oracle.com>
	<50A479AF.3060005@oracle.com> <50A47A3A.7000706@oracle.com>
	<50A487A8.4070200@oracle.com>
	<CFC04DD5-B0A1-43FD-BD98-D540F5F086BC@oracle.com>
Message-ID: <50A56B9B.3020608@oracle.com>

The pack200 tool knows that some attributes, e.g. LocalVariableTable, 
are deemed by the JVM Spec to exist for debugging purposes. 
--strip-debug will remove them. To remove a new non-debug attribute like 
MethodParameters, the invocation is:

pack200 --method-attribute=MethodParameters=strip -r rt.jar

(This will repack an existing jar, but I'll take up that point with 
David elsewhere in the thread.)

Alex

On 11/15/2012 10:14 AM, Kelly O'Hair wrote:
> Kumar explained to me that the stripping of debug information (option passed to pack200) is done as the
> packing is done, I don't think the class files on disk are modified.
> HOWEVER, pack200 does not strip out this new special attribute for parameter names, as far as I know.
>
> So I was saying in theory pack200 could do this parameter attribute stripping, but it would require changes to pack200.
>
> -kto
>
> On Nov 14, 2012, at 10:11 PM, David Holmes wrote:
>
>> On 15/11/2012 3:14 PM, Jonathan Gibbons wrote:
>>> I believe the plan would be to use pack200 to strip the attribute.
>>
>> I don't know exactly what that means. Does it strip the attribute out of the existing class file, or does it create a copy without the attribute in it? Either way it means we need two copies of the .class files. If it could be stripped as part of the jarring process we'd only need a temporary copy of each file. There is about 160MB of .class files in a build.
>>
>> David
>>
>>> -- Jon
>>>
>>> On 11/14/2012 09:12 PM, David Holmes wrote:
>>>> On 15/11/2012 6:07 AM, Alex Buckley wrote:
>>>>> Yes. We want parameters when jdk-variant=normal, so we'll include
>>>>> -parameters in the JAVAC_FLAGS for that configure option/value combo.
>>>>> Then the make targets for 'images' and 'profiles' will invoke pack200 to
>>>>> strip the parameter attributes except for the j2sdk-image.
>>>>
>>>> In that case we don't need any new configure options as this approach
>>>> also works for embedded as it doesn't care about the full JDK.
>>>>
>>>> Though we might want to conditionalize this on whether OPENJDK is true
>>>> or not. There are some concerns about Oracle JDK build requirements
>>>> being applied by default to OpenJDK builds.
>>>>
>>>> Also how does the stripping work - does it mean that we will have to
>>>> copy all the .class files first, or can it be applied when creating
>>>> the jar files?
>>>>
>>>> David
>>>>
>>>>> Eric McCorkle will have a javac capable of emitting the attribute this
>>>>> week, so we'll try it out on his local forest.
>>>>>
>>>>> Alex
>>>>>
>>>>> On 11/14/2012 11:39 AM, Jonathan Gibbons wrote:
>>>>>> OK, but it still sounds like the policy of when to include the
>>>>>> parameters can be determined without requiring extra configuration
>>>>>> parameters.
>>>>>>
>>>>>> (Which is separate from whether we should have parameters to override
>>>>>> the default determination.)
>>>>>>
>>>>>> -- Jon
>>>>>>
>>>>>>
>>>>>> On 11/14/2012 11:35 AM, Alex Buckley wrote:
>>>>>>> It sounds like the jdk-variant option would perfectly dominate the
>>>>>>> enable-parameters option, if we wanted parameters in the normal
>>>>>>> variant's JDK image and the normal variant's JRE image and the normal
>>>>>>> variant's Compact Profiles image.
>>>>>>>
>>>>>>> But we would like parameters in only the normal variant's JDK image,
>>>>>>> not the other images, because IDEs only run on the biggest fattest
>>>>>>> JDK.
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>> On 11/14/2012 10:21 AM, Jonathan Gibbons wrote:
>>>>>>>> If we already have a configure option for "JDK variant (normal or
>>>>>>>> embedded)", why do we need any additional options for parameter
>>>>>>>> names,
>>>>>>>> if the decision whether or not to use parameter names is a
>>>>>>>> function of
>>>>>>>> the variant?
>>>>>>>>
>>>>>>>> -- Jon
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/14/2012 09:09 AM, Kelly O'Hair wrote:
>>>>>>>>> Seems like if we want this information a permanent aspect of certain
>>>>>>>>> builds, it needs a configure argument means of doing it.
>>>>>>>>>
>>>>>>>>> That doesn't prevent the use of JAVAC_FLAGS for this or other
>>>>>>>>> things.
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> I'm getting concerned that we end up with too many variations here,
>>>>>>>>> for the typical developers they need simple
>>>>>>>>> ways to get the standard configurations.
>>>>>>>>>
>>>>>>>>> -kto
>>>>>>>>>
>>>>>>>>> On Nov 14, 2012, at 1:43 AM, Erik Joelsson wrote:
>>>>>>>>>
>>>>>>>>>> Alan and David are correct regarding how the build currently works.
>>>>>>>>>> To support the case of only providing this information in certain
>>>>>>>>>> images or profiles (like the JDK but not the JRE) we would need to
>>>>>>>>>> produce class files of both kinds at some point in the build. This
>>>>>>>>>> could be accomplished either by compiling everything twice or by
>>>>>>>>>> stripping out the information at some point.
>>>>>>>>>>
>>>>>>>>>> If the case is just to have different defaults between embedded and
>>>>>>>>>> normal, it should be rather straight forward to add a configure
>>>>>>>>>> argument that adds to the JAVAC_FLAGS variable. I would suggest
>>>>>>>>>> adding this somewhere in common/autoconf/toolchain.m4. If you just
>>>>>>>>>> want to see the effects of adding this parameter on a single build,
>>>>>>>>>> running "make JAVAC_FLAGS=-parameter" should do the trick.
>>>>>>>>>>
>>>>>>>>>> /Erik
>>>>>>>>>>
>>>>>>>>>> On 2012-11-14 07:13, David Holmes wrote:
>>>>>>>>>>> Alan is correct. A configuration is a selection of a range of
>>>>>>>>>>> things
>>>>>>>>>>> including platform, JDK variant (normal or embedded), JVM variant
>>>>>>>>>>> (client, server, minimal), "release" (product or fastdebug). When
>>>>>>>>>>> you do a build the classes only get compiled once regardless of
>>>>>>>>>>> which jar they end up in, or which image the jar ends up in. So
>>>>>>>>>>> this
>>>>>>>>>>> javac option will be applied to all classes and hence to all build
>>>>>>>>>>> artifacts.
>>>>>>>>>>>
>>>>>>>>>>> None of which forces the selection of this being a configure time
>>>>>>>>>>> option versus a "make" time option. The main issue with the latter
>>>>>>>>>>> is that it makes it easier to produce inconsistent build
>>>>>>>>>>> results if
>>>>>>>>>>> you do partial builds and change the value of the option each
>>>>>>>>>>> time.
>>>>>>>>>>>
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>> On 14/11/2012 7:45 AM, Alan Bateman wrote:
>>>>>>>>>>>> On 13/11/2012 20:50, Alex Buckley wrote:
>>>>>>>>>>>>> The primary reason for storing parameter names in JDK8 class
>>>>>>>>>>>>> files is
>>>>>>>>>>>>> to help IDE vendors, so it's fine if only the JDK image has
>>>>>>>>>>>>> them. We
>>>>>>>>>>>>> are not making a general promise that any program will be
>>>>>>>>>>>>> able to
>>>>>>>>>>>>> find
>>>>>>>>>>>>> parameter names of core Java Java SE classes at runtime. (Again,
>>>>>>>>>>>>> please set aside concerns about footprint, compatibility, etc on
>>>>>>>>>>>>> this
>>>>>>>>>>>>> list.)
>>>>>>>>>>>>>
>>>>>>>>>>>>> It sounds like a ./configure option of --enable-parameters could
>>>>>>>>>>>>> add
>>>>>>>>>>>>> an option to JAVAC_FLAGS - you say it would affect all
>>>>>>>>>>>>> images? But
>>>>>>>>>>>>> Erik said "the value of the option has different defaults
>>>>>>>>>>>>> depending on
>>>>>>>>>>>>> jdk variant/profile".
>>>>>>>>>>>> Suppose we do "configure --enable-paramater-names && make" then
>>>>>>>>>>>> this
>>>>>>>>>>>> would compile the classes and native libraries but at this
>>>>>>>>>>>> point we
>>>>>>>>>>>> don't have any images, rather it's just raw classes on the file
>>>>>>>>>>>> system
>>>>>>>>>>>> (no rt.jar).
>>>>>>>>>>>>
>>>>>>>>>>>> A subsequent "make images" would create the j2sdk-image and
>>>>>>>>>>>> j2re-image
>>>>>>>>>>>> with the rt.jar and the layout that we are used to. I think, and
>>>>>>>>>>>> Erik or
>>>>>>>>>>>> David can correct me, is that the same class files end up in both
>>>>>>>>>>>> images. Subsequent stripping of debug attributes from
>>>>>>>>>>>> everything in
>>>>>>>>>>>> rt.jar may happen later, at least where JRE download size is
>>>>>>>>>>>> important.
>>>>>>>>>>>>
>>>>>>>>>>>> So my point about the parameter names is that the same classes
>>>>>>>>>>>> are
>>>>>>>>>>>> used
>>>>>>>>>>>> for all images. The "profiles" build is like "images", it's
>>>>>>>>>>>> really
>>>>>>>>>>>> just
>>>>>>>>>>>> packaging up the already compiled bits and so would get the same
>>>>>>>>>>>> class
>>>>>>>>>>>> files, assuming of course that the JDK/JRE images and profiles
>>>>>>>>>>>> images
>>>>>>>>>>>> are coming from the same build.
>>>>>>>>>>>>
>>>>>>>>>>>> When Erik used the term "variant" then I assume he meant the
>>>>>>>>>>>> --with-jdk-variant and --with-jvm-variant options to configure
>>>>>>>>>>>> normal or
>>>>>>>>>>>> embedded, client or server VM and things like that. That's part
>>>>>>>>>>>> of the
>>>>>>>>>>>> configuration. If we are compiling classes differently then I
>>>>>>>>>>>> suspect it
>>>>>>>>>>>> may require a separate configuration.
>>>>>>>>>>>>
>>>>>>>>>>>>> Where should we look at the new build, given that the parameter
>>>>>>>>>>>>> feature lives in the jdk8/tl forest?
>>>>>>>>>>>> common/makefiles in the top-level repo, and makefiles
>>>>>>>>>>>> directory in
>>>>>>>>>>>> each
>>>>>>>>>>>> of the other repos. Alternatively this guide:
>>>>>>>>>>>>
>>>>>>>>>>>> http://openjdk.java.net/projects/build-infra/guide.html
>>>>>>>>>>>>
>>>>>>>>>>>> -Alan.
>>>>>>>>
>>>>>>
>>>
>


From alex.buckley at oracle.com  Thu Nov 15 14:27:55 2012
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 15 Nov 2012 14:27:55 -0800
Subject: Building with a new javac flag
In-Reply-To: <50A487A8.4070200@oracle.com>
References: <50A16F70.5050107@oracle.com>
	<50A190C4.2070105@oracle.com>	<50A2366D.9000508@oracle.com>
	<50A2B290.7040504@oracle.com>	<50A2BF71.80504@oracle.com>
	<50A3369D.5090403@oracle.com> <50A367D6.40209@oracle.com>
	<308159CD-23A3-4ED6-A293-0E40D8DE9ABF@oracle.com>
	<50A3E133.4030906@oracle.com> <50A3F267.6010901@oracle.com>
	<50A3F355.9010200@oracle.com> <50A3FA1C.4080402@oracle.com>
	<50A479AF.3060005@oracle.com> <50A47A3A.7000706@oracle.com>
	<50A487A8.4070200@oracle.com>
Message-ID: <50A56C6B.8090105@oracle.com>

On 11/14/2012 10:11 PM, David Holmes wrote:
> On 15/11/2012 3:14 PM, Jonathan Gibbons wrote:
>> I believe the plan would be to use pack200 to strip the attribute.
>
> I don't know exactly what that means. Does it strip the attribute out of
> the existing class file, or does it create a copy without the attribute
> in it? Either way it means we need two copies of the .class files. If it
> could be stripped as part of the jarring process we'd only need a
> temporary copy of each file. There is about 160MB of .class files in a
> build.

pack200 --method-attribute=MethodParameters=strip -r rt.jar  will take 
rt.jar, pack it without MethodParameters in class files, and immediately 
unpack it to rt.jar. We are experimenting with this locally. FWIW 
pack200 never accepts class files as input or output.

Alex


From philip.race at oracle.com  Thu Nov 15 14:59:05 2012
From: philip.race at oracle.com (Phil Race)
Date: Thu, 15 Nov 2012 14:59:05 -0800
Subject: cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
	error in build-infra build ('old' build works OK)
In-Reply-To: <CALZT+jBmP8_DR=enW0uSuyP5ywfC5yqcdWvuSMEqirYjZha+bQ@mail.gmail.com>
References: <CAP7YuAT+X+BfcsFm=tZk3orEHyFh=_eK07B1KUPmJ106CnREyw@mail.gmail.com>	<50A02E86.6080002@oracle.com>	<50A41541.7020606@oracle.com>
	<CALZT+jBmP8_DR=enW0uSuyP5ywfC5yqcdWvuSMEqirYjZha+bQ@mail.gmail.com>
Message-ID: <50A573B9.50001@oracle.com>

Fredik,

I've looked and the list of files in the sun/java2d/cmm/lcms source 
directory exactly
matches the list of files in the INCLUDE_FILES variable so I don't see 
anything mixed up here.

-phil.

On 11/15/2012 2:15 AM, Fredrik ?hrstr?m wrote:
>
>
> Den onsdagen den 14:e november 2012 skrev Phil Race:
>
>     So in the new build system is *everything* centralised like this?
>     Monolithic files rather than including area specific ones ?
>     I'm not sure what the supposed advantage might be?
>
> Normally in the new build system, adding new source files do not 
> require changing
> the makefile. This particular library has its sources mixed up with 
> something else
> in the same source directory, thus the need to list source files 
> explicitly.
>
> perha
>  It should be easy to fix I suppose..... and generally a goodthing. :-)
>
> //Fredrik
>
>     -phil.
>
>     On 11/11/12 3:02 PM, David Holmes wrote:
>
>         Hi Martijn,
>
>         Known issue fixed a couple of days ago:
>
>         http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/1e79fec4a01f
>
>         David
>
>         On 12/11/2012 8:45 AM, Martijn Verburg wrote:
>
>             Hi all,
>
>             Building jdk8_tl on Ubuntu 12.04 with OpenJDK Runtime
>             Environment (IcedTea7
>             2.3.3) (7u9-2.3.3-0ubuntu1~12.04.1)
>             OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode). I
>             get the following
>             compilation error using build-infra (but not the 'old' build).
>
>             /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:
>
>             In function `UnrollHalfToFloat':
>             cmspack.c:(.text+0x276b): undefined reference to
>             `_cmsHalf2Float'
>             cmspack.c:(.text+0x27c6): undefined reference to
>             `_cmsHalf2Float'
>             /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:
>
>             In function `UnrollHalfTo16':
>             cmspack.c:(.text+0x2953): undefined reference to
>             `_cmsHalf2Float'
>             cmspack.c:(.text+0x29fa): undefined reference to
>             `_cmsHalf2Float'
>             /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:
>
>             In function `PackHalfFromFloat':
>             cmspack.c:(.text+0x2baf): undefined reference to
>             `_cmsFloat2Half'
>             cmspack.c:(.text+0x2c10): undefined reference to
>             `_cmsFloat2Half'
>             cmspack.c:(.text+0x2ccb): undefined reference to
>             `_cmsFloat2Half'
>             /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:
>
>             In function `PackHalfFrom16':
>             cmspack.c:(.text+0x2de7): undefined reference to
>             `_cmsFloat2Half'
>             cmspack.c:(.text+0x2e4d): undefined reference to
>             `_cmsFloat2Half'
>             /home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/objs/liblcms/cmspack.o:cmspack.c:(.text+0x2f01):
>
>             more undefined references to `_cmsFloat2Half' follow
>             collect2: ld returned 1 exit status
>             make[2]: ***
>             [/home/openjdk/sources/jdk8_tl/build/linux-x86_64-normal-server-release/jdk/lib/amd64/liblcms.so]
>
>             Error 1
>             make[1]: *** [libs-only] Error 2
>             make: *** [jdk-only] Error 2
>
>             Haven't tracked it down any further than this yet, but
>             thought I should
>             report it in :-).
>
>             Cheers,
>             Martijn
>
>



From oehrstroem at gmail.com  Thu Nov 15 22:31:05 2012
From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=)
Date: Fri, 16 Nov 2012 07:31:05 +0100
Subject: cmspack.c:(.text+0x276b): undefined reference to `_cmsHalf2Float'
	error in build-infra build ('old' build works OK)
In-Reply-To: <50A573B9.50001@oracle.com>
References: <CAP7YuAT+X+BfcsFm=tZk3orEHyFh=_eK07B1KUPmJ106CnREyw@mail.gmail.com>
	<50A02E86.6080002@oracle.com> <50A41541.7020606@oracle.com>
	<CALZT+jBmP8_DR=enW0uSuyP5ywfC5yqcdWvuSMEqirYjZha+bQ@mail.gmail.com>
	<50A573B9.50001@oracle.com>
Message-ID: <CALZT+jBiUyPFE8Ecceo=DWWhp2CBAeFNE67MH9jzW4bCUZ7a8Q@mail.gmail.com>

2012/11/15 Phil Race <philip.race at oracle.com>:
> Fredik,
>
> I've looked and the list of files in the sun/java2d/cmm/lcms source
> directory exactly
> matches the list of files in the INCLUDE_FILES variable so I don't see
> anything mixed up here.

You are quite right! And Erik just fixed the makefiles. Since I did not convert
that makefile, I assumed that it was a reason that the sources were listed,
apparently there was not. :-)

//Fredrik


From erik.joelsson at oracle.com  Fri Nov 16 01:34:22 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 16 Nov 2012 09:34:22 +0000
Subject: hg: build-infra/jdk8/jdk: 8003482: build-infra: Use correct manifest
	in security jars
Message-ID: <20121116093441.E6C5D479E7@hg.openjdk.java.net>

Changeset: 7fbc195e79fa
Author:    erikj
Date:      2012-11-16 10:34 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/7fbc195e79fa

8003482: build-infra: Use correct manifest in security jars
Summary: Fixed typo in dependency declarations

! makefiles/CreateJars.gmk



From erik.joelsson at oracle.com  Fri Nov 16 05:02:31 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 16 Nov 2012 13:02:31 +0000
Subject: hg: build-infra/jdk8: 8003528: build-infra: Diffs in libjava and
	hotspot libs on solaris.
Message-ID: <20121116130232.3822E47A05@hg.openjdk.java.net>

Changeset: 9ceb404eba83
Author:    erikj
Date:      2012-11-16 13:58 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/9ceb404eba83

8003528: build-infra: Diffs in libjava and hotspot libs on solaris.
Summary: Put server dir before client in link path. Fixed disass filters in compare.

! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4
! common/bin/compare_exceptions.sh.incl



From erik.joelsson at oracle.com  Fri Nov 16 05:02:31 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 16 Nov 2012 13:02:31 +0000
Subject: hg: build-infra/jdk8/jdk: 2 new changesets
Message-ID: <20121116130325.CB6C747A06@hg.openjdk.java.net>

Changeset: 8ac29720380f
Author:    erikj
Date:      2012-11-16 13:56 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/8ac29720380f

8003528: build-infra: Diffs in libjava and hotspot libs on solaris.
Summary: Reordered link libs to match old build.

! makefiles/CompileNativeLibraries.gmk

Changeset: 916bdd440c8a
Author:    erikj
Date:      2012-11-16 14:01 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/916bdd440c8a

Merge




From erik.joelsson at oracle.com  Fri Nov 16 07:59:52 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 16 Nov 2012 15:59:52 +0000
Subject: hg: build-infra/jdk8: Fixed exception for windows compare.
Message-ID: <20121116155952.DB47647A09@hg.openjdk.java.net>

Changeset: 31eaae62bfeb
Author:    erikj
Date:      2012-11-16 16:59 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/31eaae62bfeb

Fixed exception for windows compare.

! common/bin/compare_exceptions.sh.incl



From philip.race at oracle.com  Fri Nov 16 15:14:50 2012
From: philip.race at oracle.com (Phil Race)
Date: Fri, 16 Nov 2012 15:14:50 -0800
Subject: build problem
Message-ID: <50A6C8EA.8080209@oracle.com>

Can anyone explain what the solution might be to the following
build failure on Windows 7 x64. I'm using our current JDK8 2d team repo :-

  sh ./configure --with-boot-jdk=c:/jdk1.7

make NEWBUILD=true BUILD_DEPLOY=false BUILD_INSTALL=false
No checks yet
cd /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/ && 
make all
make[1]: Entering directory 
`/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/spec.gmk:601: 
*** missing `endif'.  Stop.
make[1]: Leaving directory 
`/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
make: *** [all] Error 2


line 601 is the last line of spec.gmk and if I add endif afterwards it 
seems to
at least get past this point but obviously something is wrong.  I looked 
over
the file and all if's seem balanced to me.

Last few lines of the file look like this :- "8(0" looks odd too but
changing that doesn't seem to fix my issue.

----
# Name of Service Agent library
SALIB_NAME=sawindbg.dll

OS_VERSION_MAJOR:=1
OS_VERSION_MINOR:=7
OS_VERSION_MICRO:=8(0

# Include the custom-spec.gmk file if it exists
-include $(dir 
/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/spec.gmk)/custom-spec.gmk
-----


-phil.



From kelly.ohair at oracle.com  Fri Nov 16 15:21:08 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Fri, 16 Nov 2012 15:21:08 -0800
Subject: build problem
In-Reply-To: <50A6C8EA.8080209@oracle.com>
References: <50A6C8EA.8080209@oracle.com>
Message-ID: <B37AB3C0-0233-487A-89C5-C7466DEEE87D@oracle.com>

You need this changeset:

http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/1e79fec4a01f


-kto

On Nov 16, 2012, at 3:14 PM, Phil Race wrote:

> Can anyone explain what the solution might be to the following
> build failure on Windows 7 x64. I'm using our current JDK8 2d team repo :-
> 
> sh ./configure --with-boot-jdk=c:/jdk1.7
> 
> make NEWBUILD=true BUILD_DEPLOY=false BUILD_INSTALL=false
> No checks yet
> cd /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/ && make all
> make[1]: Entering directory `/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
> /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/spec.gmk:601: *** missing `endif'.  Stop.
> make[1]: Leaving directory `/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
> make: *** [all] Error 2
> 
> 
> line 601 is the last line of spec.gmk and if I add endif afterwards it seems to
> at least get past this point but obviously something is wrong.  I looked over
> the file and all if's seem balanced to me.
> 
> Last few lines of the file look like this :- "8(0" looks odd too but
> changing that doesn't seem to fix my issue.
> 
> ----
> # Name of Service Agent library
> SALIB_NAME=sawindbg.dll
> 
> OS_VERSION_MAJOR:=1
> OS_VERSION_MINOR:=7
> OS_VERSION_MICRO:=8(0
> 
> # Include the custom-spec.gmk file if it exists
> -include $(dir /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/spec.gmk)/custom-spec.gmk
> -----
> 
> 
> -phil.
> 



From philip.race at oracle.com  Fri Nov 16 15:28:20 2012
From: philip.race at oracle.com (Phil Race)
Date: Fri, 16 Nov 2012 15:28:20 -0800
Subject: build problem
In-Reply-To: <B37AB3C0-0233-487A-89C5-C7466DEEE87D@oracle.com>
References: <50A6C8EA.8080209@oracle.com>
	<B37AB3C0-0233-487A-89C5-C7466DEEE87D@oracle.com>
Message-ID: <50A6CC14.30008@oracle.com>

I had already applied those two fixes manually and I just
double-checked and they seem to be there ..

-phil.

On 11/16/2012 3:21 PM, Kelly O'Hair wrote:
> You need this changeset:
>
> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/1e79fec4a01f
>
>
> -kto
>
> On Nov 16, 2012, at 3:14 PM, Phil Race wrote:
>
>> Can anyone explain what the solution might be to the following
>> build failure on Windows 7 x64. I'm using our current JDK8 2d team repo :-
>>
>> sh ./configure --with-boot-jdk=c:/jdk1.7
>>
>> make NEWBUILD=true BUILD_DEPLOY=false BUILD_INSTALL=false
>> No checks yet
>> cd /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/&&  make all
>> make[1]: Entering directory `/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
>> /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/spec.gmk:601: *** missing `endif'.  Stop.
>> make[1]: Leaving directory `/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
>> make: *** [all] Error 2
>>
>>
>> line 601 is the last line of spec.gmk and if I add endif afterwards it seems to
>> at least get past this point but obviously something is wrong.  I looked over
>> the file and all if's seem balanced to me.
>>
>> Last few lines of the file look like this :- "8(0" looks odd too but
>> changing that doesn't seem to fix my issue.
>>
>> ----
>> # Name of Service Agent library
>> SALIB_NAME=sawindbg.dll
>>
>> OS_VERSION_MAJOR:=1
>> OS_VERSION_MINOR:=7
>> OS_VERSION_MICRO:=8(0
>>
>> # Include the custom-spec.gmk file if it exists
>> -include $(dir /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/spec.gmk)/custom-spec.gmk
>> -----
>>
>>
>> -phil.
>>



From alan.bateman at oracle.com  Mon Nov 19 02:37:23 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Mon, 19 Nov 2012 10:37:23 +0000
Subject: hg: jdk8/profiles/jdk: Improve VersionTest.java to not rely on
	Version.profileName
Message-ID: <20121119103802.6F85E47A4B@hg.openjdk.java.net>

Changeset: 7ef9fec8d42f
Author:    alanb
Date:      2012-11-19 10:34 +0000
URL:       http://hg.openjdk.java.net/jdk8/profiles/jdk/rev/7ef9fec8d42f

Improve VersionTest.java to not rely on Version.profileName

! test/tools/launcher/profiles/VersionCheck.java



From erik.joelsson at oracle.com  Mon Nov 19 03:18:35 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 19 Nov 2012 12:18:35 +0100
Subject: build problem
In-Reply-To: <50A6CC14.30008@oracle.com>
References: <50A6C8EA.8080209@oracle.com>	<B37AB3C0-0233-487A-89C5-C7466DEEE87D@oracle.com>
	<50A6CC14.30008@oracle.com>
Message-ID: <50AA158B.3080208@oracle.com>

My first guess would be a '\' at the end of a line somewhere in the 
spec.gmk file that cancels out the endif on the next line. Would be 
interesting to see the full spec.gmk regardless. I haven't seen this 
happen before in spec but wouldn't be surprised if a backslash from a 
path somewhere ended up in the wrong place.

/Erik

On 2012-11-17 00:28, Phil Race wrote:
> I had already applied those two fixes manually and I just
> double-checked and they seem to be there ..
>
> -phil.
>
> On 11/16/2012 3:21 PM, Kelly O'Hair wrote:
>> You need this changeset:
>>
>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/1e79fec4a01f
>>
>>
>> -kto
>>
>> On Nov 16, 2012, at 3:14 PM, Phil Race wrote:
>>
>>> Can anyone explain what the solution might be to the following
>>> build failure on Windows 7 x64. I'm using our current JDK8 2d team 
>>> repo :-
>>>
>>> sh ./configure --with-boot-jdk=c:/jdk1.7
>>>
>>> make NEWBUILD=true BUILD_DEPLOY=false BUILD_INSTALL=false
>>> No checks yet
>>> cd 
>>> /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/&&  
>>> make all
>>> make[1]: Entering directory 
>>> `/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
>>> /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/spec.gmk:601: 
>>> *** missing `endif'.  Stop.
>>> make[1]: Leaving directory 
>>> `/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
>>> make: *** [all] Error 2
>>>
>>>
>>> line 601 is the last line of spec.gmk and if I add endif afterwards 
>>> it seems to
>>> at least get past this point but obviously something is wrong.  I 
>>> looked over
>>> the file and all if's seem balanced to me.
>>>
>>> Last few lines of the file look like this :- "8(0" looks odd too but
>>> changing that doesn't seem to fix my issue.
>>>
>>> ----
>>> # Name of Service Agent library
>>> SALIB_NAME=sawindbg.dll
>>>
>>> OS_VERSION_MAJOR:=1
>>> OS_VERSION_MINOR:=7
>>> OS_VERSION_MICRO:=8(0
>>>
>>> # Include the custom-spec.gmk file if it exists
>>> -include $(dir 
>>> /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/spec.gmk)/custom-spec.gmk
>>> -----
>>>
>>>
>>> -phil.
>>>
>


From erik.joelsson at oracle.com  Mon Nov 19 04:54:07 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Mon, 19 Nov 2012 12:54:07 +0000
Subject: hg: build-infra/jdk8/jdk: Moving all jar creation and copying to
	CreateJars and putting the jars
Message-ID: <20121119125455.C747547A4C@hg.openjdk.java.net>

Changeset: c97edc9b4c68
Author:    erikj
Date:      2012-11-19 13:50 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/c97edc9b4c68

Moving all jar creation and copying to CreateJars and putting the jars
in images/lib instead of jdk/lib for consistency.

! makefiles/CompileDemos.gmk
! makefiles/CompileJavaClasses.gmk
! makefiles/CreateJars.gmk
! makefiles/Images.gmk
! makefiles/Import.gmk



From erik.joelsson at oracle.com  Mon Nov 19 05:00:44 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Mon, 19 Nov 2012 13:00:44 +0000
Subject: hg: build-infra/jdk8: Removing stray ')' in SetupArchive macro
	implementation.
Message-ID: <20121119130045.1206D47A4D@hg.openjdk.java.net>

Changeset: e02034fbbef5
Author:    erikj
Date:      2012-11-19 13:48 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/e02034fbbef5

Removing stray ')' in SetupArchive macro implementation.

! common/makefiles/JavaCompilation.gmk



From erik.joelsson at oracle.com  Mon Nov 19 05:10:55 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Mon, 19 Nov 2012 13:10:55 +0000
Subject: hg: build-infra/jdk8/jdk: Fixed build on mac after jar move.
Message-ID: <20121119131106.9A61247A4E@hg.openjdk.java.net>

Changeset: b3945c2c40fc
Author:    erikj
Date:      2012-11-19 05:13 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/b3945c2c40fc

Fixed build on mac after jar move.

! makefiles/CompileJavaClasses.gmk



From erik.joelsson at oracle.com  Mon Nov 19 08:17:16 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Mon, 19 Nov 2012 16:17:16 +0000
Subject: hg: build-infra/jdk8: 8003300: build-infra: fails on solaris when
	objcopy is not found
Message-ID: <20121119161716.395A447A52@hg.openjdk.java.net>

Changeset: cf98fae05959
Author:    erikj
Date:      2012-11-19 17:14 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/cf98fae05959

8003300: build-infra: fails on solaris when objcopy is not found
Summary: Made call to fixup_path for objcopy conditional on objcopy being set.

! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4



From philip.race at oracle.com  Mon Nov 19 08:43:27 2012
From: philip.race at oracle.com (Phil Race)
Date: Mon, 19 Nov 2012 08:43:27 -0800
Subject: build problem
In-Reply-To: <50AA158B.3080208@oracle.com>
References: <50A6C8EA.8080209@oracle.com>	<B37AB3C0-0233-487A-89C5-C7466DEEE87D@oracle.com>	<50A6CC14.30008@oracle.com>
	<50AA158B.3080208@oracle.com>
Message-ID: <50AA61AF.3050800@oracle.com>

I'm sure that's why Kelly suggested the changeset below .. since it has 
such a \
but I already fixed that prior to even trying to build.

-phil.

On 11/19/2012 3:18 AM, Erik Joelsson wrote:
> My first guess would be a '\' at the end of a line somewhere in the 
> spec.gmk file that cancels out the endif on the next line. Would be 
> interesting to see the full spec.gmk regardless. I haven't seen this 
> happen before in spec but wouldn't be surprised if a backslash from a 
> path somewhere ended up in the wrong place.
>
> /Erik
>
> On 2012-11-17 00:28, Phil Race wrote:
>> I had already applied those two fixes manually and I just
>> double-checked and they seem to be there ..
>>
>> -phil.
>>
>> On 11/16/2012 3:21 PM, Kelly O'Hair wrote:
>>> You need this changeset:
>>>
>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/1e79fec4a01f
>>>
>>>
>>> -kto
>>>
>>> On Nov 16, 2012, at 3:14 PM, Phil Race wrote:
>>>
>>>> Can anyone explain what the solution might be to the following
>>>> build failure on Windows 7 x64. I'm using our current JDK8 2d team 
>>>> repo :-
>>>>
>>>> sh ./configure --with-boot-jdk=c:/jdk1.7
>>>>
>>>> make NEWBUILD=true BUILD_DEPLOY=false BUILD_INSTALL=false
>>>> No checks yet
>>>> cd 
>>>> /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/&&  
>>>> make all
>>>> make[1]: Entering directory 
>>>> `/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
>>>> /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/spec.gmk:601: 
>>>> *** missing `endif'.  Stop.
>>>> make[1]: Leaving directory 
>>>> `/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
>>>> make: *** [all] Error 2
>>>>
>>>>
>>>> line 601 is the last line of spec.gmk and if I add endif afterwards 
>>>> it seems to
>>>> at least get past this point but obviously something is wrong.  I 
>>>> looked over
>>>> the file and all if's seem balanced to me.
>>>>
>>>> Last few lines of the file look like this :- "8(0" looks odd too but
>>>> changing that doesn't seem to fix my issue.
>>>>
>>>> ----
>>>> # Name of Service Agent library
>>>> SALIB_NAME=sawindbg.dll
>>>>
>>>> OS_VERSION_MAJOR:=1
>>>> OS_VERSION_MINOR:=7
>>>> OS_VERSION_MICRO:=8(0
>>>>
>>>> # Include the custom-spec.gmk file if it exists
>>>> -include $(dir 
>>>> /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/spec.gmk)/custom-spec.gmk
>>>> -----
>>>>
>>>>
>>>> -phil.
>>>>
>>



From erik.joelsson at oracle.com  Mon Nov 19 08:45:54 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 19 Nov 2012 17:45:54 +0100
Subject: build problem
In-Reply-To: <50AA61AF.3050800@oracle.com>
References: <50A6C8EA.8080209@oracle.com>	<B37AB3C0-0233-487A-89C5-C7466DEEE87D@oracle.com>	<50A6CC14.30008@oracle.com>
	<50AA158B.3080208@oracle.com> <50AA61AF.3050800@oracle.com>
Message-ID: <50AA6242.3070908@oracle.com>

No, you misunderstand me. That changeset fixed such a problem in 
CreateJars.gmk. Your error message says spec.gmk, the generated file in 
the build output dir. I'm suspecting that something to do with a path 
with backslashes in it has somehow gotten in there, but it's just a 
guess. I would like to take a look at the resulting spec.gmk regardless 
to try to figure it out.

/Erik

On 2012-11-19 17:43, Phil Race wrote:
> I'm sure that's why Kelly suggested the changeset below .. since it 
> has such a \
> but I already fixed that prior to even trying to build.
>
> -phil.
>
> On 11/19/2012 3:18 AM, Erik Joelsson wrote:
>> My first guess would be a '\' at the end of a line somewhere in the 
>> spec.gmk file that cancels out the endif on the next line. Would be 
>> interesting to see the full spec.gmk regardless. I haven't seen this 
>> happen before in spec but wouldn't be surprised if a backslash from a 
>> path somewhere ended up in the wrong place.
>>
>> /Erik
>>
>> On 2012-11-17 00:28, Phil Race wrote:
>>> I had already applied those two fixes manually and I just
>>> double-checked and they seem to be there ..
>>>
>>> -phil.
>>>
>>> On 11/16/2012 3:21 PM, Kelly O'Hair wrote:
>>>> You need this changeset:
>>>>
>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/1e79fec4a01f
>>>>
>>>>
>>>> -kto
>>>>
>>>> On Nov 16, 2012, at 3:14 PM, Phil Race wrote:
>>>>
>>>>> Can anyone explain what the solution might be to the following
>>>>> build failure on Windows 7 x64. I'm using our current JDK8 2d team 
>>>>> repo :-
>>>>>
>>>>> sh ./configure --with-boot-jdk=c:/jdk1.7
>>>>>
>>>>> make NEWBUILD=true BUILD_DEPLOY=false BUILD_INSTALL=false
>>>>> No checks yet
>>>>> cd 
>>>>> /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/&&  
>>>>> make all
>>>>> make[1]: Entering directory 
>>>>> `/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
>>>>> /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/spec.gmk:601: 
>>>>> *** missing `endif'.  Stop.
>>>>> make[1]: Leaving directory 
>>>>> `/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
>>>>> make: *** [all] Error 2
>>>>>
>>>>>
>>>>> line 601 is the last line of spec.gmk and if I add endif 
>>>>> afterwards it seems to
>>>>> at least get past this point but obviously something is wrong.  I 
>>>>> looked over
>>>>> the file and all if's seem balanced to me.
>>>>>
>>>>> Last few lines of the file look like this :- "8(0" looks odd too but
>>>>> changing that doesn't seem to fix my issue.
>>>>>
>>>>> ----
>>>>> # Name of Service Agent library
>>>>> SALIB_NAME=sawindbg.dll
>>>>>
>>>>> OS_VERSION_MAJOR:=1
>>>>> OS_VERSION_MINOR:=7
>>>>> OS_VERSION_MICRO:=8(0
>>>>>
>>>>> # Include the custom-spec.gmk file if it exists
>>>>> -include $(dir 
>>>>> /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/spec.gmk)/custom-spec.gmk
>>>>> -----
>>>>>
>>>>>
>>>>> -phil.
>>>>>
>>>
>


From philip.race at oracle.com  Mon Nov 19 08:50:28 2012
From: philip.race at oracle.com (Phil Race)
Date: Mon, 19 Nov 2012 08:50:28 -0800
Subject: build problem
In-Reply-To: <50AA6242.3070908@oracle.com>
References: <50A6C8EA.8080209@oracle.com>	<B37AB3C0-0233-487A-89C5-C7466DEEE87D@oracle.com>	<50A6CC14.30008@oracle.com>
	<50AA158B.3080208@oracle.com> <50AA61AF.3050800@oracle.com>
	<50AA6242.3070908@oracle.com>
Message-ID: <50AA6354.6040801@oracle.com>

Ok .. well I already sent you the file.

-phil.

On 11/19/2012 8:45 AM, Erik Joelsson wrote:
> No, you misunderstand me. That changeset fixed such a problem in 
> CreateJars.gmk. Your error message says spec.gmk, the generated file 
> in the build output dir. I'm suspecting that something to do with a 
> path with backslashes in it has somehow gotten in there, but it's just 
> a guess. I would like to take a look at the resulting spec.gmk 
> regardless to try to figure it out.
>
> /Erik
>
> On 2012-11-19 17:43, Phil Race wrote:
>> I'm sure that's why Kelly suggested the changeset below .. since it 
>> has such a \
>> but I already fixed that prior to even trying to build.
>>
>> -phil.
>>
>> On 11/19/2012 3:18 AM, Erik Joelsson wrote:
>>> My first guess would be a '\' at the end of a line somewhere in the 
>>> spec.gmk file that cancels out the endif on the next line. Would be 
>>> interesting to see the full spec.gmk regardless. I haven't seen this 
>>> happen before in spec but wouldn't be surprised if a backslash from 
>>> a path somewhere ended up in the wrong place.
>>>
>>> /Erik
>>>
>>> On 2012-11-17 00:28, Phil Race wrote:
>>>> I had already applied those two fixes manually and I just
>>>> double-checked and they seem to be there ..
>>>>
>>>> -phil.
>>>>
>>>> On 11/16/2012 3:21 PM, Kelly O'Hair wrote:
>>>>> You need this changeset:
>>>>>
>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/1e79fec4a01f
>>>>>
>>>>>
>>>>> -kto
>>>>>
>>>>> On Nov 16, 2012, at 3:14 PM, Phil Race wrote:
>>>>>
>>>>>> Can anyone explain what the solution might be to the following
>>>>>> build failure on Windows 7 x64. I'm using our current JDK8 2d 
>>>>>> team repo :-
>>>>>>
>>>>>> sh ./configure --with-boot-jdk=c:/jdk1.7
>>>>>>
>>>>>> make NEWBUILD=true BUILD_DEPLOY=false BUILD_INSTALL=false
>>>>>> No checks yet
>>>>>> cd 
>>>>>> /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/&&  make 
>>>>>> all
>>>>>> make[1]: Entering directory 
>>>>>> `/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
>>>>>> /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/spec.gmk:601: 
>>>>>> *** missing `endif'.  Stop.
>>>>>> make[1]: Leaving directory 
>>>>>> `/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
>>>>>> make: *** [all] Error 2
>>>>>>
>>>>>>
>>>>>> line 601 is the last line of spec.gmk and if I add endif 
>>>>>> afterwards it seems to
>>>>>> at least get past this point but obviously something is wrong.  I 
>>>>>> looked over
>>>>>> the file and all if's seem balanced to me.
>>>>>>
>>>>>> Last few lines of the file look like this :- "8(0" looks odd too but
>>>>>> changing that doesn't seem to fix my issue.
>>>>>>
>>>>>> ----
>>>>>> # Name of Service Agent library
>>>>>> SALIB_NAME=sawindbg.dll
>>>>>>
>>>>>> OS_VERSION_MAJOR:=1
>>>>>> OS_VERSION_MINOR:=7
>>>>>> OS_VERSION_MICRO:=8(0
>>>>>>
>>>>>> # Include the custom-spec.gmk file if it exists
>>>>>> -include $(dir 
>>>>>> /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/spec.gmk)/custom-spec.gmk
>>>>>> -----
>>>>>>
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>
>>



From ohumbel at gmail.com  Mon Nov 19 09:51:27 2012
From: ohumbel at gmail.com (Oti)
Date: Mon, 19 Nov 2012 18:51:27 +0100
Subject: Access denied on Windows7 64bit
Message-ID: <CACDaqRCoFcz98tRoEUx5hgDTDSwEQqmWmniNe_Yvwym2Oj1H2A@mail.gmail.com>

Hi all,

recently I joined the AdoptOpenJDK program and started to test the new
build on Windows.
You can find a list what I did here:
http://java.net/projects/adoptopenjdk/pages/BuildWindows.

The disabling of ASLR really helped: Before that I got a never ending
hotspot build with 0% CPU load.
Now hotspot builds just fine, thanks for the tip in
http://mail.openjdk.java.net/pipermail/build-dev/2012-February/005594.html!

What I am stuck with now is an Access denied stack trace.
I can reproduce it as many times I want, like this:


ohumbel at WIN-B8PK3J3J70Q ~
$ cd /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles/

ohumbel at WIN-B8PK3J3J70Q /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles
$ make clean-langtools
Cleaning langtools build artifacts ... done

ohumbel at WIN-B8PK3J3J70Q /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles
$ make langtools-only
Building OpenJDK for target 'langtools-only' in configuration
'windows-x86_64-normal-server-release
            '

## Starting langtools
Compiling 2 files for BUILD_TOOLS
Compiling 23 properties into resource bundles
Compiling 673 files for BUILD_BOOTSTRAP_LANGTOOLS
Creating langtools/dist/bootstrap/lib/javac.jar
Compiling 676 files for BUILD_FULL_JAVAC
Creating langtools/dist/lib/classes.jar
java.io.FileNotFoundException:
com\sun\tools\doclets\internal\toolkit\resources\background.gif (Access is
denied)
        at java.io.FileInputStream.open(Native Method)
        at java.io.FileInputStream.<init>(FileInputStream.java:138)
        at sun.tools.jar.Main.copy(Main.java:791)
        at sun.tools.jar.Main.addFile(Main.java:740)
        at sun.tools.jar.Main.update(Main.java:592)
        at sun.tools.jar.Main.run(Main.java:223)
        at sun.tools.jar.Main.main(Main.java:1177)
BuildLangtools.gmk:186: recipe for target
`/cygdrive/c/OpenJDK/jdk8_tl/build/windows-x86_64-normal-server-release/langtools/dist/lib/classes.jar'
failed
make[1]: ***
[/cygdrive/c/OpenJDK/jdk8_tl/build/windows-x86_64-normal-server-release/langtools/dist/lib/classes.jar]
Error 1
/cygdrive/c/OpenJDK/jdk8_tl/common/makefiles//Main.gmk:75: recipe for
target `langtools-only' failed
make: *** [langtools-only] Error 2


Interestingly, it is always the same background.gif which appears in the
error message.
>From the above mentioned mail thread I guess that this could have something
to to with Security Software (Anti-Virus, ...)
I use Microsoft Security Essentials and
 - disabled all real time access
 - excluded the whole jdk folder
 - excluded the whole cygwin folder
, but without any effect.

Hopefully somebody on this list has a tip what I could try next.

Thanks in advance, and best wishes,
Oti.


PS.
I am running a VM inside VMware Fusion on a Macbook Air


From kelly.ohair at oracle.com  Mon Nov 19 11:47:21 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Mon, 19 Nov 2012 11:47:21 -0800
Subject: Access denied on Windows7 64bit
In-Reply-To: <CACDaqRCoFcz98tRoEUx5hgDTDSwEQqmWmniNe_Yvwym2Oj1H2A@mail.gmail.com>
References: <CACDaqRCoFcz98tRoEUx5hgDTDSwEQqmWmniNe_Yvwym2Oj1H2A@mail.gmail.com>
Message-ID: <EBBDD3FA-C1F7-4CF6-B36F-F4372EDAE1BC@oracle.com>

Since this appears to be some kind of file permission issue, what does 'ls -al' say on these files?

Perhaps the problem is with the hg you are using?

-kto

On Nov 19, 2012, at 9:51 AM, Oti wrote:

> Hi all,
> 
> recently I joined the AdoptOpenJDK program and started to test the new
> build on Windows.
> You can find a list what I did here:
> http://java.net/projects/adoptopenjdk/pages/BuildWindows.
> 
> The disabling of ASLR really helped: Before that I got a never ending
> hotspot build with 0% CPU load.
> Now hotspot builds just fine, thanks for the tip in
> http://mail.openjdk.java.net/pipermail/build-dev/2012-February/005594.html!
> 
> What I am stuck with now is an Access denied stack trace.
> I can reproduce it as many times I want, like this:
> 
> 
> ohumbel at WIN-B8PK3J3J70Q ~
> $ cd /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles/
> 
> ohumbel at WIN-B8PK3J3J70Q /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles
> $ make clean-langtools
> Cleaning langtools build artifacts ... done
> 
> ohumbel at WIN-B8PK3J3J70Q /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles
> $ make langtools-only
> Building OpenJDK for target 'langtools-only' in configuration
> 'windows-x86_64-normal-server-release
>            '
> 
> ## Starting langtools
> Compiling 2 files for BUILD_TOOLS
> Compiling 23 properties into resource bundles
> Compiling 673 files for BUILD_BOOTSTRAP_LANGTOOLS
> Creating langtools/dist/bootstrap/lib/javac.jar
> Compiling 676 files for BUILD_FULL_JAVAC
> Creating langtools/dist/lib/classes.jar
> java.io.FileNotFoundException:
> com\sun\tools\doclets\internal\toolkit\resources\background.gif (Access is
> denied)
>        at java.io.FileInputStream.open(Native Method)
>        at java.io.FileInputStream.<init>(FileInputStream.java:138)
>        at sun.tools.jar.Main.copy(Main.java:791)
>        at sun.tools.jar.Main.addFile(Main.java:740)
>        at sun.tools.jar.Main.update(Main.java:592)
>        at sun.tools.jar.Main.run(Main.java:223)
>        at sun.tools.jar.Main.main(Main.java:1177)
> BuildLangtools.gmk:186: recipe for target
> `/cygdrive/c/OpenJDK/jdk8_tl/build/windows-x86_64-normal-server-release/langtools/dist/lib/classes.jar'
> failed
> make[1]: ***
> [/cygdrive/c/OpenJDK/jdk8_tl/build/windows-x86_64-normal-server-release/langtools/dist/lib/classes.jar]
> Error 1
> /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles//Main.gmk:75: recipe for
> target `langtools-only' failed
> make: *** [langtools-only] Error 2
> 
> 
> Interestingly, it is always the same background.gif which appears in the
> error message.
>> From the above mentioned mail thread I guess that this could have something
> to to with Security Software (Anti-Virus, ...)
> I use Microsoft Security Essentials and
> - disabled all real time access
> - excluded the whole jdk folder
> - excluded the whole cygwin folder
> , but without any effect.
> 
> Hopefully somebody on this list has a tip what I could try next.
> 
> Thanks in advance, and best wishes,
> Oti.
> 
> 
> PS.
> I am running a VM inside VMware Fusion on a Macbook Air



From mike.duigou at oracle.com  Mon Nov 19 15:11:26 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 19 Nov 2012 15:11:26 -0800
Subject: Update to build-infra guide?
Message-ID: <3A84218F-22DD-4A31-85E4-05C0D4417AF5@oracle.com>

I'm sure it's been mentioned but I couldn't find it. I'm looking to generate api javadocs using new build and couldn't find the instructions. 

Looking at http://openjdk.java.net/projects/build-infra/guide.html it appears to be a bit out of date. Any chance it could get an update?

Mike

From erik.joelsson at oracle.com  Tue Nov 20 04:26:56 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 20 Nov 2012 12:26:56 +0000
Subject: hg: build-infra/jdk8: 2 new changesets
Message-ID: <20121120122657.D140A47A78@hg.openjdk.java.net>

Changeset: 10915c4e8ce9
Author:    erikj
Date:      2012-11-20 11:28 +0000
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/10915c4e8ce9

8001541: build-infra: Cannot build on Solaris using softlinks
Summary: Fixed test for readlink. Fixed backup implementation to work for directory only symlinks.

! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh

Changeset: 6f8d29305852
Author:    erikj
Date:      2012-11-20 12:24 +0000
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/6f8d29305852

Merge

! common/autoconf/generated-configure.sh



From erik.joelsson at oracle.com  Tue Nov 20 04:46:35 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 20 Nov 2012 13:46:35 +0100
Subject: Update to build-infra guide?
In-Reply-To: <3A84218F-22DD-4A31-85E4-05C0D4417AF5@oracle.com>
References: <3A84218F-22DD-4A31-85E4-05C0D4417AF5@oracle.com>
Message-ID: <50AB7BAB.4080008@oracle.com>

I just tried make docs and it seems to at least try doing what you would 
expect. It's not very stable though. So far I've had to rerun it once 
after failure every time I try to build it clean. I will look into it.

/Erik

On 2012-11-20 00:11, Mike Duigou wrote:
> I'm sure it's been mentioned but I couldn't find it. I'm looking to generate api javadocs using new build and couldn't find the instructions.
>
> Looking at http://openjdk.java.net/projects/build-infra/guide.html it appears to be a bit out of date. Any chance it could get an update?
>
> Mike


From ohumbel at gmail.com  Tue Nov 20 05:14:13 2012
From: ohumbel at gmail.com (Oti)
Date: Tue, 20 Nov 2012 14:14:13 +0100
Subject: Access denied on Windows7 64bit
In-Reply-To: <EBBDD3FA-C1F7-4CF6-B36F-F4372EDAE1BC@oracle.com>
References: <CACDaqRCoFcz98tRoEUx5hgDTDSwEQqmWmniNe_Yvwym2Oj1H2A@mail.gmail.com>
	<EBBDD3FA-C1F7-4CF6-B36F-F4372EDAE1BC@oracle.com>
Message-ID: <CACDaqRBBw-=KnvQyxULAgzfEXHb+QjJJRLfnf1BsUTabJefKmA@mail.gmail.com>

Kelly,

thanks for the fast response!
Wow, real file permissions - I should have thought of that ?

They look like this:
$ ls -l
./langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif
----------+ 1 ohumbel None 2313 Nov 15 08:49
./langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif

while on Ubuntu I see:
$ ls -l
./langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif
-rw-rw-r--. 1 rep rep 2313 Jul 21  2011
./langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif


I believe Tortoise is the only hg on my system:
$ python
-bash: python: command not found
$ which hg
/cygdrive/c/Program Files/TortoiseHg/hg


Changing the permissions as follows:
ohumbel at WIN-B8PK3J3J70Q/cygdrive/c/OpenJDK/jdk8_tl/langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources
$ ls -la
-rw-rw-r--+ 1 ohumbel None  2313 Nov 15 08:49 background.gif
:
-rw-rw-r--+ 1 ohumbel None 10701 Nov 15 08:49 titlebar.gif

, I get an Access denied from another directory:
java.io.FileNotFoundException:
com\sun\tools\javac\services\javax.tools.JavaCompilerTool (Access is denied)


In the archives I read that TortoiseHg solves some problems because it
provides a hg.exe. That is the reason why I installed it.
Is this still true?
If yes: How can I tell Tortoise to preserve the file permissions?

Oti.


On Mon, Nov 19, 2012 at 8:47 PM, Kelly O'Hair <kelly.ohair at oracle.com>wrote:

> Since this appears to be some kind of file permission issue, what does 'ls
> -al' say on these files?
>
> Perhaps the problem is with the hg you are using?
>
> -kto
>
> On Nov 19, 2012, at 9:51 AM, Oti wrote:
>
> > Hi all,
> >
> > recently I joined the AdoptOpenJDK program and started to test the new
> > build on Windows.
> > You can find a list what I did here:
> > http://java.net/projects/adoptopenjdk/pages/BuildWindows.
> >
> > The disabling of ASLR really helped: Before that I got a never ending
> > hotspot build with 0% CPU load.
> > Now hotspot builds just fine, thanks for the tip in
> >
> http://mail.openjdk.java.net/pipermail/build-dev/2012-February/005594.html
> !
> >
> > What I am stuck with now is an Access denied stack trace.
> > I can reproduce it as many times I want, like this:
> >
> >
> > ohumbel at WIN-B8PK3J3J70Q ~
> > $ cd /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles/
> >
> > ohumbel at WIN-B8PK3J3J70Q /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles
> > $ make clean-langtools
> > Cleaning langtools build artifacts ... done
> >
> > ohumbel at WIN-B8PK3J3J70Q /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles
> > $ make langtools-only
> > Building OpenJDK for target 'langtools-only' in configuration
> > 'windows-x86_64-normal-server-release
> >            '
> >
> > ## Starting langtools
> > Compiling 2 files for BUILD_TOOLS
> > Compiling 23 properties into resource bundles
> > Compiling 673 files for BUILD_BOOTSTRAP_LANGTOOLS
> > Creating langtools/dist/bootstrap/lib/javac.jar
> > Compiling 676 files for BUILD_FULL_JAVAC
> > Creating langtools/dist/lib/classes.jar
> > java.io.FileNotFoundException:
> > com\sun\tools\doclets\internal\toolkit\resources\background.gif (Access
> is
> > denied)
> >        at java.io.FileInputStream.open(Native Method)
> >        at java.io.FileInputStream.<init>(FileInputStream.java:138)
> >        at sun.tools.jar.Main.copy(Main.java:791)
> >        at sun.tools.jar.Main.addFile(Main.java:740)
> >        at sun.tools.jar.Main.update(Main.java:592)
> >        at sun.tools.jar.Main.run(Main.java:223)
> >        at sun.tools.jar.Main.main(Main.java:1177)
> > BuildLangtools.gmk:186: recipe for target
> >
> `/cygdrive/c/OpenJDK/jdk8_tl/build/windows-x86_64-normal-server-release/langtools/dist/lib/classes.jar'
> > failed
> > make[1]: ***
> >
> [/cygdrive/c/OpenJDK/jdk8_tl/build/windows-x86_64-normal-server-release/langtools/dist/lib/classes.jar]
> > Error 1
> > /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles//Main.gmk:75: recipe for
> > target `langtools-only' failed
> > make: *** [langtools-only] Error 2
> >
> >
> > Interestingly, it is always the same background.gif which appears in the
> > error message.
> >> From the above mentioned mail thread I guess that this could have
> something
> > to to with Security Software (Anti-Virus, ...)
> > I use Microsoft Security Essentials and
> > - disabled all real time access
> > - excluded the whole jdk folder
> > - excluded the whole cygwin folder
> > , but without any effect.
> >
> > Hopefully somebody on this list has a tip what I could try next.
> >
> > Thanks in advance, and best wishes,
> > Oti.
> >
> >
> > PS.
> > I am running a VM inside VMware Fusion on a Macbook Air
>
>


From fredrik.ohrstrom at oracle.com  Tue Nov 20 05:16:43 2012
From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com)
Date: Tue, 20 Nov 2012 13:16:43 +0000
Subject: hg: build-infra/jdk8/langtools: Synced with jdk8/tl/langtools
Message-ID: <20121120131649.441A547A7A@hg.openjdk.java.net>

Changeset: 44bb4516e229
Author:    ohrstrom
Date:      2012-11-20 14:15 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/langtools/rev/44bb4516e229

Synced with jdk8/tl/langtools

+ src/share/classes/com/sun/source/util/Plugin.java
! src/share/classes/com/sun/source/util/Trees.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/MemberSummaryWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar.gif
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar_end.gif
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/script.js
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritDocTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFile.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFileFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPath.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MethodTypes.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PathDocFileFactory.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SimpleDocFileFactory.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/util/StandardDocFileFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java
! src/share/classes/com/sun/tools/javac/api/BasicJavacTask.java
! src/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java
! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java
! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! 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/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/Pool.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javac/main/Option.java
! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/resources/javac.properties
! src/share/classes/com/sun/tools/javac/tree/Pretty.java
! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/util/Warner.java
! src/share/classes/com/sun/tools/javadoc/DocEnv.java
! src/share/classes/com/sun/tools/javadoc/DocLocale.java
! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java
! src/share/classes/com/sun/tools/javadoc/JavadocTool.java
! src/share/classes/com/sun/tools/javadoc/Messager.java
! src/share/classes/com/sun/tools/javadoc/ParamTagImpl.java
! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java
! src/share/classes/com/sun/tools/javadoc/Start.java
+ src/share/classes/com/sun/tools/javadoc/ToolOption.java
+ src/share/classes/com/sun/tools/javadoc/api/JavadocTaskImpl.java
+ src/share/classes/com/sun/tools/javadoc/api/JavadocTool.java
! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties
+ src/share/classes/javax/tools/DocumentationTool.java
! src/share/classes/javax/tools/JavaCompiler.java
! src/share/classes/javax/tools/ToolProvider.java



From fredrik.ohrstrom at oracle.com  Tue Nov 20 05:39:25 2012
From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com)
Date: Tue, 20 Nov 2012 13:39:25 +0000
Subject: hg: build-infra/jdk8/jdk: Add new Native annotation.
Message-ID: <20121120134007.07B3047A7C@hg.openjdk.java.net>

Changeset: 023dd53d697b
Author:    ohrstrom
Date:      2012-11-20 14:37 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/023dd53d697b

Add new Native annotation.

+ src/share/classes/java/lang/annotation/Native.java



From erik.joelsson at oracle.com  Tue Nov 20 05:52:43 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 20 Nov 2012 14:52:43 +0100
Subject: Access denied on Windows7 64bit
In-Reply-To: <CACDaqRBBw-=KnvQyxULAgzfEXHb+QjJJRLfnf1BsUTabJefKmA@mail.gmail.com>
References: <CACDaqRCoFcz98tRoEUx5hgDTDSwEQqmWmniNe_Yvwym2Oj1H2A@mail.gmail.com>	<EBBDD3FA-C1F7-4CF6-B36F-F4372EDAE1BC@oracle.com>
	<CACDaqRBBw-=KnvQyxULAgzfEXHb+QjJJRLfnf1BsUTabJefKmA@mail.gmail.com>
Message-ID: <50AB8B2B.4080102@oracle.com>

I don't know how to solve this, but I can confirm that I'm using 
tortoisehg and cygwin on a windows 7 x64 system and building 
successfully with both old and new build system. We have seen different 
issues on some machines concerning file permissions though. A bit of 
googling led me to this page http://www.cygwin.com/cygwin-ug-net/ntsec.html
Maybe something to investigate?

/Erik

On 2012-11-20 14:14, Oti wrote:
> Kelly,
>
> thanks for the fast response!
> Wow, real file permissions - I should have thought of that ?
>
> They look like this:
> $ ls -l
> ./langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif
> ----------+ 1 ohumbel None 2313 Nov 15 08:49
> ./langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif
>
> while on Ubuntu I see:
> $ ls -l
> ./langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif
> -rw-rw-r--. 1 rep rep 2313 Jul 21  2011
> ./langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif
>
>
> I believe Tortoise is the only hg on my system:
> $ python
> -bash: python: command not found
> $ which hg
> /cygdrive/c/Program Files/TortoiseHg/hg
>
>
> Changing the permissions as follows:
> ohumbel at WIN-B8PK3J3J70Q/cygdrive/c/OpenJDK/jdk8_tl/langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources
> $ ls -la
> -rw-rw-r--+ 1 ohumbel None  2313 Nov 15 08:49 background.gif
> :
> -rw-rw-r--+ 1 ohumbel None 10701 Nov 15 08:49 titlebar.gif
>
> , I get an Access denied from another directory:
> java.io.FileNotFoundException:
> com\sun\tools\javac\services\javax.tools.JavaCompilerTool (Access is denied)
>
>
> In the archives I read that TortoiseHg solves some problems because it
> provides a hg.exe. That is the reason why I installed it.
> Is this still true?
> If yes: How can I tell Tortoise to preserve the file permissions?
>
> Oti.
>
>
> On Mon, Nov 19, 2012 at 8:47 PM, Kelly O'Hair<kelly.ohair at oracle.com>wrote:
>
>> Since this appears to be some kind of file permission issue, what does 'ls
>> -al' say on these files?
>>
>> Perhaps the problem is with the hg you are using?
>>
>> -kto
>>
>> On Nov 19, 2012, at 9:51 AM, Oti wrote:
>>
>>> Hi all,
>>>
>>> recently I joined the AdoptOpenJDK program and started to test the new
>>> build on Windows.
>>> You can find a list what I did here:
>>> http://java.net/projects/adoptopenjdk/pages/BuildWindows.
>>>
>>> The disabling of ASLR really helped: Before that I got a never ending
>>> hotspot build with 0% CPU load.
>>> Now hotspot builds just fine, thanks for the tip in
>>>
>> http://mail.openjdk.java.net/pipermail/build-dev/2012-February/005594.html
>> !
>>> What I am stuck with now is an Access denied stack trace.
>>> I can reproduce it as many times I want, like this:
>>>
>>>
>>> ohumbel at WIN-B8PK3J3J70Q ~
>>> $ cd /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles/
>>>
>>> ohumbel at WIN-B8PK3J3J70Q /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles
>>> $ make clean-langtools
>>> Cleaning langtools build artifacts ... done
>>>
>>> ohumbel at WIN-B8PK3J3J70Q /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles
>>> $ make langtools-only
>>> Building OpenJDK for target 'langtools-only' in configuration
>>> 'windows-x86_64-normal-server-release
>>>             '
>>>
>>> ## Starting langtools
>>> Compiling 2 files for BUILD_TOOLS
>>> Compiling 23 properties into resource bundles
>>> Compiling 673 files for BUILD_BOOTSTRAP_LANGTOOLS
>>> Creating langtools/dist/bootstrap/lib/javac.jar
>>> Compiling 676 files for BUILD_FULL_JAVAC
>>> Creating langtools/dist/lib/classes.jar
>>> java.io.FileNotFoundException:
>>> com\sun\tools\doclets\internal\toolkit\resources\background.gif (Access
>> is
>>> denied)
>>>         at java.io.FileInputStream.open(Native Method)
>>>         at java.io.FileInputStream.<init>(FileInputStream.java:138)
>>>         at sun.tools.jar.Main.copy(Main.java:791)
>>>         at sun.tools.jar.Main.addFile(Main.java:740)
>>>         at sun.tools.jar.Main.update(Main.java:592)
>>>         at sun.tools.jar.Main.run(Main.java:223)
>>>         at sun.tools.jar.Main.main(Main.java:1177)
>>> BuildLangtools.gmk:186: recipe for target
>>>
>> `/cygdrive/c/OpenJDK/jdk8_tl/build/windows-x86_64-normal-server-release/langtools/dist/lib/classes.jar'
>>> failed
>>> make[1]: ***
>>>
>> [/cygdrive/c/OpenJDK/jdk8_tl/build/windows-x86_64-normal-server-release/langtools/dist/lib/classes.jar]
>>> Error 1
>>> /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles//Main.gmk:75: recipe for
>>> target `langtools-only' failed
>>> make: *** [langtools-only] Error 2
>>>
>>>
>>> Interestingly, it is always the same background.gif which appears in the
>>> error message.
>>>>  From the above mentioned mail thread I guess that this could have
>> something
>>> to to with Security Software (Anti-Virus, ...)
>>> I use Microsoft Security Essentials and
>>> - disabled all real time access
>>> - excluded the whole jdk folder
>>> - excluded the whole cygwin folder
>>> , but without any effect.
>>>
>>> Hopefully somebody on this list has a tip what I could try next.
>>>
>>> Thanks in advance, and best wishes,
>>> Oti.
>>>
>>>
>>> PS.
>>> I am running a VM inside VMware Fusion on a Macbook Air
>>


From staffan.larsen at oracle.com  Tue Nov 20 05:57:44 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 20 Nov 2012 14:57:44 +0100
Subject: Access denied on Windows7 64bit
In-Reply-To: <CACDaqRBBw-=KnvQyxULAgzfEXHb+QjJJRLfnf1BsUTabJefKmA@mail.gmail.com>
References: <CACDaqRCoFcz98tRoEUx5hgDTDSwEQqmWmniNe_Yvwym2Oj1H2A@mail.gmail.com>
	<EBBDD3FA-C1F7-4CF6-B36F-F4372EDAE1BC@oracle.com>
	<CACDaqRBBw-=KnvQyxULAgzfEXHb+QjJJRLfnf1BsUTabJefKmA@mail.gmail.com>
Message-ID: <3929F0C1-DC30-4DF6-91C6-6719A39E41A5@oracle.com>

I know that I have had to create an empty directory, make sure it has all permissions for everyone in windows, make sure subdirectories inherit permissions, and only then sync out the source to this directory. Not sure this helps you, but thought I would mention it.

/Staffan

On 20 nov 2012, at 14:14, Oti <ohumbel at gmail.com> wrote:

> Kelly,
> 
> thanks for the fast response!
> Wow, real file permissions - I should have thought of that ?
> 
> They look like this:
> $ ls -l
> ./langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif
> ----------+ 1 ohumbel None 2313 Nov 15 08:49
> ./langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif
> 
> while on Ubuntu I see:
> $ ls -l
> ./langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif
> -rw-rw-r--. 1 rep rep 2313 Jul 21  2011
> ./langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif
> 
> 
> I believe Tortoise is the only hg on my system:
> $ python
> -bash: python: command not found
> $ which hg
> /cygdrive/c/Program Files/TortoiseHg/hg
> 
> 
> Changing the permissions as follows:
> ohumbel at WIN-B8PK3J3J70Q/cygdrive/c/OpenJDK/jdk8_tl/langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources
> $ ls -la
> -rw-rw-r--+ 1 ohumbel None  2313 Nov 15 08:49 background.gif
> :
> -rw-rw-r--+ 1 ohumbel None 10701 Nov 15 08:49 titlebar.gif
> 
> , I get an Access denied from another directory:
> java.io.FileNotFoundException:
> com\sun\tools\javac\services\javax.tools.JavaCompilerTool (Access is denied)
> 
> 
> In the archives I read that TortoiseHg solves some problems because it
> provides a hg.exe. That is the reason why I installed it.
> Is this still true?
> If yes: How can I tell Tortoise to preserve the file permissions?
> 
> Oti.
> 
> 
> On Mon, Nov 19, 2012 at 8:47 PM, Kelly O'Hair <kelly.ohair at oracle.com>wrote:
> 
>> Since this appears to be some kind of file permission issue, what does 'ls
>> -al' say on these files?
>> 
>> Perhaps the problem is with the hg you are using?
>> 
>> -kto
>> 
>> On Nov 19, 2012, at 9:51 AM, Oti wrote:
>> 
>>> Hi all,
>>> 
>>> recently I joined the AdoptOpenJDK program and started to test the new
>>> build on Windows.
>>> You can find a list what I did here:
>>> http://java.net/projects/adoptopenjdk/pages/BuildWindows.
>>> 
>>> The disabling of ASLR really helped: Before that I got a never ending
>>> hotspot build with 0% CPU load.
>>> Now hotspot builds just fine, thanks for the tip in
>>> 
>> http://mail.openjdk.java.net/pipermail/build-dev/2012-February/005594.html
>> !
>>> 
>>> What I am stuck with now is an Access denied stack trace.
>>> I can reproduce it as many times I want, like this:
>>> 
>>> 
>>> ohumbel at WIN-B8PK3J3J70Q ~
>>> $ cd /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles/
>>> 
>>> ohumbel at WIN-B8PK3J3J70Q /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles
>>> $ make clean-langtools
>>> Cleaning langtools build artifacts ... done
>>> 
>>> ohumbel at WIN-B8PK3J3J70Q /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles
>>> $ make langtools-only
>>> Building OpenJDK for target 'langtools-only' in configuration
>>> 'windows-x86_64-normal-server-release
>>>           '
>>> 
>>> ## Starting langtools
>>> Compiling 2 files for BUILD_TOOLS
>>> Compiling 23 properties into resource bundles
>>> Compiling 673 files for BUILD_BOOTSTRAP_LANGTOOLS
>>> Creating langtools/dist/bootstrap/lib/javac.jar
>>> Compiling 676 files for BUILD_FULL_JAVAC
>>> Creating langtools/dist/lib/classes.jar
>>> java.io.FileNotFoundException:
>>> com\sun\tools\doclets\internal\toolkit\resources\background.gif (Access
>> is
>>> denied)
>>>       at java.io.FileInputStream.open(Native Method)
>>>       at java.io.FileInputStream.<init>(FileInputStream.java:138)
>>>       at sun.tools.jar.Main.copy(Main.java:791)
>>>       at sun.tools.jar.Main.addFile(Main.java:740)
>>>       at sun.tools.jar.Main.update(Main.java:592)
>>>       at sun.tools.jar.Main.run(Main.java:223)
>>>       at sun.tools.jar.Main.main(Main.java:1177)
>>> BuildLangtools.gmk:186: recipe for target
>>> 
>> `/cygdrive/c/OpenJDK/jdk8_tl/build/windows-x86_64-normal-server-release/langtools/dist/lib/classes.jar'
>>> failed
>>> make[1]: ***
>>> 
>> [/cygdrive/c/OpenJDK/jdk8_tl/build/windows-x86_64-normal-server-release/langtools/dist/lib/classes.jar]
>>> Error 1
>>> /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles//Main.gmk:75: recipe for
>>> target `langtools-only' failed
>>> make: *** [langtools-only] Error 2
>>> 
>>> 
>>> Interestingly, it is always the same background.gif which appears in the
>>> error message.
>>>> From the above mentioned mail thread I guess that this could have
>> something
>>> to to with Security Software (Anti-Virus, ...)
>>> I use Microsoft Security Essentials and
>>> - disabled all real time access
>>> - excluded the whole jdk folder
>>> - excluded the whole cygwin folder
>>> , but without any effect.
>>> 
>>> Hopefully somebody on this list has a tip what I could try next.
>>> 
>>> Thanks in advance, and best wishes,
>>> Oti.
>>> 
>>> 
>>> PS.
>>> I am running a VM inside VMware Fusion on a Macbook Air
>> 
>> 



From erik.joelsson at oracle.com  Tue Nov 20 07:10:26 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 20 Nov 2012 16:10:26 +0100
Subject: Access denied on Windows7 64bit
In-Reply-To: <3929F0C1-DC30-4DF6-91C6-6719A39E41A5@oracle.com>
References: <CACDaqRCoFcz98tRoEUx5hgDTDSwEQqmWmniNe_Yvwym2Oj1H2A@mail.gmail.com>	<EBBDD3FA-C1F7-4CF6-B36F-F4372EDAE1BC@oracle.com>	<CACDaqRBBw-=KnvQyxULAgzfEXHb+QjJJRLfnf1BsUTabJefKmA@mail.gmail.com>
	<3929F0C1-DC30-4DF6-91C6-6719A39E41A5@oracle.com>
Message-ID: <50AB9D62.3020603@oracle.com>

After reading this, I think I vaguely remember someone saying something 
about creating the directory in cygwin, not explorer. I did an 
experiment based on this. Using explorer, I created a directory 
"testdir" in c:\. I then opened a cygwin terminal and CDd into it and 
did a hg clone. Both c:\testdir and all the files I cloned showed 
permissions in cygwin as ---------+. Then, in the cygwin terminal, I 
created c:\testdir2 and cloned in there. All the files in there got 
-rwxr-xr-x+. It seems that could be the solution.

/Erik

On 2012-11-20 14:57, Staffan Larsen wrote:
> I know that I have had to create an empty directory, make sure it has all permissions for everyone in windows, make sure subdirectories inherit permissions, and only then sync out the source to this directory. Not sure this helps you, but thought I would mention it.
>
> /Staffan
>
> On 20 nov 2012, at 14:14, Oti<ohumbel at gmail.com>  wrote:
>
>> Kelly,
>>
>> thanks for the fast response!
>> Wow, real file permissions - I should have thought of that ?
>>
>> They look like this:
>> $ ls -l
>> ./langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif
>> ----------+ 1 ohumbel None 2313 Nov 15 08:49
>> ./langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif
>>
>> while on Ubuntu I see:
>> $ ls -l
>> ./langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif
>> -rw-rw-r--. 1 rep rep 2313 Jul 21  2011
>> ./langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif
>>
>>
>> I believe Tortoise is the only hg on my system:
>> $ python
>> -bash: python: command not found
>> $ which hg
>> /cygdrive/c/Program Files/TortoiseHg/hg
>>
>>
>> Changing the permissions as follows:
>> ohumbel at WIN-B8PK3J3J70Q/cygdrive/c/OpenJDK/jdk8_tl/langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources
>> $ ls -la
>> -rw-rw-r--+ 1 ohumbel None  2313 Nov 15 08:49 background.gif
>> :
>> -rw-rw-r--+ 1 ohumbel None 10701 Nov 15 08:49 titlebar.gif
>>
>> , I get an Access denied from another directory:
>> java.io.FileNotFoundException:
>> com\sun\tools\javac\services\javax.tools.JavaCompilerTool (Access is denied)
>>
>>
>> In the archives I read that TortoiseHg solves some problems because it
>> provides a hg.exe. That is the reason why I installed it.
>> Is this still true?
>> If yes: How can I tell Tortoise to preserve the file permissions?
>>
>> Oti.
>>
>>
>> On Mon, Nov 19, 2012 at 8:47 PM, Kelly O'Hair<kelly.ohair at oracle.com>wrote:
>>
>>> Since this appears to be some kind of file permission issue, what does 'ls
>>> -al' say on these files?
>>>
>>> Perhaps the problem is with the hg you are using?
>>>
>>> -kto
>>>
>>> On Nov 19, 2012, at 9:51 AM, Oti wrote:
>>>
>>>> Hi all,
>>>>
>>>> recently I joined the AdoptOpenJDK program and started to test the new
>>>> build on Windows.
>>>> You can find a list what I did here:
>>>> http://java.net/projects/adoptopenjdk/pages/BuildWindows.
>>>>
>>>> The disabling of ASLR really helped: Before that I got a never ending
>>>> hotspot build with 0% CPU load.
>>>> Now hotspot builds just fine, thanks for the tip in
>>>>
>>> http://mail.openjdk.java.net/pipermail/build-dev/2012-February/005594.html
>>> !
>>>> What I am stuck with now is an Access denied stack trace.
>>>> I can reproduce it as many times I want, like this:
>>>>
>>>>
>>>> ohumbel at WIN-B8PK3J3J70Q ~
>>>> $ cd /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles/
>>>>
>>>> ohumbel at WIN-B8PK3J3J70Q /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles
>>>> $ make clean-langtools
>>>> Cleaning langtools build artifacts ... done
>>>>
>>>> ohumbel at WIN-B8PK3J3J70Q /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles
>>>> $ make langtools-only
>>>> Building OpenJDK for target 'langtools-only' in configuration
>>>> 'windows-x86_64-normal-server-release
>>>>            '
>>>>
>>>> ## Starting langtools
>>>> Compiling 2 files for BUILD_TOOLS
>>>> Compiling 23 properties into resource bundles
>>>> Compiling 673 files for BUILD_BOOTSTRAP_LANGTOOLS
>>>> Creating langtools/dist/bootstrap/lib/javac.jar
>>>> Compiling 676 files for BUILD_FULL_JAVAC
>>>> Creating langtools/dist/lib/classes.jar
>>>> java.io.FileNotFoundException:
>>>> com\sun\tools\doclets\internal\toolkit\resources\background.gif (Access
>>> is
>>>> denied)
>>>>        at java.io.FileInputStream.open(Native Method)
>>>>        at java.io.FileInputStream.<init>(FileInputStream.java:138)
>>>>        at sun.tools.jar.Main.copy(Main.java:791)
>>>>        at sun.tools.jar.Main.addFile(Main.java:740)
>>>>        at sun.tools.jar.Main.update(Main.java:592)
>>>>        at sun.tools.jar.Main.run(Main.java:223)
>>>>        at sun.tools.jar.Main.main(Main.java:1177)
>>>> BuildLangtools.gmk:186: recipe for target
>>>>
>>> `/cygdrive/c/OpenJDK/jdk8_tl/build/windows-x86_64-normal-server-release/langtools/dist/lib/classes.jar'
>>>> failed
>>>> make[1]: ***
>>>>
>>> [/cygdrive/c/OpenJDK/jdk8_tl/build/windows-x86_64-normal-server-release/langtools/dist/lib/classes.jar]
>>>> Error 1
>>>> /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles//Main.gmk:75: recipe for
>>>> target `langtools-only' failed
>>>> make: *** [langtools-only] Error 2
>>>>
>>>>
>>>> Interestingly, it is always the same background.gif which appears in the
>>>> error message.
>>>>>  From the above mentioned mail thread I guess that this could have
>>> something
>>>> to to with Security Software (Anti-Virus, ...)
>>>> I use Microsoft Security Essentials and
>>>> - disabled all real time access
>>>> - excluded the whole jdk folder
>>>> - excluded the whole cygwin folder
>>>> , but without any effect.
>>>>
>>>> Hopefully somebody on this list has a tip what I could try next.
>>>>
>>>> Thanks in advance, and best wishes,
>>>> Oti.
>>>>
>>>>
>>>> PS.
>>>> I am running a VM inside VMware Fusion on a Macbook Air
>>>


From kelly.ohair at oracle.com  Tue Nov 20 07:12:34 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 20 Nov 2012 07:12:34 -0800
Subject: Access denied on Windows7 64bit
In-Reply-To: <3929F0C1-DC30-4DF6-91C6-6719A39E41A5@oracle.com>
References: <CACDaqRCoFcz98tRoEUx5hgDTDSwEQqmWmniNe_Yvwym2Oj1H2A@mail.gmail.com>
	<EBBDD3FA-C1F7-4CF6-B36F-F4372EDAE1BC@oracle.com>
	<CACDaqRBBw-=KnvQyxULAgzfEXHb+QjJJRLfnf1BsUTabJefKmA@mail.gmail.com>
	<3929F0C1-DC30-4DF6-91C6-6719A39E41A5@oracle.com>
Message-ID: <EE074D0B-B78D-4729-A096-08D36BB2A174@oracle.com>

Yes, that seems to be something I remember too.
The directory where you create your clone is what defines all permissions for some reason.

-kto

On Nov 20, 2012, at 5:57 AM, Staffan Larsen wrote:

> I know that I have had to create an empty directory, make sure it has all permissions for everyone in windows, make sure subdirectories inherit permissions, and only then sync out the source to this directory. Not sure this helps you, but thought I would mention it.
> 
> /Staffan
> 
> On 20 nov 2012, at 14:14, Oti <ohumbel at gmail.com> wrote:
> 
>> Kelly,
>> 
>> thanks for the fast response!
>> Wow, real file permissions - I should have thought of that ?
>> 
>> They look like this:
>> $ ls -l
>> ./langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif
>> ----------+ 1 ohumbel None 2313 Nov 15 08:49
>> ./langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif
>> 
>> while on Ubuntu I see:
>> $ ls -l
>> ./langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif
>> -rw-rw-r--. 1 rep rep 2313 Jul 21  2011
>> ./langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif
>> 
>> 
>> I believe Tortoise is the only hg on my system:
>> $ python
>> -bash: python: command not found
>> $ which hg
>> /cygdrive/c/Program Files/TortoiseHg/hg
>> 
>> 
>> Changing the permissions as follows:
>> ohumbel at WIN-B8PK3J3J70Q/cygdrive/c/OpenJDK/jdk8_tl/langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources
>> $ ls -la
>> -rw-rw-r--+ 1 ohumbel None  2313 Nov 15 08:49 background.gif
>> :
>> -rw-rw-r--+ 1 ohumbel None 10701 Nov 15 08:49 titlebar.gif
>> 
>> , I get an Access denied from another directory:
>> java.io.FileNotFoundException:
>> com\sun\tools\javac\services\javax.tools.JavaCompilerTool (Access is denied)
>> 
>> 
>> In the archives I read that TortoiseHg solves some problems because it
>> provides a hg.exe. That is the reason why I installed it.
>> Is this still true?
>> If yes: How can I tell Tortoise to preserve the file permissions?
>> 
>> Oti.
>> 
>> 
>> On Mon, Nov 19, 2012 at 8:47 PM, Kelly O'Hair <kelly.ohair at oracle.com>wrote:
>> 
>>> Since this appears to be some kind of file permission issue, what does 'ls
>>> -al' say on these files?
>>> 
>>> Perhaps the problem is with the hg you are using?
>>> 
>>> -kto
>>> 
>>> On Nov 19, 2012, at 9:51 AM, Oti wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> recently I joined the AdoptOpenJDK program and started to test the new
>>>> build on Windows.
>>>> You can find a list what I did here:
>>>> http://java.net/projects/adoptopenjdk/pages/BuildWindows.
>>>> 
>>>> The disabling of ASLR really helped: Before that I got a never ending
>>>> hotspot build with 0% CPU load.
>>>> Now hotspot builds just fine, thanks for the tip in
>>>> 
>>> http://mail.openjdk.java.net/pipermail/build-dev/2012-February/005594.html
>>> !
>>>> 
>>>> What I am stuck with now is an Access denied stack trace.
>>>> I can reproduce it as many times I want, like this:
>>>> 
>>>> 
>>>> ohumbel at WIN-B8PK3J3J70Q ~
>>>> $ cd /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles/
>>>> 
>>>> ohumbel at WIN-B8PK3J3J70Q /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles
>>>> $ make clean-langtools
>>>> Cleaning langtools build artifacts ... done
>>>> 
>>>> ohumbel at WIN-B8PK3J3J70Q /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles
>>>> $ make langtools-only
>>>> Building OpenJDK for target 'langtools-only' in configuration
>>>> 'windows-x86_64-normal-server-release
>>>>          '
>>>> 
>>>> ## Starting langtools
>>>> Compiling 2 files for BUILD_TOOLS
>>>> Compiling 23 properties into resource bundles
>>>> Compiling 673 files for BUILD_BOOTSTRAP_LANGTOOLS
>>>> Creating langtools/dist/bootstrap/lib/javac.jar
>>>> Compiling 676 files for BUILD_FULL_JAVAC
>>>> Creating langtools/dist/lib/classes.jar
>>>> java.io.FileNotFoundException:
>>>> com\sun\tools\doclets\internal\toolkit\resources\background.gif (Access
>>> is
>>>> denied)
>>>>      at java.io.FileInputStream.open(Native Method)
>>>>      at java.io.FileInputStream.<init>(FileInputStream.java:138)
>>>>      at sun.tools.jar.Main.copy(Main.java:791)
>>>>      at sun.tools.jar.Main.addFile(Main.java:740)
>>>>      at sun.tools.jar.Main.update(Main.java:592)
>>>>      at sun.tools.jar.Main.run(Main.java:223)
>>>>      at sun.tools.jar.Main.main(Main.java:1177)
>>>> BuildLangtools.gmk:186: recipe for target
>>>> 
>>> `/cygdrive/c/OpenJDK/jdk8_tl/build/windows-x86_64-normal-server-release/langtools/dist/lib/classes.jar'
>>>> failed
>>>> make[1]: ***
>>>> 
>>> [/cygdrive/c/OpenJDK/jdk8_tl/build/windows-x86_64-normal-server-release/langtools/dist/lib/classes.jar]
>>>> Error 1
>>>> /cygdrive/c/OpenJDK/jdk8_tl/common/makefiles//Main.gmk:75: recipe for
>>>> target `langtools-only' failed
>>>> make: *** [langtools-only] Error 2
>>>> 
>>>> 
>>>> Interestingly, it is always the same background.gif which appears in the
>>>> error message.
>>>>> From the above mentioned mail thread I guess that this could have
>>> something
>>>> to to with Security Software (Anti-Virus, ...)
>>>> I use Microsoft Security Essentials and
>>>> - disabled all real time access
>>>> - excluded the whole jdk folder
>>>> - excluded the whole cygwin folder
>>>> , but without any effect.
>>>> 
>>>> Hopefully somebody on this list has a tip what I could try next.
>>>> 
>>>> Thanks in advance, and best wishes,
>>>> Oti.
>>>> 
>>>> 
>>>> PS.
>>>> I am running a VM inside VMware Fusion on a Macbook Air
>>> 
>>> 
> 



From fredrik.ohrstrom at oracle.com  Tue Nov 20 07:44:43 2012
From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com)
Date: Tue, 20 Nov 2012 15:44:43 +0000
Subject: hg: build-infra/jdk8/jdk: Make use of @Native annotation for base
	classes.
Message-ID: <20121120154506.4E63B47A86@hg.openjdk.java.net>

Changeset: 9fe81cc79176
Author:    ohrstrom
Date:      2012-11-20 15:09 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/9fe81cc79176

Make use of @Native annotation for base classes.

! makefiles/CompileJavaClasses.gmk
! src/share/classes/java/io/FileSystem.java
! src/share/classes/java/lang/Integer.java
! src/share/classes/java/lang/Long.java
! src/share/classes/java/net/SocketOptions.java
! src/share/classes/sun/nio/ch/IOStatus.java
! src/windows/classes/sun/nio/ch/PollArrayWrapper.java



From ohumbel at gmail.com  Tue Nov 20 07:48:21 2012
From: ohumbel at gmail.com (Oti)
Date: Tue, 20 Nov 2012 16:48:21 +0100
Subject: Access denied on Windows7 64bit
In-Reply-To: <50AB9D62.3020603@oracle.com>
References: <CACDaqRCoFcz98tRoEUx5hgDTDSwEQqmWmniNe_Yvwym2Oj1H2A@mail.gmail.com>
	<EBBDD3FA-C1F7-4CF6-B36F-F4372EDAE1BC@oracle.com>
	<CACDaqRBBw-=KnvQyxULAgzfEXHb+QjJJRLfnf1BsUTabJefKmA@mail.gmail.com>
	<3929F0C1-DC30-4DF6-91C6-6719A39E41A5@oracle.com>
	<50AB9D62.3020603@oracle.com>
Message-ID: <CACDaqRCC+7t+sdCrBqf6ScQpbKAtdVsTrjxOz+9cCJB6ZxCCOA@mail.gmail.com>

Yes,
that is exactly what my experiments just showed as well :-)

thx
Oti.


On Tue, Nov 20, 2012 at 4:10 PM, Erik Joelsson <erik.joelsson at oracle.com>wrote:

> After reading this, I think I vaguely remember someone saying something
> about creating the directory in cygwin, not explorer. I did an experiment
> based on this. Using explorer, I created a directory "testdir" in c:\. I
> then opened a cygwin terminal and CDd into it and did a hg clone. Both
> c:\testdir and all the files I cloned showed permissions in cygwin as
> ---------+. Then, in the cygwin terminal, I created c:\testdir2 and cloned
> in there. All the files in there got -rwxr-xr-x+. It seems that could be
> the solution.
>
> /Erik
>
>
> On 2012-11-20 14:57, Staffan Larsen wrote:
>
>> I know that I have had to create an empty directory, make sure it has all
>> permissions for everyone in windows, make sure subdirectories inherit
>> permissions, and only then sync out the source to this directory. Not sure
>> this helps you, but thought I would mention it.
>>
>> /Staffan
>>
>> On 20 nov 2012, at 14:14, Oti<ohumbel at gmail.com>  wrote:
>>
>>  Kelly,
>>>
>>> thanks for the fast response!
>>> Wow, real file permissions - I should have thought of that ?
>>>
>>> They look like this:
>>> $ ls -l
>>> ./langtools/src/share/classes/**com/sun/tools/doclets/**
>>> internal/toolkit/resources/**background.gif
>>> ----------+ 1 ohumbel None 2313 Nov 15 08:49
>>> ./langtools/src/share/classes/**com/sun/tools/doclets/**
>>> internal/toolkit/resources/**background.gif
>>>
>>> while on Ubuntu I see:
>>> $ ls -l
>>> ./langtools/src/share/classes/**com/sun/tools/doclets/**
>>> internal/toolkit/resources/**background.gif
>>> -rw-rw-r--. 1 rep rep 2313 Jul 21  2011
>>> ./langtools/src/share/classes/**com/sun/tools/doclets/**
>>> internal/toolkit/resources/**background.gif
>>>
>>>
>>> I believe Tortoise is the only hg on my system:
>>> $ python
>>> -bash: python: command not found
>>> $ which hg
>>> /cygdrive/c/Program Files/TortoiseHg/hg
>>>
>>>
>>> Changing the permissions as follows:
>>> ohumbel at WIN-B8PK3J3J70Q/**cygdrive/c/OpenJDK/jdk8_tl/**
>>> langtools/src/share/classes/**com/sun/tools/doclets/**
>>> internal/toolkit/resources
>>> $ ls -la
>>> -rw-rw-r--+ 1 ohumbel None  2313 Nov 15 08:49 background.gif
>>> :
>>> -rw-rw-r--+ 1 ohumbel None 10701 Nov 15 08:49 titlebar.gif
>>>
>>> , I get an Access denied from another directory:
>>> java.io.FileNotFoundException:
>>> com\sun\tools\javac\services\**javax.tools.JavaCompilerTool (Access is
>>> denied)
>>>
>>>
>>> In the archives I read that TortoiseHg solves some problems because it
>>> provides a hg.exe. That is the reason why I installed it.
>>> Is this still true?
>>> If yes: How can I tell Tortoise to preserve the file permissions?
>>>
>>> Oti.
>>>
>>>
>>> On Mon, Nov 19, 2012 at 8:47 PM, Kelly O'Hair<kelly.ohair at oracle.com>**
>>> wrote:
>>>
>>>  Since this appears to be some kind of file permission issue, what does
>>>> 'ls
>>>> -al' say on these files?
>>>>
>>>> Perhaps the problem is with the hg you are using?
>>>>
>>>> -kto
>>>>
>>>> On Nov 19, 2012, at 9:51 AM, Oti wrote:
>>>>
>>>>  Hi all,
>>>>>
>>>>> recently I joined the AdoptOpenJDK program and started to test the new
>>>>> build on Windows.
>>>>> You can find a list what I did here:
>>>>> http://java.net/projects/**adoptopenjdk/pages/**BuildWindows<http://java.net/projects/adoptopenjdk/pages/BuildWindows>
>>>>> .
>>>>>
>>>>> The disabling of ASLR really helped: Before that I got a never ending
>>>>> hotspot build with 0% CPU load.
>>>>> Now hotspot builds just fine, thanks for the tip in
>>>>>
>>>>>  http://mail.openjdk.java.net/**pipermail/build-dev/2012-**
>>>> February/005594.html<http://mail.openjdk.java.net/pipermail/build-dev/2012-February/005594.html>
>>>> !
>>>>
>>>>> What I am stuck with now is an Access denied stack trace.
>>>>> I can reproduce it as many times I want, like this:
>>>>>
>>>>>
>>>>> ohumbel at WIN-B8PK3J3J70Q ~
>>>>> $ cd /cygdrive/c/OpenJDK/jdk8_tl/**common/makefiles/
>>>>>
>>>>> ohumbel at WIN-B8PK3J3J70Q /cygdrive/c/OpenJDK/jdk8_tl/**common/makefiles
>>>>> $ make clean-langtools
>>>>> Cleaning langtools build artifacts ... done
>>>>>
>>>>> ohumbel at WIN-B8PK3J3J70Q /cygdrive/c/OpenJDK/jdk8_tl/**common/makefiles
>>>>> $ make langtools-only
>>>>> Building OpenJDK for target 'langtools-only' in configuration
>>>>> 'windows-x86_64-normal-server-**release
>>>>>            '
>>>>>
>>>>> ## Starting langtools
>>>>> Compiling 2 files for BUILD_TOOLS
>>>>> Compiling 23 properties into resource bundles
>>>>> Compiling 673 files for BUILD_BOOTSTRAP_LANGTOOLS
>>>>> Creating langtools/dist/bootstrap/lib/**javac.jar
>>>>> Compiling 676 files for BUILD_FULL_JAVAC
>>>>> Creating langtools/dist/lib/classes.jar
>>>>> java.io.FileNotFoundException:
>>>>> com\sun\tools\doclets\**internal\toolkit\resources\**background.gif
>>>>> (Access
>>>>>
>>>> is
>>>>
>>>>> denied)
>>>>>        at java.io.FileInputStream.open(**Native Method)
>>>>>        at java.io.FileInputStream.<init>**(FileInputStream.java:138)
>>>>>        at sun.tools.jar.Main.copy(Main.**java:791)
>>>>>        at sun.tools.jar.Main.addFile(**Main.java:740)
>>>>>        at sun.tools.jar.Main.update(**Main.java:592)
>>>>>        at sun.tools.jar.Main.run(Main.**java:223)
>>>>>        at sun.tools.jar.Main.main(Main.**java:1177)
>>>>> BuildLangtools.gmk:186: recipe for target
>>>>>
>>>>>  `/cygdrive/c/OpenJDK/jdk8_tl/**build/windows-x86_64-normal-**
>>>> server-release/langtools/dist/**lib/classes.jar'
>>>>
>>>>> failed
>>>>> make[1]: ***
>>>>>
>>>>>  [/cygdrive/c/OpenJDK/jdk8_tl/**build/windows-x86_64-normal-**
>>>> server-release/langtools/dist/**lib/classes.jar]
>>>>
>>>>> Error 1
>>>>> /cygdrive/c/OpenJDK/jdk8_tl/**common/makefiles//Main.gmk:75: recipe
>>>>> for
>>>>> target `langtools-only' failed
>>>>> make: *** [langtools-only] Error 2
>>>>>
>>>>>
>>>>> Interestingly, it is always the same background.gif which appears in
>>>>> the
>>>>> error message.
>>>>>
>>>>>>  From the above mentioned mail thread I guess that this could have
>>>>>>
>>>>> something
>>>>
>>>>> to to with Security Software (Anti-Virus, ...)
>>>>> I use Microsoft Security Essentials and
>>>>> - disabled all real time access
>>>>> - excluded the whole jdk folder
>>>>> - excluded the whole cygwin folder
>>>>> , but without any effect.
>>>>>
>>>>> Hopefully somebody on this list has a tip what I could try next.
>>>>>
>>>>> Thanks in advance, and best wishes,
>>>>> Oti.
>>>>>
>>>>>
>>>>> PS.
>>>>> I am running a VM inside VMware Fusion on a Macbook Air
>>>>>
>>>>
>>>>


From ohumbel at gmail.com  Tue Nov 20 12:23:23 2012
From: ohumbel at gmail.com (Oti)
Date: Tue, 20 Nov 2012 21:23:23 +0100
Subject: Access denied on Windows7 64bit
In-Reply-To: <CACDaqRCC+7t+sdCrBqf6ScQpbKAtdVsTrjxOz+9cCJB6ZxCCOA@mail.gmail.com>
References: <CACDaqRCoFcz98tRoEUx5hgDTDSwEQqmWmniNe_Yvwym2Oj1H2A@mail.gmail.com>
	<EBBDD3FA-C1F7-4CF6-B36F-F4372EDAE1BC@oracle.com>
	<CACDaqRBBw-=KnvQyxULAgzfEXHb+QjJJRLfnf1BsUTabJefKmA@mail.gmail.com>
	<3929F0C1-DC30-4DF6-91C6-6719A39E41A5@oracle.com>
	<50AB9D62.3020603@oracle.com>
	<CACDaqRCC+7t+sdCrBqf6ScQpbKAtdVsTrjxOz+9cCJB6ZxCCOA@mail.gmail.com>
Message-ID: <CACDaqRDGPr3+f4OXrD=CsgoQNVYA4Fk50myA+ODMBtFJnjdUuQ@mail.gmail.com>

Hi again,
how cool is that:

----- Build times -------

Start 2012-11-20 20:39:50

End   2012-11-20 21:05:26

00:01:11 corba

00:05:17 hotspot

00:01:04 jaxp

00:01:15 jaxws

00:15:22 jdk

00:01:22 langtools

00:25:36 TOTAL

-------------------------

Finished building OpenJDK for target 'all'


However, a few lines above:

utils.cpp

zip.cpp

main.c

Error: loading:
c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll

Error: loading:
c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll

Error: loading:
c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll

Error: loading:
c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll

Error: loading:
c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll

## Finished jdk (build time 00:15:22)

And the same error appears when trying to start the just built java:

ohumbel at WIN-B8PK3J3J70Q
/cygdrive/c/OpenJDK/jdk8_tl_2/build/windows-x86_64-normal-server-release/jdk/bin

$ ./java -version

openjdk version "1.8.0-internal"

OpenJDK Runtime Environment (build
1.8.0-internal-ohumbel_2012_11_20_20_38-b00)

OpenJDK 64-Bit Server VM (build 25.0-b09, mixed mode)

Error: loading:
C:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll

But the msvcr100.dll is present:

ohumbel at WIN-B8PK3J3J70Q
/cygdrive/c/OpenJDK/jdk8_tl_2/build/windows-x86_64-normal-server-release/jdk/bin

$ ls -la

total 14160

drwxr-xr-x+ 1 ohumbel None       0 Nov 20 21:05 .

drwxr-xr-x+ 1 ohumbel None       0 Nov 20 21:05 ..

-rw-r--r--  1 ohumbel None   32492 Nov 20 21:04 appletviewer.diz

-rwxr-xr-x  1 ohumbel None    9728 Nov 20 21:04 appletviewer.exe

-rw-r--r--  1 ohumbel None   54444 Nov 20 21:02 attach.diz

-rwxr-xr-x  1 ohumbel None   14848 Nov 20 21:02 attach.dll

:

-rw-r--r--  1 ohumbel None  204307 Nov 20 21:03 lcms.diz

-rwxr-xr-x  1 ohumbel None  179200 Nov 20 21:03 lcms.dll

-rw-r--r--  1 ohumbel None   90728 Nov 20 21:03 management.diz

-rwxr-xr-x  1 ohumbel None   28160 Nov 20 21:03 management.dll

-rw-r--r--  1 ohumbel None  135997 Nov 20 21:00 mlib_image.diz

-rwxr-xr-x  1 ohumbel None  646656 Nov 20 21:00 mlib_image.dll

-rwx------  1 ohumbel None  773968 Nov 20 20:55 msvcr100.dll

:

Again file permissions, or
could it be that another path should be converted to cygwin?

Oti.


On Tue, Nov 20, 2012 at 4:48 PM, Oti <ohumbel at gmail.com> wrote:

> Yes,
> that is exactly what my experiments just showed as well :-)
>
> thx
> Oti.
>
>
> On Tue, Nov 20, 2012 at 4:10 PM, Erik Joelsson <erik.joelsson at oracle.com>wrote:
>
>> After reading this, I think I vaguely remember someone saying something
>> about creating the directory in cygwin, not explorer. I did an experiment
>> based on this. Using explorer, I created a directory "testdir" in c:\. I
>> then opened a cygwin terminal and CDd into it and did a hg clone. Both
>> c:\testdir and all the files I cloned showed permissions in cygwin as
>> ---------+. Then, in the cygwin terminal, I created c:\testdir2 and cloned
>> in there. All the files in there got -rwxr-xr-x+. It seems that could be
>> the solution.
>>
>> /Erik
>>
>>
>> On 2012-11-20 14:57, Staffan Larsen wrote:
>>
>>> I know that I have had to create an empty directory, make sure it has
>>> all permissions for everyone in windows, make sure subdirectories inherit
>>> permissions, and only then sync out the source to this directory. Not sure
>>> this helps you, but thought I would mention it.
>>>
>>> /Staffan
>>>
>>> On 20 nov 2012, at 14:14, Oti<ohumbel at gmail.com>  wrote:
>>>
>>>  Kelly,
>>>>
>>>> thanks for the fast response!
>>>> Wow, real file permissions - I should have thought of that ?
>>>>
>>>> They look like this:
>>>> $ ls -l
>>>> ./langtools/src/share/classes/**com/sun/tools/doclets/**
>>>> internal/toolkit/resources/**background.gif
>>>> ----------+ 1 ohumbel None 2313 Nov 15 08:49
>>>> ./langtools/src/share/classes/**com/sun/tools/doclets/**
>>>> internal/toolkit/resources/**background.gif
>>>>
>>>> while on Ubuntu I see:
>>>> $ ls -l
>>>> ./langtools/src/share/classes/**com/sun/tools/doclets/**
>>>> internal/toolkit/resources/**background.gif
>>>> -rw-rw-r--. 1 rep rep 2313 Jul 21  2011
>>>> ./langtools/src/share/classes/**com/sun/tools/doclets/**
>>>> internal/toolkit/resources/**background.gif
>>>>
>>>>
>>>> I believe Tortoise is the only hg on my system:
>>>> $ python
>>>> -bash: python: command not found
>>>> $ which hg
>>>> /cygdrive/c/Program Files/TortoiseHg/hg
>>>>
>>>>
>>>> Changing the permissions as follows:
>>>> ohumbel at WIN-B8PK3J3J70Q/**cygdrive/c/OpenJDK/jdk8_tl/**
>>>> langtools/src/share/classes/**com/sun/tools/doclets/**
>>>> internal/toolkit/resources
>>>> $ ls -la
>>>> -rw-rw-r--+ 1 ohumbel None  2313 Nov 15 08:49 background.gif
>>>> :
>>>> -rw-rw-r--+ 1 ohumbel None 10701 Nov 15 08:49 titlebar.gif
>>>>
>>>> , I get an Access denied from another directory:
>>>> java.io.FileNotFoundException:
>>>> com\sun\tools\javac\services\**javax.tools.JavaCompilerTool (Access is
>>>> denied)
>>>>
>>>>
>>>> In the archives I read that TortoiseHg solves some problems because it
>>>> provides a hg.exe. That is the reason why I installed it.
>>>> Is this still true?
>>>> If yes: How can I tell Tortoise to preserve the file permissions?
>>>>
>>>> Oti.
>>>>
>>>>
>>>> On Mon, Nov 19, 2012 at 8:47 PM, Kelly O'Hair<kelly.ohair at oracle.com>**
>>>> wrote:
>>>>
>>>>  Since this appears to be some kind of file permission issue, what does
>>>>> 'ls
>>>>> -al' say on these files?
>>>>>
>>>>> Perhaps the problem is with the hg you are using?
>>>>>
>>>>> -kto
>>>>>
>>>>> On Nov 19, 2012, at 9:51 AM, Oti wrote:
>>>>>
>>>>>  Hi all,
>>>>>>
>>>>>> recently I joined the AdoptOpenJDK program and started to test the new
>>>>>> build on Windows.
>>>>>> You can find a list what I did here:
>>>>>> http://java.net/projects/**adoptopenjdk/pages/**BuildWindows<http://java.net/projects/adoptopenjdk/pages/BuildWindows>
>>>>>> .
>>>>>>
>>>>>> The disabling of ASLR really helped: Before that I got a never ending
>>>>>> hotspot build with 0% CPU load.
>>>>>> Now hotspot builds just fine, thanks for the tip in
>>>>>>
>>>>>>  http://mail.openjdk.java.net/**pipermail/build-dev/2012-**
>>>>> February/005594.html<http://mail.openjdk.java.net/pipermail/build-dev/2012-February/005594.html>
>>>>> !
>>>>>
>>>>>> What I am stuck with now is an Access denied stack trace.
>>>>>> I can reproduce it as many times I want, like this:
>>>>>>
>>>>>>
>>>>>> ohumbel at WIN-B8PK3J3J70Q ~
>>>>>> $ cd /cygdrive/c/OpenJDK/jdk8_tl/**common/makefiles/
>>>>>>
>>>>>> ohumbel at WIN-B8PK3J3J70Q /cygdrive/c/OpenJDK/jdk8_tl/**
>>>>>> common/makefiles
>>>>>> $ make clean-langtools
>>>>>> Cleaning langtools build artifacts ... done
>>>>>>
>>>>>> ohumbel at WIN-B8PK3J3J70Q /cygdrive/c/OpenJDK/jdk8_tl/**
>>>>>> common/makefiles
>>>>>> $ make langtools-only
>>>>>> Building OpenJDK for target 'langtools-only' in configuration
>>>>>> 'windows-x86_64-normal-server-**release
>>>>>>            '
>>>>>>
>>>>>> ## Starting langtools
>>>>>> Compiling 2 files for BUILD_TOOLS
>>>>>> Compiling 23 properties into resource bundles
>>>>>> Compiling 673 files for BUILD_BOOTSTRAP_LANGTOOLS
>>>>>> Creating langtools/dist/bootstrap/lib/**javac.jar
>>>>>> Compiling 676 files for BUILD_FULL_JAVAC
>>>>>> Creating langtools/dist/lib/classes.jar
>>>>>> java.io.FileNotFoundException:
>>>>>> com\sun\tools\doclets\**internal\toolkit\resources\**background.gif
>>>>>> (Access
>>>>>>
>>>>> is
>>>>>
>>>>>> denied)
>>>>>>        at java.io.FileInputStream.open(**Native Method)
>>>>>>        at java.io.FileInputStream.<init>**(FileInputStream.java:138)
>>>>>>        at sun.tools.jar.Main.copy(Main.**java:791)
>>>>>>        at sun.tools.jar.Main.addFile(**Main.java:740)
>>>>>>        at sun.tools.jar.Main.update(**Main.java:592)
>>>>>>        at sun.tools.jar.Main.run(Main.**java:223)
>>>>>>        at sun.tools.jar.Main.main(Main.**java:1177)
>>>>>> BuildLangtools.gmk:186: recipe for target
>>>>>>
>>>>>>  `/cygdrive/c/OpenJDK/jdk8_tl/**build/windows-x86_64-normal-**
>>>>> server-release/langtools/dist/**lib/classes.jar'
>>>>>
>>>>>> failed
>>>>>> make[1]: ***
>>>>>>
>>>>>>  [/cygdrive/c/OpenJDK/jdk8_tl/**build/windows-x86_64-normal-**
>>>>> server-release/langtools/dist/**lib/classes.jar]
>>>>>
>>>>>> Error 1
>>>>>> /cygdrive/c/OpenJDK/jdk8_tl/**common/makefiles//Main.gmk:75: recipe
>>>>>> for
>>>>>> target `langtools-only' failed
>>>>>> make: *** [langtools-only] Error 2
>>>>>>
>>>>>>
>>>>>> Interestingly, it is always the same background.gif which appears in
>>>>>> the
>>>>>> error message.
>>>>>>
>>>>>>>  From the above mentioned mail thread I guess that this could have
>>>>>>>
>>>>>> something
>>>>>
>>>>>> to to with Security Software (Anti-Virus, ...)
>>>>>> I use Microsoft Security Essentials and
>>>>>> - disabled all real time access
>>>>>> - excluded the whole jdk folder
>>>>>> - excluded the whole cygwin folder
>>>>>> , but without any effect.
>>>>>>
>>>>>> Hopefully somebody on this list has a tip what I could try next.
>>>>>>
>>>>>> Thanks in advance, and best wishes,
>>>>>> Oti.
>>>>>>
>>>>>>
>>>>>> PS.
>>>>>> I am running a VM inside VMware Fusion on a Macbook Air
>>>>>>
>>>>>
>>>>>
>


From patrick at reini.net  Tue Nov 20 12:40:46 2012
From: patrick at reini.net (Patrick Reinhart)
Date: Tue, 20 Nov 2012 21:40:46 +0100
Subject: Access denied on Windows7 64bit
In-Reply-To: <CACDaqRDGPr3+f4OXrD=CsgoQNVYA4Fk50myA+ODMBtFJnjdUuQ@mail.gmail.com>
References: <CACDaqRCoFcz98tRoEUx5hgDTDSwEQqmWmniNe_Yvwym2Oj1H2A@mail.gmail.com>
	<EBBDD3FA-C1F7-4CF6-B36F-F4372EDAE1BC@oracle.com>
	<CACDaqRBBw-=KnvQyxULAgzfEXHb+QjJJRLfnf1BsUTabJefKmA@mail.gmail.com>
	<3929F0C1-DC30-4DF6-91C6-6719A39E41A5@oracle.com>
	<50AB9D62.3020603@oracle.com>
	<CACDaqRCC+7t+sdCrBqf6ScQpbKAtdVsTrjxOz+9cCJB6ZxCCOA@mail.gmail.com>
	<CACDaqRDGPr3+f4OXrD=CsgoQNVYA4Fk50myA+ODMBtFJnjdUuQ@mail.gmail.com>
Message-ID: <9DB18954-C488-47C9-8C29-E45A617D7F50@reini.net>

Hi Oti,

Could it be that msvcr100.dll should be executable?

Cheers

Patrick 'Reini' Reinhart

Am 20.11.2012 um 21:23 schrieb Oti <ohumbel at gmail.com>:

> Hi again,
> how cool is that:
> 
> ----- Build times -------
> 
> Start 2012-11-20 20:39:50
> 
> End   2012-11-20 21:05:26
> 
> 00:01:11 corba
> 
> 00:05:17 hotspot
> 
> 00:01:04 jaxp
> 
> 00:01:15 jaxws
> 
> 00:15:22 jdk
> 
> 00:01:22 langtools
> 
> 00:25:36 TOTAL
> 
> -------------------------
> 
> Finished building OpenJDK for target 'all'
> 
> 
> However, a few lines above:
> 
> utils.cpp
> 
> zip.cpp
> 
> main.c
> 
> Error: loading:
> c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
> 
> Error: loading:
> c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
> 
> Error: loading:
> c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
> 
> Error: loading:
> c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
> 
> Error: loading:
> c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
> 
> ## Finished jdk (build time 00:15:22)
> 
> And the same error appears when trying to start the just built java:
> 
> ohumbel at WIN-B8PK3J3J70Q
> /cygdrive/c/OpenJDK/jdk8_tl_2/build/windows-x86_64-normal-server-release/jdk/bin
> 
> $ ./java -version
> 
> openjdk version "1.8.0-internal"
> 
> OpenJDK Runtime Environment (build
> 1.8.0-internal-ohumbel_2012_11_20_20_38-b00)
> 
> OpenJDK 64-Bit Server VM (build 25.0-b09, mixed mode)
> 
> Error: loading:
> C:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
> 
> But the msvcr100.dll is present:
> 
> ohumbel at WIN-B8PK3J3J70Q
> /cygdrive/c/OpenJDK/jdk8_tl_2/build/windows-x86_64-normal-server-release/jdk/bin
> 
> $ ls -la
> 
> total 14160
> 
> drwxr-xr-x+ 1 ohumbel None       0 Nov 20 21:05 .
> 
> drwxr-xr-x+ 1 ohumbel None       0 Nov 20 21:05 ..
> 
> -rw-r--r--  1 ohumbel None   32492 Nov 20 21:04 appletviewer.diz
> 
> -rwxr-xr-x  1 ohumbel None    9728 Nov 20 21:04 appletviewer.exe
> 
> -rw-r--r--  1 ohumbel None   54444 Nov 20 21:02 attach.diz
> 
> -rwxr-xr-x  1 ohumbel None   14848 Nov 20 21:02 attach.dll
> 
> :
> 
> -rw-r--r--  1 ohumbel None  204307 Nov 20 21:03 lcms.diz
> 
> -rwxr-xr-x  1 ohumbel None  179200 Nov 20 21:03 lcms.dll
> 
> -rw-r--r--  1 ohumbel None   90728 Nov 20 21:03 management.diz
> 
> -rwxr-xr-x  1 ohumbel None   28160 Nov 20 21:03 management.dll
> 
> -rw-r--r--  1 ohumbel None  135997 Nov 20 21:00 mlib_image.diz
> 
> -rwxr-xr-x  1 ohumbel None  646656 Nov 20 21:00 mlib_image.dll
> 
> -rwx------  1 ohumbel None  773968 Nov 20 20:55 msvcr100.dll
> 
> :
> 
> Again file permissions, or
> could it be that another path should be converted to cygwin?
> 
> Oti.
> 
> 
> On Tue, Nov 20, 2012 at 4:48 PM, Oti <ohumbel at gmail.com> wrote:
> 
>> Yes,
>> that is exactly what my experiments just showed as well :-)
>> 
>> thx
>> Oti.
>> 
>> 
>> On Tue, Nov 20, 2012 at 4:10 PM, Erik Joelsson <erik.joelsson at oracle.com>wrote:
>> 
>>> After reading this, I think I vaguely remember someone saying something
>>> about creating the directory in cygwin, not explorer. I did an experiment
>>> based on this. Using explorer, I created a directory "testdir" in c:\. I
>>> then opened a cygwin terminal and CDd into it and did a hg clone. Both
>>> c:\testdir and all the files I cloned showed permissions in cygwin as
>>> ---------+. Then, in the cygwin terminal, I created c:\testdir2 and cloned
>>> in there. All the files in there got -rwxr-xr-x+. It seems that could be
>>> the solution.
>>> 
>>> /Erik
>>> 
>>> 
>>> On 2012-11-20 14:57, Staffan Larsen wrote:
>>> 
>>>> I know that I have had to create an empty directory, make sure it has
>>>> all permissions for everyone in windows, make sure subdirectories inherit
>>>> permissions, and only then sync out the source to this directory. Not sure
>>>> this helps you, but thought I would mention it.
>>>> 
>>>> /Staffan
>>>> 
>>>> On 20 nov 2012, at 14:14, Oti<ohumbel at gmail.com>  wrote:
>>>> 
>>>> Kelly,
>>>>> 
>>>>> thanks for the fast response!
>>>>> Wow, real file permissions - I should have thought of that ?
>>>>> 
>>>>> They look like this:
>>>>> $ ls -l
>>>>> ./langtools/src/share/classes/**com/sun/tools/doclets/**
>>>>> internal/toolkit/resources/**background.gif
>>>>> ----------+ 1 ohumbel None 2313 Nov 15 08:49
>>>>> ./langtools/src/share/classes/**com/sun/tools/doclets/**
>>>>> internal/toolkit/resources/**background.gif
>>>>> 
>>>>> while on Ubuntu I see:
>>>>> $ ls -l
>>>>> ./langtools/src/share/classes/**com/sun/tools/doclets/**
>>>>> internal/toolkit/resources/**background.gif
>>>>> -rw-rw-r--. 1 rep rep 2313 Jul 21  2011
>>>>> ./langtools/src/share/classes/**com/sun/tools/doclets/**
>>>>> internal/toolkit/resources/**background.gif
>>>>> 
>>>>> 
>>>>> I believe Tortoise is the only hg on my system:
>>>>> $ python
>>>>> -bash: python: command not found
>>>>> $ which hg
>>>>> /cygdrive/c/Program Files/TortoiseHg/hg
>>>>> 
>>>>> 
>>>>> Changing the permissions as follows:
>>>>> ohumbel at WIN-B8PK3J3J70Q/**cygdrive/c/OpenJDK/jdk8_tl/**
>>>>> langtools/src/share/classes/**com/sun/tools/doclets/**
>>>>> internal/toolkit/resources
>>>>> $ ls -la
>>>>> -rw-rw-r--+ 1 ohumbel None  2313 Nov 15 08:49 background.gif
>>>>> :
>>>>> -rw-rw-r--+ 1 ohumbel None 10701 Nov 15 08:49 titlebar.gif
>>>>> 
>>>>> , I get an Access denied from another directory:
>>>>> java.io.FileNotFoundException:
>>>>> com\sun\tools\javac\services\**javax.tools.JavaCompilerTool (Access is
>>>>> denied)
>>>>> 
>>>>> 
>>>>> In the archives I read that TortoiseHg solves some problems because it
>>>>> provides a hg.exe. That is the reason why I installed it.
>>>>> Is this still true?
>>>>> If yes: How can I tell Tortoise to preserve the file permissions?
>>>>> 
>>>>> Oti.
>>>>> 
>>>>> 
>>>>> On Mon, Nov 19, 2012 at 8:47 PM, Kelly O'Hair<kelly.ohair at oracle.com>**
>>>>> wrote:
>>>>> 
>>>>> Since this appears to be some kind of file permission issue, what does
>>>>>> 'ls
>>>>>> -al' say on these files?
>>>>>> 
>>>>>> Perhaps the problem is with the hg you are using?
>>>>>> 
>>>>>> -kto
>>>>>> 
>>>>>> On Nov 19, 2012, at 9:51 AM, Oti wrote:
>>>>>> 
>>>>>> Hi all,
>>>>>>> 
>>>>>>> recently I joined the AdoptOpenJDK program and started to test the new
>>>>>>> build on Windows.
>>>>>>> You can find a list what I did here:
>>>>>>> http://java.net/projects/**adoptopenjdk/pages/**BuildWindows<http://java.net/projects/adoptopenjdk/pages/BuildWindows>
>>>>>>> .
>>>>>>> 
>>>>>>> The disabling of ASLR really helped: Before that I got a never ending
>>>>>>> hotspot build with 0% CPU load.
>>>>>>> Now hotspot builds just fine, thanks for the tip in
>>>>>>> 
>>>>>>> http://mail.openjdk.java.net/**pipermail/build-dev/2012-**
>>>>>> February/005594.html<http://mail.openjdk.java.net/pipermail/build-dev/2012-February/005594.html>
>>>>>> !
>>>>>> 
>>>>>>> What I am stuck with now is an Access denied stack trace.
>>>>>>> I can reproduce it as many times I want, like this:
>>>>>>> 
>>>>>>> 
>>>>>>> ohumbel at WIN-B8PK3J3J70Q ~
>>>>>>> $ cd /cygdrive/c/OpenJDK/jdk8_tl/**common/makefiles/
>>>>>>> 
>>>>>>> ohumbel at WIN-B8PK3J3J70Q /cygdrive/c/OpenJDK/jdk8_tl/**
>>>>>>> common/makefiles
>>>>>>> $ make clean-langtools
>>>>>>> Cleaning langtools build artifacts ... done
>>>>>>> 
>>>>>>> ohumbel at WIN-B8PK3J3J70Q /cygdrive/c/OpenJDK/jdk8_tl/**
>>>>>>> common/makefiles
>>>>>>> $ make langtools-only
>>>>>>> Building OpenJDK for target 'langtools-only' in configuration
>>>>>>> 'windows-x86_64-normal-server-**release
>>>>>>>           '
>>>>>>> 
>>>>>>> ## Starting langtools
>>>>>>> Compiling 2 files for BUILD_TOOLS
>>>>>>> Compiling 23 properties into resource bundles
>>>>>>> Compiling 673 files for BUILD_BOOTSTRAP_LANGTOOLS
>>>>>>> Creating langtools/dist/bootstrap/lib/**javac.jar
>>>>>>> Compiling 676 files for BUILD_FULL_JAVAC
>>>>>>> Creating langtools/dist/lib/classes.jar
>>>>>>> java.io.FileNotFoundException:
>>>>>>> com\sun\tools\doclets\**internal\toolkit\resources\**background.gif
>>>>>>> (Access
>>>>>> is
>>>>>> 
>>>>>>> denied)
>>>>>>>       at java.io.FileInputStream.open(**Native Method)
>>>>>>>       at java.io.FileInputStream.<init>**(FileInputStream.java:138)
>>>>>>>       at sun.tools.jar.Main.copy(Main.**java:791)
>>>>>>>       at sun.tools.jar.Main.addFile(**Main.java:740)
>>>>>>>       at sun.tools.jar.Main.update(**Main.java:592)
>>>>>>>       at sun.tools.jar.Main.run(Main.**java:223)
>>>>>>>       at sun.tools.jar.Main.main(Main.**java:1177)
>>>>>>> BuildLangtools.gmk:186: recipe for target
>>>>>>> 
>>>>>>> `/cygdrive/c/OpenJDK/jdk8_tl/**build/windows-x86_64-normal-**
>>>>>> server-release/langtools/dist/**lib/classes.jar'
>>>>>> 
>>>>>>> failed
>>>>>>> make[1]: ***
>>>>>>> 
>>>>>>> [/cygdrive/c/OpenJDK/jdk8_tl/**build/windows-x86_64-normal-**
>>>>>> server-release/langtools/dist/**lib/classes.jar]
>>>>>> 
>>>>>>> Error 1
>>>>>>> /cygdrive/c/OpenJDK/jdk8_tl/**common/makefiles//Main.gmk:75: recipe
>>>>>>> for
>>>>>>> target `langtools-only' failed
>>>>>>> make: *** [langtools-only] Error 2
>>>>>>> 
>>>>>>> 
>>>>>>> Interestingly, it is always the same background.gif which appears in
>>>>>>> the
>>>>>>> error message.
>>>>>>> 
>>>>>>>> From the above mentioned mail thread I guess that this could have
>>>>>>> something
>>>>>> 
>>>>>>> to to with Security Software (Anti-Virus, ...)
>>>>>>> I use Microsoft Security Essentials and
>>>>>>> - disabled all real time access
>>>>>>> - excluded the whole jdk folder
>>>>>>> - excluded the whole cygwin folder
>>>>>>> , but without any effect.
>>>>>>> 
>>>>>>> Hopefully somebody on this list has a tip what I could try next.
>>>>>>> 
>>>>>>> Thanks in advance, and best wishes,
>>>>>>> Oti.
>>>>>>> 
>>>>>>> 
>>>>>>> PS.
>>>>>>> I am running a VM inside VMware Fusion on a Macbook Air
>> 


From ohumbel at gmail.com  Tue Nov 20 13:48:58 2012
From: ohumbel at gmail.com (Oti)
Date: Tue, 20 Nov 2012 22:48:58 +0100
Subject: Access denied on Windows7 64bit
In-Reply-To: <9DB18954-C488-47C9-8C29-E45A617D7F50@reini.net>
References: <CACDaqRCoFcz98tRoEUx5hgDTDSwEQqmWmniNe_Yvwym2Oj1H2A@mail.gmail.com>
	<EBBDD3FA-C1F7-4CF6-B36F-F4372EDAE1BC@oracle.com>
	<CACDaqRBBw-=KnvQyxULAgzfEXHb+QjJJRLfnf1BsUTabJefKmA@mail.gmail.com>
	<3929F0C1-DC30-4DF6-91C6-6719A39E41A5@oracle.com>
	<50AB9D62.3020603@oracle.com>
	<CACDaqRCC+7t+sdCrBqf6ScQpbKAtdVsTrjxOz+9cCJB6ZxCCOA@mail.gmail.com>
	<CACDaqRDGPr3+f4OXrD=CsgoQNVYA4Fk50myA+ODMBtFJnjdUuQ@mail.gmail.com>
	<9DB18954-C488-47C9-8C29-E45A617D7F50@reini.net>
Message-ID: <CACDaqRCY_VDDZ_QWwBBL-Agw84+BxOFy-vTg7V7jAbCGo8kk8Q@mail.gmail.com>

Sorry for the poor formatting in the last message. The text below should be
a lot easier to read.

Hi again,
how cool is that:

----- Build times -------
Start 2012-11-20 20:39:50
End   2012-11-20 21:05:26
00:01:11 corba
00:05:17 hotspot
00:01:04 jaxp
00:01:15 jaxws
00:15:22 jdk
00:01:22 langtools
00:25:36 TOTAL
-------------------------
Finished building OpenJDK for target 'all'


However, a few lines above:

utils.cpp
zip.cpp
main.c
Error: loading:
c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
Error: loading:
c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
Error: loading:
c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
Error: loading:
c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
Error: loading:
c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
## Finished jdk (build time 00:15:22)

And the same error appears when trying to start the just built java:

ohumbel at WIN-B8PK3J3J70Q/cygdrive/c/OpenJDK/jdk8_tl_2/build/windows-x86_64-normal-server-release/jdk/bin
$ ./java -version
openjdk version "1.8.0-internal"
OpenJDK Runtime Environment (build
1.8.0-internal-ohumbel_2012_11_20_20_38-b00)
OpenJDK 64-Bit Server VM (build 25.0-b09, mixed mode)
Error: loading:
C:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll

But the msvcr100.dll is present:

ohumbel at WIN-B8PK3J3J70Q/cygdrive/c/OpenJDK/jdk8_tl_2/build/windows-x86_64-normal-server-release/jdk/bin
$ ls -la
total 14160
drwxr-xr-x+ 1 ohumbel None       0 Nov 20 21:05 .
drwxr-xr-x+ 1 ohumbel None       0 Nov 20 21:05 ..
-rw-r--r--  1 ohumbel None   32492 Nov 20 21:04 appletviewer.diz
-rwxr-xr-x  1 ohumbel None    9728 Nov 20 21:04 appletviewer.exe
-rw-r--r--  1 ohumbel None   54444 Nov 20 21:02 attach.diz
-rwxr-xr-x  1 ohumbel None   14848 Nov 20 21:02 attach.dll
:
-rw-r--r--  1 ohumbel None  204307 Nov 20 21:03 lcms.diz
-rwxr-xr-x  1 ohumbel None  179200 Nov 20 21:03 lcms.dll
-rw-r--r--  1 ohumbel None   90728 Nov 20 21:03 management.diz
-rwxr-xr-x  1 ohumbel None   28160 Nov 20 21:03 management.dll
-rw-r--r--  1 ohumbel None  135997 Nov 20 21:00 mlib_image.diz
-rwxr-xr-x  1 ohumbel None  646656 Nov 20 21:00 mlib_image.dll
-rwx------  1 ohumbel None  773968 Nov 20 20:55 msvcr100.dll
:

Could it be that another path should be converted to cygwin?


Reini,
changing the file permission has no effect for running java:

ohumbel at WIN-B8PK3J3J70Q/cygdrive/c/OpenJDK/jdk8_tl_2/build/windows-x86_64-normal-server-release/jdk/bin
$ ls -la msv*
-rwxr-xr-x 1 ohumbel None 773968 Nov 20 20:55 msvcr100.dll
$ ./java -version
openjdk version "1.8.0-internal"
OpenJDK Runtime Environment (build
1.8.0-internal-ohumbel_2012_11_20_20_38-b00)
OpenJDK 64-Bit Server VM (build 25.0-b09, mixed mode)
Error: loading:
C:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll

, and during the build I have no control over it.

Thanks, and best wishes
Oti.



On Tue, Nov 20, 2012 at 9:40 PM, Patrick Reinhart <patrick at reini.net> wrote:

> Hi Oti,
>
> Could it be that msvcr100.dll should be executable?
>
> Cheers
>
> Patrick 'Reini' Reinhart
>


From erik.joelsson at oracle.com  Wed Nov 21 00:39:39 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 21 Nov 2012 09:39:39 +0100
Subject: build problem
In-Reply-To: <50AA6354.6040801@oracle.com>
References: <50A6C8EA.8080209@oracle.com>	<B37AB3C0-0233-487A-89C5-C7466DEEE87D@oracle.com>	<50A6CC14.30008@oracle.com>
	<50AA158B.3080208@oracle.com> <50AA61AF.3050800@oracle.com>
	<50AA6242.3070908@oracle.com> <50AA6354.6040801@oracle.com>
Message-ID: <50AC934B.5090702@oracle.com>

Think I found the problem. Created JDK-8003819 for this.

/Erik

On 2012-11-19 17:50, Phil Race wrote:
> Ok .. well I already sent you the file.
>
> -phil.
>
> On 11/19/2012 8:45 AM, Erik Joelsson wrote:
>> No, you misunderstand me. That changeset fixed such a problem in 
>> CreateJars.gmk. Your error message says spec.gmk, the generated file 
>> in the build output dir. I'm suspecting that something to do with a 
>> path with backslashes in it has somehow gotten in there, but it's 
>> just a guess. I would like to take a look at the resulting spec.gmk 
>> regardless to try to figure it out.
>>
>> /Erik
>>
>> On 2012-11-19 17:43, Phil Race wrote:
>>> I'm sure that's why Kelly suggested the changeset below .. since it 
>>> has such a \
>>> but I already fixed that prior to even trying to build.
>>>
>>> -phil.
>>>
>>> On 11/19/2012 3:18 AM, Erik Joelsson wrote:
>>>> My first guess would be a '\' at the end of a line somewhere in the 
>>>> spec.gmk file that cancels out the endif on the next line. Would be 
>>>> interesting to see the full spec.gmk regardless. I haven't seen 
>>>> this happen before in spec but wouldn't be surprised if a backslash 
>>>> from a path somewhere ended up in the wrong place.
>>>>
>>>> /Erik
>>>>
>>>> On 2012-11-17 00:28, Phil Race wrote:
>>>>> I had already applied those two fixes manually and I just
>>>>> double-checked and they seem to be there ..
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 11/16/2012 3:21 PM, Kelly O'Hair wrote:
>>>>>> You need this changeset:
>>>>>>
>>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/1e79fec4a01f
>>>>>>
>>>>>>
>>>>>> -kto
>>>>>>
>>>>>> On Nov 16, 2012, at 3:14 PM, Phil Race wrote:
>>>>>>
>>>>>>> Can anyone explain what the solution might be to the following
>>>>>>> build failure on Windows 7 x64. I'm using our current JDK8 2d 
>>>>>>> team repo :-
>>>>>>>
>>>>>>> sh ./configure --with-boot-jdk=c:/jdk1.7
>>>>>>>
>>>>>>> make NEWBUILD=true BUILD_DEPLOY=false BUILD_INSTALL=false
>>>>>>> No checks yet
>>>>>>> cd 
>>>>>>> /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/&&  
>>>>>>> make all
>>>>>>> make[1]: Entering directory 
>>>>>>> `/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
>>>>>>> /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/spec.gmk:601: 
>>>>>>> *** missing `endif'.  Stop.
>>>>>>> make[1]: Leaving directory 
>>>>>>> `/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
>>>>>>> make: *** [all] Error 2
>>>>>>>
>>>>>>>
>>>>>>> line 601 is the last line of spec.gmk and if I add endif 
>>>>>>> afterwards it seems to
>>>>>>> at least get past this point but obviously something is wrong.  
>>>>>>> I looked over
>>>>>>> the file and all if's seem balanced to me.
>>>>>>>
>>>>>>> Last few lines of the file look like this :- "8(0" looks odd too 
>>>>>>> but
>>>>>>> changing that doesn't seem to fix my issue.
>>>>>>>
>>>>>>> ----
>>>>>>> # Name of Service Agent library
>>>>>>> SALIB_NAME=sawindbg.dll
>>>>>>>
>>>>>>> OS_VERSION_MAJOR:=1
>>>>>>> OS_VERSION_MINOR:=7
>>>>>>> OS_VERSION_MICRO:=8(0
>>>>>>>
>>>>>>> # Include the custom-spec.gmk file if it exists
>>>>>>> -include $(dir 
>>>>>>> /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/spec.gmk)/custom-spec.gmk
>>>>>>> -----
>>>>>>>
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>
>>>
>


From erik.joelsson at oracle.com  Wed Nov 21 00:54:51 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 21 Nov 2012 09:54:51 +0100
Subject: Access denied on Windows7 64bit
In-Reply-To: <CACDaqRCY_VDDZ_QWwBBL-Agw84+BxOFy-vTg7V7jAbCGo8kk8Q@mail.gmail.com>
References: <CACDaqRCoFcz98tRoEUx5hgDTDSwEQqmWmniNe_Yvwym2Oj1H2A@mail.gmail.com>	<EBBDD3FA-C1F7-4CF6-B36F-F4372EDAE1BC@oracle.com>	<CACDaqRBBw-=KnvQyxULAgzfEXHb+QjJJRLfnf1BsUTabJefKmA@mail.gmail.com>	<3929F0C1-DC30-4DF6-91C6-6719A39E41A5@oracle.com>	<50AB9D62.3020603@oracle.com>	<CACDaqRCC+7t+sdCrBqf6ScQpbKAtdVsTrjxOz+9cCJB6ZxCCOA@mail.gmail.com>	<CACDaqRDGPr3+f4OXrD=CsgoQNVYA4Fk50myA+ODMBtFJnjdUuQ@mail.gmail.com>	<9DB18954-C488-47C9-8C29-E45A617D7F50@reini.net>
	<CACDaqRCY_VDDZ_QWwBBL-Agw84+BxOFy-vTg7V7jAbCGo8kk8Q@mail.gmail.com>
Message-ID: <50AC96DB.6020005@oracle.com>

Hello Oti,

It could be that. I know one of my colleges has an issue that is at 
least similar. Something with permissions getting messed up after 
copying that file into the build directory. It could also be that the 
wrong msvcr100.dll has been picked up. We had a bug at some point where 
that could happen and I'm not sure how up to date the source base you 
are building from is. To check, find the reference to that file in 
spec.gmk in the root of your build dir.

To see if it's a permissions issue, you could try chmod, checking the 
permissions using explorer or manually copying the file using explorer 
and see if anything makes a difference.

/Erik

On 2012-11-20 22:48, Oti wrote:
> Sorry for the poor formatting in the last message. The text below should be
> a lot easier to read.
>
> Hi again,
> how cool is that:
>
> ----- Build times -------
> Start 2012-11-20 20:39:50
> End   2012-11-20 21:05:26
> 00:01:11 corba
> 00:05:17 hotspot
> 00:01:04 jaxp
> 00:01:15 jaxws
> 00:15:22 jdk
> 00:01:22 langtools
> 00:25:36 TOTAL
> -------------------------
> Finished building OpenJDK for target 'all'
>
>
> However, a few lines above:
>
> utils.cpp
> zip.cpp
> main.c
> Error: loading:
> c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
> Error: loading:
> c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
> Error: loading:
> c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
> Error: loading:
> c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
> Error: loading:
> c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
> ## Finished jdk (build time 00:15:22)
>
> And the same error appears when trying to start the just built java:
>
> ohumbel at WIN-B8PK3J3J70Q/cygdrive/c/OpenJDK/jdk8_tl_2/build/windows-x86_64-normal-server-release/jdk/bin
> $ ./java -version
> openjdk version "1.8.0-internal"
> OpenJDK Runtime Environment (build
> 1.8.0-internal-ohumbel_2012_11_20_20_38-b00)
> OpenJDK 64-Bit Server VM (build 25.0-b09, mixed mode)
> Error: loading:
> C:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
>
> But the msvcr100.dll is present:
>
> ohumbel at WIN-B8PK3J3J70Q/cygdrive/c/OpenJDK/jdk8_tl_2/build/windows-x86_64-normal-server-release/jdk/bin
> $ ls -la
> total 14160
> drwxr-xr-x+ 1 ohumbel None       0 Nov 20 21:05 .
> drwxr-xr-x+ 1 ohumbel None       0 Nov 20 21:05 ..
> -rw-r--r--  1 ohumbel None   32492 Nov 20 21:04 appletviewer.diz
> -rwxr-xr-x  1 ohumbel None    9728 Nov 20 21:04 appletviewer.exe
> -rw-r--r--  1 ohumbel None   54444 Nov 20 21:02 attach.diz
> -rwxr-xr-x  1 ohumbel None   14848 Nov 20 21:02 attach.dll
> :
> -rw-r--r--  1 ohumbel None  204307 Nov 20 21:03 lcms.diz
> -rwxr-xr-x  1 ohumbel None  179200 Nov 20 21:03 lcms.dll
> -rw-r--r--  1 ohumbel None   90728 Nov 20 21:03 management.diz
> -rwxr-xr-x  1 ohumbel None   28160 Nov 20 21:03 management.dll
> -rw-r--r--  1 ohumbel None  135997 Nov 20 21:00 mlib_image.diz
> -rwxr-xr-x  1 ohumbel None  646656 Nov 20 21:00 mlib_image.dll
> -rwx------  1 ohumbel None  773968 Nov 20 20:55 msvcr100.dll
> :
>
> Could it be that another path should be converted to cygwin?
>
>
> Reini,
> changing the file permission has no effect for running java:
>
> ohumbel at WIN-B8PK3J3J70Q/cygdrive/c/OpenJDK/jdk8_tl_2/build/windows-x86_64-normal-server-release/jdk/bin
> $ ls -la msv*
> -rwxr-xr-x 1 ohumbel None 773968 Nov 20 20:55 msvcr100.dll
> $ ./java -version
> openjdk version "1.8.0-internal"
> OpenJDK Runtime Environment (build
> 1.8.0-internal-ohumbel_2012_11_20_20_38-b00)
> OpenJDK 64-Bit Server VM (build 25.0-b09, mixed mode)
> Error: loading:
> C:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
>
> , and during the build I have no control over it.
>
> Thanks, and best wishes
> Oti.
>
>
>
> On Tue, Nov 20, 2012 at 9:40 PM, Patrick Reinhart<patrick at reini.net>  wrote:
>
>> Hi Oti,
>>
>> Could it be that msvcr100.dll should be executable?
>>
>> Cheers
>>
>> Patrick 'Reini' Reinhart
>>


From david.holmes at oracle.com  Wed Nov 21 01:54:10 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 21 Nov 2012 19:54:10 +1000
Subject: Using compare.sh ?
Message-ID: <50ACA4C2.1000005@oracle.com>

I found compareimages.sh extremely simple to use and very useful. Now we 
have a compare.sh in the "config" directory which I assume I run from 
the "root" of the image I want to compare, with -o pointing to the other 
image. But something doesn't seem right:

 > 
/java/embedded/users/dh198349/profiles/builds/b65/se-linux-i586-ea/images/j2sdk-image 
 > bash ../../compare.sh -all -vv -o 
/scratch/dh198349/profiles-ref/builds/b60/se-linux-i586-ea/images/j2sdk-image/
/java/embedded/users/dh198349/profiles/builds/b65/se-linux-i586-ea
Comparing to:
/scratch/dh198349/profiles-ref/builds/b60/se-linux-i586-ea/images/j2sdk-image


No regressions found

--

Apart from expecting regressions, I also specified -vv but there's no 
output. ??

David

PS. The "example" from compare.sh usage message still refers to the now 
non-existent common/bin/compareimages.sh

Thanks,
David


From erik.joelsson at oracle.com  Wed Nov 21 02:16:09 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 21 Nov 2012 11:16:09 +0100
Subject: Using compare.sh ?
In-Reply-To: <50ACA4C2.1000005@oracle.com>
References: <50ACA4C2.1000005@oracle.com>
Message-ID: <50ACA9E9.1090801@oracle.com>

I will try to improve the help output from script and detecting of bad 
input.

The way it's currently implemented, it compares a "build" and not just 
an image. -o is supposed to point to the root of a build output. The 
usecase of comparing just the j2sdk image was dropped. I wanted to check 
both the jre and sdk images, and am now also adding comparison of docs.

The intended way of calling the script for what I think you are trying 
to do would be:

/java/embedded/users/dh198349/profiles/builds/b65/se-linux-i586-ea> bash 
compare.sh -all -vv -o 
/scratch/dh198349/profiles-ref/builds/b60/se-linux-i586-ea

/Erik

On 2012-11-21 10:54, David Holmes wrote:
> I found compareimages.sh extremely simple to use and very useful. Now 
> we have a compare.sh in the "config" directory which I assume I run 
> from the "root" of the image I want to compare, with -o pointing to 
> the other image. But something doesn't seem right:
>
> > 
> /java/embedded/users/dh198349/profiles/builds/b65/se-linux-i586-ea/images/j2sdk-image 
> > bash ../../compare.sh -all -vv -o 
> /scratch/dh198349/profiles-ref/builds/b60/se-linux-i586-ea/images/j2sdk-image/
> /java/embedded/users/dh198349/profiles/builds/b65/se-linux-i586-ea
> Comparing to:
> /scratch/dh198349/profiles-ref/builds/b60/se-linux-i586-ea/images/j2sdk-image 
>
>
>
> No regressions found
>
> -- 
>
> Apart from expecting regressions, I also specified -vv but there's no 
> output. ??
>
> David
>
> PS. The "example" from compare.sh usage message still refers to the 
> now non-existent common/bin/compareimages.sh
>
> Thanks,
> David


From david.holmes at oracle.com  Wed Nov 21 04:25:47 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 21 Nov 2012 22:25:47 +1000
Subject: Using compare.sh ?
In-Reply-To: <50ACA9E9.1090801@oracle.com>
References: <50ACA4C2.1000005@oracle.com> <50ACA9E9.1090801@oracle.com>
Message-ID: <50ACC84B.2050705@oracle.com>

On 21/11/2012 8:16 PM, Erik Joelsson wrote:
> I will try to improve the help output from script and detecting of bad
> input.
>
> The way it's currently implemented, it compares a "build" and not just
> an image. -o is supposed to point to the root of a build output. The
> usecase of comparing just the j2sdk image was dropped. I wanted to check
> both the jre and sdk images, and am now also adding comparison of docs.

Wow! That's a huge loss of usability to me :( I want to compare images, 
not sets of images. I don't have complete sets to start from and I don't 
want to see a report that a thousand things are missing. It also sounds 
from that that it won't be able to compare profiles because it doesn't 
know about them. :(

I'm trying to sync up the profiles work from b60 level to b65 and I just 
got the images target to build again, so now I want to check that the 
jdk and jre images produced has the same contents compared to my b60 
build, before trying to make the profile images work again.

We also wanted to use this tool to compare a new build JDK with an old 
build JDK. But we really want to be able to work with individual images.

David
-----

> The intended way of calling the script for what I think you are trying
> to do would be:
>
> /java/embedded/users/dh198349/profiles/builds/b65/se-linux-i586-ea> bash
> compare.sh -all -vv -o
> /scratch/dh198349/profiles-ref/builds/b60/se-linux-i586-ea
>
> /Erik
>
> On 2012-11-21 10:54, David Holmes wrote:
>> I found compareimages.sh extremely simple to use and very useful. Now
>> we have a compare.sh in the "config" directory which I assume I run
>> from the "root" of the image I want to compare, with -o pointing to
>> the other image. But something doesn't seem right:
>>
>> >
>> /java/embedded/users/dh198349/profiles/builds/b65/se-linux-i586-ea/images/j2sdk-image
>> > bash ../../compare.sh -all -vv -o
>> /scratch/dh198349/profiles-ref/builds/b60/se-linux-i586-ea/images/j2sdk-image/
>>
>> /java/embedded/users/dh198349/profiles/builds/b65/se-linux-i586-ea
>> Comparing to:
>> /scratch/dh198349/profiles-ref/builds/b60/se-linux-i586-ea/images/j2sdk-image
>>
>>
>>
>> No regressions found
>>
>> --
>>
>> Apart from expecting regressions, I also specified -vv but there's no
>> output. ??
>>
>> David
>>
>> PS. The "example" from compare.sh usage message still refers to the
>> now non-existent common/bin/compareimages.sh
>>
>> Thanks,
>> David


From erik.joelsson at oracle.com  Wed Nov 21 04:30:45 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 21 Nov 2012 13:30:45 +0100
Subject: Using compare.sh ?
In-Reply-To: <50ACC84B.2050705@oracle.com>
References: <50ACA4C2.1000005@oracle.com> <50ACA9E9.1090801@oracle.com>
	<50ACC84B.2050705@oracle.com>
Message-ID: <50ACC975.6090401@oracle.com>

Then we need to return that functionality. It's not technically hard at 
all, just need to figure out a reasonable UI for it.

/Erik

On 2012-11-21 13:25, David Holmes wrote:
> On 21/11/2012 8:16 PM, Erik Joelsson wrote:
>> I will try to improve the help output from script and detecting of bad
>> input.
>>
>> The way it's currently implemented, it compares a "build" and not just
>> an image. -o is supposed to point to the root of a build output. The
>> usecase of comparing just the j2sdk image was dropped. I wanted to check
>> both the jre and sdk images, and am now also adding comparison of docs.
>
> Wow! That's a huge loss of usability to me :( I want to compare 
> images, not sets of images. I don't have complete sets to start from 
> and I don't want to see a report that a thousand things are missing. 
> It also sounds from that that it won't be able to compare profiles 
> because it doesn't know about them. :(
>
> I'm trying to sync up the profiles work from b60 level to b65 and I 
> just got the images target to build again, so now I want to check that 
> the jdk and jre images produced has the same contents compared to my 
> b60 build, before trying to make the profile images work again.
>
> We also wanted to use this tool to compare a new build JDK with an old 
> build JDK. But we really want to be able to work with individual images.
>
> David
> -----
>
>> The intended way of calling the script for what I think you are trying
>> to do would be:
>>
>> /java/embedded/users/dh198349/profiles/builds/b65/se-linux-i586-ea> bash
>> compare.sh -all -vv -o
>> /scratch/dh198349/profiles-ref/builds/b60/se-linux-i586-ea
>>
>> /Erik
>>
>> On 2012-11-21 10:54, David Holmes wrote:
>>> I found compareimages.sh extremely simple to use and very useful. Now
>>> we have a compare.sh in the "config" directory which I assume I run
>>> from the "root" of the image I want to compare, with -o pointing to
>>> the other image. But something doesn't seem right:
>>>
>>> >
>>> /java/embedded/users/dh198349/profiles/builds/b65/se-linux-i586-ea/images/j2sdk-image 
>>>
>>> > bash ../../compare.sh -all -vv -o
>>> /scratch/dh198349/profiles-ref/builds/b60/se-linux-i586-ea/images/j2sdk-image/ 
>>>
>>>
>>> /java/embedded/users/dh198349/profiles/builds/b65/se-linux-i586-ea
>>> Comparing to:
>>> /scratch/dh198349/profiles-ref/builds/b60/se-linux-i586-ea/images/j2sdk-image 
>>>
>>>
>>>
>>>
>>> No regressions found
>>>
>>> -- 
>>>
>>> Apart from expecting regressions, I also specified -vv but there's no
>>> output. ??
>>>
>>> David
>>>
>>> PS. The "example" from compare.sh usage message still refers to the
>>> now non-existent common/bin/compareimages.sh
>>>
>>> Thanks,
>>> David


From erik.joelsson at oracle.com  Wed Nov 21 08:37:03 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Wed, 21 Nov 2012 16:37:03 +0000
Subject: hg: build-infra/jdk8/langtools: 8003844: build-infra: docs target
	isn't working properly
Message-ID: <20121121163708.544D347ABC@hg.openjdk.java.net>

Changeset: 9d6292d4623b
Author:    erikj
Date:      2012-11-21 17:36 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/langtools/rev/9d6292d4623b

8003844: build-infra: docs target isn't working properly
Summary: Added resource files to bootstrap javadoc.jar

! makefiles/BuildLangtools.gmk



From erik.joelsson at oracle.com  Wed Nov 21 08:37:20 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Wed, 21 Nov 2012 16:37:20 +0000
Subject: hg: build-infra/jdk8: 8003844: build-infra: docs target isn't working
	properly
Message-ID: <20121121163720.C457647ABD@hg.openjdk.java.net>

Changeset: 91d8f845c95a
Author:    erikj
Date:      2012-11-21 17:35 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/91d8f845c95a

8003844: build-infra: docs target isn't working properly
Summary: Fixed docs target and added support in compare.sh

! common/autoconf/generated-configure.sh
! common/bin/compare.sh
! common/makefiles/javadoc/Javadoc.gmk



From kelly.ohair at oracle.com  Wed Nov 21 08:39:04 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 21 Nov 2012 08:39:04 -0800
Subject: Access denied on Windows7 64bit
In-Reply-To: <50AC96DB.6020005@oracle.com>
References: <CACDaqRCoFcz98tRoEUx5hgDTDSwEQqmWmniNe_Yvwym2Oj1H2A@mail.gmail.com>	<EBBDD3FA-C1F7-4CF6-B36F-F4372EDAE1BC@oracle.com>	<CACDaqRBBw-=KnvQyxULAgzfEXHb+QjJJRLfnf1BsUTabJefKmA@mail.gmail.com>	<3929F0C1-DC30-4DF6-91C6-6719A39E41A5@oracle.com>	<50AB9D62.3020603@oracle.com>	<CACDaqRCC+7t+sdCrBqf6ScQpbKAtdVsTrjxOz+9cCJB6ZxCCOA@mail.gmail.com>	<CACDaqRDGPr3+f4OXrD=CsgoQNVYA4Fk50myA+ODMBtFJnjdUuQ@mail.gmail.com>	<9DB18954-C488-47C9-8C29-E45A617D7F50@reini.net>
	<CACDaqRCY_VDDZ_QWwBBL-Agw84+BxOFy-vTg7V7jAbCGo8kk8Q@mail.gmail.com>
	<50AC96DB.6020005@oracle.com>
Message-ID: <9FDA6036-A6BD-4229-AFF3-3BC0046975E6@oracle.com>

Just some background...  When we used MKS with the old makefiles, there was a bad habit of not following the
copy with a 'chmod a+rx' simply because MKS seemed to always default to very generous copied file permissions,
either the equivalent of 'chmod a+rx' or even 'chmod a+rwx'. The default umask was mostly ignored by MKS.
So when we allowed the use of CYGWIN, which did permissions more like Linux/Solaris, we often had to
change the make rules to include the chmod calls, and also rm's before writing to a file that could be copied as
read-only.  So even with the old builds, if used with CYGWIN, I would not be surprised if issues remained with
regards to this.

At a high level, I really wish we could create an inventory file with every bundle we create that would itemize
the entire bundle contents, something to nail down and allow us to check these kind of things.

So please try doing a  'chmod a+rx' on this msvcr100.dll file and see if that works.

-kto

On Nov 21, 2012, at 12:54 AM, Erik Joelsson wrote:

> Hello Oti,
> 
> It could be that. I know one of my colleges has an issue that is at least similar. Something with permissions getting messed up after copying that file into the build directory. It could also be that the wrong msvcr100.dll has been picked up. We had a bug at some point where that could happen and I'm not sure how up to date the source base you are building from is. To check, find the reference to that file in spec.gmk in the root of your build dir.
> 
> To see if it's a permissions issue, you could try chmod, checking the permissions using explorer or manually copying the file using explorer and see if anything makes a difference.
> 
> /Erik
> 
> On 2012-11-20 22:48, Oti wrote:
>> Sorry for the poor formatting in the last message. The text below should be
>> a lot easier to read.
>> 
>> Hi again,
>> how cool is that:
>> 
>> ----- Build times -------
>> Start 2012-11-20 20:39:50
>> End   2012-11-20 21:05:26
>> 00:01:11 corba
>> 00:05:17 hotspot
>> 00:01:04 jaxp
>> 00:01:15 jaxws
>> 00:15:22 jdk
>> 00:01:22 langtools
>> 00:25:36 TOTAL
>> -------------------------
>> Finished building OpenJDK for target 'all'
>> 
>> 
>> However, a few lines above:
>> 
>> utils.cpp
>> zip.cpp
>> main.c
>> Error: loading:
>> c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
>> Error: loading:
>> c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
>> Error: loading:
>> c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
>> Error: loading:
>> c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
>> Error: loading:
>> c:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
>> ## Finished jdk (build time 00:15:22)
>> 
>> And the same error appears when trying to start the just built java:
>> 
>> ohumbel at WIN-B8PK3J3J70Q/cygdrive/c/OpenJDK/jdk8_tl_2/build/windows-x86_64-normal-server-release/jdk/bin
>> $ ./java -version
>> openjdk version "1.8.0-internal"
>> OpenJDK Runtime Environment (build
>> 1.8.0-internal-ohumbel_2012_11_20_20_38-b00)
>> OpenJDK 64-Bit Server VM (build 25.0-b09, mixed mode)
>> Error: loading:
>> C:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
>> 
>> But the msvcr100.dll is present:
>> 
>> ohumbel at WIN-B8PK3J3J70Q/cygdrive/c/OpenJDK/jdk8_tl_2/build/windows-x86_64-normal-server-release/jdk/bin
>> $ ls -la
>> total 14160
>> drwxr-xr-x+ 1 ohumbel None       0 Nov 20 21:05 .
>> drwxr-xr-x+ 1 ohumbel None       0 Nov 20 21:05 ..
>> -rw-r--r--  1 ohumbel None   32492 Nov 20 21:04 appletviewer.diz
>> -rwxr-xr-x  1 ohumbel None    9728 Nov 20 21:04 appletviewer.exe
>> -rw-r--r--  1 ohumbel None   54444 Nov 20 21:02 attach.diz
>> -rwxr-xr-x  1 ohumbel None   14848 Nov 20 21:02 attach.dll
>> :
>> -rw-r--r--  1 ohumbel None  204307 Nov 20 21:03 lcms.diz
>> -rwxr-xr-x  1 ohumbel None  179200 Nov 20 21:03 lcms.dll
>> -rw-r--r--  1 ohumbel None   90728 Nov 20 21:03 management.diz
>> -rwxr-xr-x  1 ohumbel None   28160 Nov 20 21:03 management.dll
>> -rw-r--r--  1 ohumbel None  135997 Nov 20 21:00 mlib_image.diz
>> -rwxr-xr-x  1 ohumbel None  646656 Nov 20 21:00 mlib_image.dll
>> -rwx------  1 ohumbel None  773968 Nov 20 20:55 msvcr100.dll
>> :
>> 
>> Could it be that another path should be converted to cygwin?
>> 
>> 
>> Reini,
>> changing the file permission has no effect for running java:
>> 
>> ohumbel at WIN-B8PK3J3J70Q/cygdrive/c/OpenJDK/jdk8_tl_2/build/windows-x86_64-normal-server-release/jdk/bin
>> $ ls -la msv*
>> -rwxr-xr-x 1 ohumbel None 773968 Nov 20 20:55 msvcr100.dll
>> $ ./java -version
>> openjdk version "1.8.0-internal"
>> OpenJDK Runtime Environment (build
>> 1.8.0-internal-ohumbel_2012_11_20_20_38-b00)
>> OpenJDK 64-Bit Server VM (build 25.0-b09, mixed mode)
>> Error: loading:
>> C:\OpenJDK\jdk8_tl_2\build\windows-x86_64-normal-server-release\jdk\bin\msvcr100.dll
>> 
>> , and during the build I have no control over it.
>> 
>> Thanks, and best wishes
>> Oti.
>> 
>> 
>> 
>> On Tue, Nov 20, 2012 at 9:40 PM, Patrick Reinhart<patrick at reini.net>  wrote:
>> 
>>> Hi Oti,
>>> 
>>> Could it be that msvcr100.dll should be executable?
>>> 
>>> Cheers
>>> 
>>> Patrick 'Reini' Reinhart
>>> 



From fredrik.ohrstrom at oracle.com  Wed Nov 21 12:10:30 2012
From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com)
Date: Wed, 21 Nov 2012 20:10:30 +0000
Subject: hg: build-infra/jdk8: Improved hgforest.sh
Message-ID: <20121121201030.36C3747AC8@hg.openjdk.java.net>

Changeset: 811b3b283175
Author:    ohrstrom
Date:      2012-11-21 21:08 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/811b3b283175

Improved hgforest.sh

+ common/bin/hgforest.sh



From philip.race at oracle.com  Wed Nov 21 13:04:23 2012
From: philip.race at oracle.com (Phil Race)
Date: Wed, 21 Nov 2012 13:04:23 -0800
Subject: build problem
In-Reply-To: <50AC934B.5090702@oracle.com>
References: <50A6C8EA.8080209@oracle.com>	<B37AB3C0-0233-487A-89C5-C7466DEEE87D@oracle.com>	<50A6CC14.30008@oracle.com>	<50AA158B.3080208@oracle.com>
	<50AA61AF.3050800@oracle.com>	<50AA6242.3070908@oracle.com>
	<50AA6354.6040801@oracle.com> <50AC934B.5090702@oracle.com>
Message-ID: <50AD41D7.3050508@oracle.com>

Using your workaround I get much further .. it now dies after apparently
building several repos, but at the start of the JDK repo :-

Here's my configure output and a log snippet :-
------
A new configuration has been successfully created in
/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release
using configure arguments '--with-boot-jdk=c:/jdk1.7'.

Configuration summary:
* Debug level:    release
* JDK variant:    normal
* JVM variants:   server
* OpenJDK target: OS: windows, CPU architecture: x86, address length: 64

Tools summary:
* Environment:    cygwin version 1.7.8(0.236/5/3) (root at 
/cygdrive/c/cygwin)
* Boot JDK:       java version "1.7.0_07"  Java(TM) SE Runtime 
Environment (buil
d 1.7.0_07-b11)  Java HotSpot(TM) Client VM (build 23.3-b01, mixed mode, 
sharing
)   (at /cygdrive/c/jdk1.7)
* C Compiler:     Microsoft CL.EXE version 16.00.30319.01 (at 
/cygdrive/c/vs2010
/VC/BIN/amd64/cl)
* C++ Compiler:   Microsoft CL.EXE version 16.00.30319.01 (at 
/cygdrive/c/vs2010
/VC/BIN/amd64/cl)

Build performance summary:
* Cores to use:   8
* Memory limit:   4095 MB
* ccache status:  not available for your system
------------------------------

sh-4.1$ make NEWBUILD=true BUILD_DEPLOY=false BUILD_INSTALL=false
....

tail of log looks like :-
-----------------------------------
## Starting jdk
make[2]: Entering directory `/cygdrive/c/jdks/2d/jdk/makefiles'
Compiling 169 files for BUILD_TOOLS
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
make[3]: Entering directory `/cygdrive/c/jdks/2d/jdk/makefiles'
Importing CORBA classes.jar
Importing CORBA src.zip
Importing CORBA bin.zip
Importing JAXP classes.jar
Importing JAXP src.zip
Importing JAXWS src.zip
Importing JAXWS classes.jar
Importing LANGTOOLS src.zip
make[3]: *** 
[/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/jdk/impsrc/_the.LANGTOOLS.src.imported] 
Error 126
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory `/cygdrive/c/jdks/2d/jdk/makefiles'
make[2]: *** [import-only] Error 2
make[2]: Leaving directory `/cygdrive/c/jdks/2d/jdk/makefiles'
make[1]: *** [jdk-only] Error 2
make[1]: Leaving directory 
`/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
make: *** [all] Error 2

-------------------------------------

-phil.


On 11/21/2012 12:39 AM, Erik Joelsson wrote:
> Think I found the problem. Created JDK-8003819 for this.
>
> /Erik
>
> On 2012-11-19 17:50, Phil Race wrote:
>> Ok .. well I already sent you the file.
>>
>> -phil.
>>
>> On 11/19/2012 8:45 AM, Erik Joelsson wrote:
>>> No, you misunderstand me. That changeset fixed such a problem in 
>>> CreateJars.gmk. Your error message says spec.gmk, the generated file 
>>> in the build output dir. I'm suspecting that something to do with a 
>>> path with backslashes in it has somehow gotten in there, but it's 
>>> just a guess. I would like to take a look at the resulting spec.gmk 
>>> regardless to try to figure it out.
>>>
>>> /Erik
>>>
>>> On 2012-11-19 17:43, Phil Race wrote:
>>>> I'm sure that's why Kelly suggested the changeset below .. since it 
>>>> has such a \
>>>> but I already fixed that prior to even trying to build.
>>>>
>>>> -phil.
>>>>
>>>> On 11/19/2012 3:18 AM, Erik Joelsson wrote:
>>>>> My first guess would be a '\' at the end of a line somewhere in 
>>>>> the spec.gmk file that cancels out the endif on the next line. 
>>>>> Would be interesting to see the full spec.gmk regardless. I 
>>>>> haven't seen this happen before in spec but wouldn't be surprised 
>>>>> if a backslash from a path somewhere ended up in the wrong place.
>>>>>
>>>>> /Erik
>>>>>
>>>>> On 2012-11-17 00:28, Phil Race wrote:
>>>>>> I had already applied those two fixes manually and I just
>>>>>> double-checked and they seem to be there ..
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> On 11/16/2012 3:21 PM, Kelly O'Hair wrote:
>>>>>>> You need this changeset:
>>>>>>>
>>>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/1e79fec4a01f
>>>>>>>
>>>>>>>
>>>>>>> -kto
>>>>>>>
>>>>>>> On Nov 16, 2012, at 3:14 PM, Phil Race wrote:
>>>>>>>
>>>>>>>> Can anyone explain what the solution might be to the following
>>>>>>>> build failure on Windows 7 x64. I'm using our current JDK8 2d 
>>>>>>>> team repo :-
>>>>>>>>
>>>>>>>> sh ./configure --with-boot-jdk=c:/jdk1.7
>>>>>>>>
>>>>>>>> make NEWBUILD=true BUILD_DEPLOY=false BUILD_INSTALL=false
>>>>>>>> No checks yet
>>>>>>>> cd 
>>>>>>>> /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/&&  
>>>>>>>> make all
>>>>>>>> make[1]: Entering directory 
>>>>>>>> `/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
>>>>>>>> /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/spec.gmk:601: 
>>>>>>>> *** missing `endif'.  Stop.
>>>>>>>> make[1]: Leaving directory 
>>>>>>>> `/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
>>>>>>>> make: *** [all] Error 2
>>>>>>>>
>>>>>>>>
>>>>>>>> line 601 is the last line of spec.gmk and if I add endif 
>>>>>>>> afterwards it seems to
>>>>>>>> at least get past this point but obviously something is wrong.  
>>>>>>>> I looked over
>>>>>>>> the file and all if's seem balanced to me.
>>>>>>>>
>>>>>>>> Last few lines of the file look like this :- "8(0" looks odd 
>>>>>>>> too but
>>>>>>>> changing that doesn't seem to fix my issue.
>>>>>>>>
>>>>>>>> ----
>>>>>>>> # Name of Service Agent library
>>>>>>>> SALIB_NAME=sawindbg.dll
>>>>>>>>
>>>>>>>> OS_VERSION_MAJOR:=1
>>>>>>>> OS_VERSION_MINOR:=7
>>>>>>>> OS_VERSION_MICRO:=8(0
>>>>>>>>
>>>>>>>> # Include the custom-spec.gmk file if it exists
>>>>>>>> -include $(dir 
>>>>>>>> /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/spec.gmk)/custom-spec.gmk
>>>>>>>> -----
>>>>>>>>
>>>>>>>>
>>>>>>>> -phil.
>>>>>>>>
>>>>>>
>>>>
>>



From mike.duigou at oracle.com  Wed Nov 21 13:31:32 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 21 Nov 2012 13:31:32 -0800
Subject: build problem
In-Reply-To: <50AD41D7.3050508@oracle.com>
References: <50A6C8EA.8080209@oracle.com>	<B37AB3C0-0233-487A-89C5-C7466DEEE87D@oracle.com>	<50A6CC14.30008@oracle.com>	<50AA158B.3080208@oracle.com>
	<50AA61AF.3050800@oracle.com>	<50AA6242.3070908@oracle.com>
	<50AA6354.6040801@oracle.com> <50AC934B.5090702@oracle.com>
	<50AD41D7.3050508@oracle.com>
Message-ID: <C3D8069C-BECB-4280-B48B-692402B34584@oracle.com>

I was able to get past this particular failure by deleting the images directory before each build. It seems to fail only on update for me.

Mike

On Nov 21 2012, at 13:04 , Phil Race wrote:

> Using your workaround I get much further .. it now dies after apparently
> building several repos, but at the start of the JDK repo :-
> 
> Here's my configure output and a log snippet :-
> ------
> A new configuration has been successfully created in
> /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release
> using configure arguments '--with-boot-jdk=c:/jdk1.7'.
> 
> Configuration summary:
> * Debug level:    release
> * JDK variant:    normal
> * JVM variants:   server
> * OpenJDK target: OS: windows, CPU architecture: x86, address length: 64
> 
> Tools summary:
> * Environment:    cygwin version 1.7.8(0.236/5/3) (root at /cygdrive/c/cygwin)
> * Boot JDK:       java version "1.7.0_07"  Java(TM) SE Runtime Environment (buil
> d 1.7.0_07-b11)  Java HotSpot(TM) Client VM (build 23.3-b01, mixed mode, sharing
> )   (at /cygdrive/c/jdk1.7)
> * C Compiler:     Microsoft CL.EXE version 16.00.30319.01 (at /cygdrive/c/vs2010
> /VC/BIN/amd64/cl)
> * C++ Compiler:   Microsoft CL.EXE version 16.00.30319.01 (at /cygdrive/c/vs2010
> /VC/BIN/amd64/cl)
> 
> Build performance summary:
> * Cores to use:   8
> * Memory limit:   4095 MB
> * ccache status:  not available for your system
> ------------------------------
> 
> sh-4.1$ make NEWBUILD=true BUILD_DEPLOY=false BUILD_INSTALL=false
> ....
> 
> tail of log looks like :-
> -----------------------------------
> ## Starting jdk
> make[2]: Entering directory `/cygdrive/c/jdks/2d/jdk/makefiles'
> Compiling 169 files for BUILD_TOOLS
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> make[3]: Entering directory `/cygdrive/c/jdks/2d/jdk/makefiles'
> Importing CORBA classes.jar
> Importing CORBA src.zip
> Importing CORBA bin.zip
> Importing JAXP classes.jar
> Importing JAXP src.zip
> Importing JAXWS src.zip
> Importing JAXWS classes.jar
> Importing LANGTOOLS src.zip
> make[3]: *** [/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/jdk/impsrc/_the.LANGTOOLS.src.imported] Error 126
> make[3]: *** Waiting for unfinished jobs....
> make[3]: Leaving directory `/cygdrive/c/jdks/2d/jdk/makefiles'
> make[2]: *** [import-only] Error 2
> make[2]: Leaving directory `/cygdrive/c/jdks/2d/jdk/makefiles'
> make[1]: *** [jdk-only] Error 2
> make[1]: Leaving directory `/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
> make: *** [all] Error 2
> 
> -------------------------------------
> 
> -phil.
> 
> 
> On 11/21/2012 12:39 AM, Erik Joelsson wrote:
>> Think I found the problem. Created JDK-8003819 for this.
>> 
>> /Erik
>> 
>> On 2012-11-19 17:50, Phil Race wrote:
>>> Ok .. well I already sent you the file.
>>> 
>>> -phil.
>>> 
>>> On 11/19/2012 8:45 AM, Erik Joelsson wrote:
>>>> No, you misunderstand me. That changeset fixed such a problem in CreateJars.gmk. Your error message says spec.gmk, the generated file in the build output dir. I'm suspecting that something to do with a path with backslashes in it has somehow gotten in there, but it's just a guess. I would like to take a look at the resulting spec.gmk regardless to try to figure it out.
>>>> 
>>>> /Erik
>>>> 
>>>> On 2012-11-19 17:43, Phil Race wrote:
>>>>> I'm sure that's why Kelly suggested the changeset below .. since it has such a \
>>>>> but I already fixed that prior to even trying to build.
>>>>> 
>>>>> -phil.
>>>>> 
>>>>> On 11/19/2012 3:18 AM, Erik Joelsson wrote:
>>>>>> My first guess would be a '\' at the end of a line somewhere in the spec.gmk file that cancels out the endif on the next line. Would be interesting to see the full spec.gmk regardless. I haven't seen this happen before in spec but wouldn't be surprised if a backslash from a path somewhere ended up in the wrong place.
>>>>>> 
>>>>>> /Erik
>>>>>> 
>>>>>> On 2012-11-17 00:28, Phil Race wrote:
>>>>>>> I had already applied those two fixes manually and I just
>>>>>>> double-checked and they seem to be there ..
>>>>>>> 
>>>>>>> -phil.
>>>>>>> 
>>>>>>> On 11/16/2012 3:21 PM, Kelly O'Hair wrote:
>>>>>>>> You need this changeset:
>>>>>>>> 
>>>>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/1e79fec4a01f
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -kto
>>>>>>>> 
>>>>>>>> On Nov 16, 2012, at 3:14 PM, Phil Race wrote:
>>>>>>>> 
>>>>>>>>> Can anyone explain what the solution might be to the following
>>>>>>>>> build failure on Windows 7 x64. I'm using our current JDK8 2d team repo :-
>>>>>>>>> 
>>>>>>>>> sh ./configure --with-boot-jdk=c:/jdk1.7
>>>>>>>>> 
>>>>>>>>> make NEWBUILD=true BUILD_DEPLOY=false BUILD_INSTALL=false
>>>>>>>>> No checks yet
>>>>>>>>> cd /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/&&  make all
>>>>>>>>> make[1]: Entering directory `/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
>>>>>>>>> /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/spec.gmk:601: *** missing `endif'.  Stop.
>>>>>>>>> make[1]: Leaving directory `/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
>>>>>>>>> make: *** [all] Error 2
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> line 601 is the last line of spec.gmk and if I add endif afterwards it seems to
>>>>>>>>> at least get past this point but obviously something is wrong.  I looked over
>>>>>>>>> the file and all if's seem balanced to me.
>>>>>>>>> 
>>>>>>>>> Last few lines of the file look like this :- "8(0" looks odd too but
>>>>>>>>> changing that doesn't seem to fix my issue.
>>>>>>>>> 
>>>>>>>>> ----
>>>>>>>>> # Name of Service Agent library
>>>>>>>>> SALIB_NAME=sawindbg.dll
>>>>>>>>> 
>>>>>>>>> OS_VERSION_MAJOR:=1
>>>>>>>>> OS_VERSION_MINOR:=7
>>>>>>>>> OS_VERSION_MICRO:=8(0
>>>>>>>>> 
>>>>>>>>> # Include the custom-spec.gmk file if it exists
>>>>>>>>> -include $(dir /cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/spec.gmk)/custom-spec.gmk
>>>>>>>>> -----
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -phil.
>>>>>>>>> 
>>>>>>> 
>>>>> 
>>> 
> 



From tim.bell at oracle.com  Wed Nov 21 13:49:09 2012
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 21 Nov 2012 13:49:09 -0800
Subject: build problem
In-Reply-To: <50AD41D7.3050508@oracle.com>
References: <50A6C8EA.8080209@oracle.com>	<B37AB3C0-0233-487A-89C5-C7466DEEE87D@oracle.com>	<50A6CC14.30008@oracle.com>	<50AA158B.3080208@oracle.com>
	<50AA61AF.3050800@oracle.com>	<50AA6242.3070908@oracle.com>
	<50AA6354.6040801@oracle.com> <50AC934B.5090702@oracle.com>
	<50AD41D7.3050508@oracle.com>
Message-ID: <50AD4C55.6060407@oracle.com>

On 11/21/12 13:04, Phil Race wrote:
> sh-4.1$ make NEWBUILD=true BUILD_DEPLOY=false BUILD_INSTALL=false 
[... snip!...]
> make[3]: *** 
> [/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/jdk/impsrc/_the.LANGTOOLS.src.imported] 
> Error 126

You are using Windows 7, right?

Searching for 'Error 126' or 'anyone able to build on Win 7' uncovered 
some email threads on mail.openjdk.java.net, but clear answer that I 
could find.

> make[3]: *** Waiting for unfinished jobs....
> make[3]: Leaving directory `/cygdrive/c/jdks/2d/jdk/makefiles'
> make[2]: *** [import-only] Error 2
> make[2]: Leaving directory `/cygdrive/c/jdks/2d/jdk/makefiles'
> make[1]: *** [jdk-only] Error 2
> make[1]: Leaving directory 
> `/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
> make: *** [all] Error 2


Please add 'LOG=debug' to your make command, rerun, and send a pointer 
to that output (or include the tail end of the output with plenty of 
context...).

Thanks-

Tim




From erik.joelsson at oracle.com  Thu Nov 22 00:14:11 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 22 Nov 2012 09:14:11 +0100
Subject: build problem
In-Reply-To: <50AD4C55.6060407@oracle.com>
References: <50A6C8EA.8080209@oracle.com>	<B37AB3C0-0233-487A-89C5-C7466DEEE87D@oracle.com>	<50A6CC14.30008@oracle.com>	<50AA158B.3080208@oracle.com>	<50AA61AF.3050800@oracle.com>	<50AA6242.3070908@oracle.com>	<50AA6354.6040801@oracle.com>
	<50AC934B.5090702@oracle.com>	<50AD41D7.3050508@oracle.com>
	<50AD4C55.6060407@oracle.com>
Message-ID: <50ADDED3.2080600@oracle.com>

This might be something to look into even if I haven't needed to this on 
any of my systems.

http://mail.openjdk.java.net/pipermail/build-dev/2012-February/005594.html

How recently did you update cygwin?

/Erik

On 2012-11-21 22:49, Tim Bell wrote:
> On 11/21/12 13:04, Phil Race wrote:
>> sh-4.1$ make NEWBUILD=true BUILD_DEPLOY=false BUILD_INSTALL=false 
> [... snip!...]
>> make[3]: *** 
>> [/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/jdk/impsrc/_the.LANGTOOLS.src.imported] 
>> Error 126
>
> You are using Windows 7, right?
>
> Searching for 'Error 126' or 'anyone able to build on Win 7' uncovered 
> some email threads on mail.openjdk.java.net, but clear answer that I 
> could find.
>
>> make[3]: *** Waiting for unfinished jobs....
>> make[3]: Leaving directory `/cygdrive/c/jdks/2d/jdk/makefiles'
>> make[2]: *** [import-only] Error 2
>> make[2]: Leaving directory `/cygdrive/c/jdks/2d/jdk/makefiles'
>> make[1]: *** [jdk-only] Error 2
>> make[1]: Leaving directory 
>> `/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
>> make: *** [all] Error 2
>
>
> Please add 'LOG=debug' to your make command, rerun, and send a pointer 
> to that output (or include the tail end of the output with plenty of 
> context...).
>
> Thanks-
>
> Tim
>
>


From david.holmes at oracle.com  Thu Nov 22 16:19:36 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 23 Nov 2012 10:19:36 +1000
Subject: Implicit assumptions in Images.gmk: find errors
Message-ID: <50AEC118.9090405@oracle.com>

Some of the constructs in Images.gmk implicitly assume that you are 
always building a JDK image and a JRE image. Ie.:

JDK_DEMO_TARGETS := $(patsubst 
$(JDK_OUTPUTDIR)/demo/%,$(JDK_IMAGE_DIR)/demo/%,\
                         $(shell $(FIND) $(JDK_OUTPUTDIR)/demo ! \( 
-name "_the*" -o -name "javac_state" \) ))

and:

# /sample dir
$(foreach f,$(shell $(FIND) $(JDK_OUTPUTDIR)/sample -type f),\
     $(eval $(call 
AddFileToCopy,$(JDK_OUTPUTDIR),$(JDK_IMAGE_DIR),$f,JDK_SAMPLE_TARGETS)))


will both attempt to issue "find" in a directory that may not exist 
(jdk/demo and jdk/sample respectively) if you are not building a jdk image.

Fortunately (or perhaps erroneously?) these find failures do not cause 
make to fail, they just generate noisy output (which of course is how I 
noticed it).

Not sure what the solution is or if it is just something we have to live 
with. There is an awful lot of setup needed to build images, but some of 
it is dependent on what image has been requested.

Cheers,
David


From david.holmes at oracle.com  Thu Nov 22 20:23:22 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 23 Nov 2012 14:23:22 +1000
Subject: --debug-configure doesn't quite work
Message-ID: <50AEFA3A.8060702@oracle.com>

I used --debug-configure to try and debug configure but the resulting 
debug log just stops abruptly:

++ WC=/usr/bin/wc
++ test -n /usr/bin/wc
++ printf '%s\n' 'configure:5726: result: /usr/bin/wc'
++ printf '%s\n' /usr/bin/wc
++ test -n /usr/bin/wc
++ break
++ test x/usr/bin/wc = x
++ for ac_prog in which
++ set dummy which
++ ac_word=which
++ printf '%s\n' 'configure:5755: checking for which'
++ printf %s 'checking for which... '
++ false
++ case $WHICH in
++ as_save_IFS='
'
++ IFS=

???

David


From david.holmes at oracle.com  Thu Nov 22 20:47:14 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 23 Nov 2012 14:47:14 +1000
Subject: --debug-configure doesn't quite work
In-Reply-To: <50AEFA3A.8060702@oracle.com>
References: <50AEFA3A.8060702@oracle.com>
Message-ID: <50AEFFD2.5010902@oracle.com>

Okay some weird happened with piping the output into tee. But I got past 
that and then hit this :)

++ files_present='confdefs.h
config.log
debug-configure.log'
+++ /bin/echo 'confdefs.h
config.log
debug-configure.log'
+++ /bin/sed -e s/config.log//g -e s/confdefs.h//g -e 's/ //g'
+++ /usr/bin/tr -d '\n'
++ filtered_files=debug-configure.log
++ test xdebug-configure.log '!=' x
++ printf '%s\n' 'configure:7991: Current directory is 
/java/embedded/users/dh198349/build-infra/builds/b00/se-linux
t-ea.'
++ printf '%s\n' 'configure: Current directory is 
/java/embedded/users/dh198349/build-infra/builds/b00/se-linux.
'
configure: Current directory is 
/java/embedded/users/dh198349/build-infra/builds/b00/se-linux.
configure: Since this is not the source root, configure will output the 
configuration here
configure: (as opposed to creating a configuration in 
<src_root>/build/<conf-name>).
configure: However, this directory is not empty. This is not allowed, 
since it could
configure: seriously mess up just about everything.
configure: Try 'cd /java/embedded/users/dh198349/build-infra' and 
restart configure
configure: (or create a new empty directory and cd to it).

----

Oops! The debug log causes configure to stop configuring. Simple patch 
below:

David
-----


diff -r 811b3b283175 common/autoconf/basics.m4
--- a/common/autoconf/basics.m4
+++ b/common/autoconf/basics.m4
@@ -385,7 +385,7 @@
        files_present=`$LS $OUTPUT_ROOT`
        # Configure has already touched config.log and confdefs.h in the 
current dir when this check
        # is performed.
-      filtered_files=`$ECHO "$files_present" | $SED -e 
's/config.log//g' -e 's/confdefs.h//g' -e 's/ //g' \
+      filtered_files=`$ECHO "$files_present" | $SED -e 
's/config.log//g' -e 's/confdefs.h//g' -e 's/debug-configure.log//g' -e 
's/ //g' \
                                               | $TR -d '\n'`
        if test "x$filtered_files" != x; then
          AC_MSG_NOTICE([Current directory is $CURDIR.])



On 23/11/2012 2:23 PM, David Holmes wrote:
> I used --debug-configure to try and debug configure but the resulting
> debug log just stops abruptly:
>
> ++ WC=/usr/bin/wc
> ++ test -n /usr/bin/wc
> ++ printf '%s\n' 'configure:5726: result: /usr/bin/wc'
> ++ printf '%s\n' /usr/bin/wc
> ++ test -n /usr/bin/wc
> ++ break
> ++ test x/usr/bin/wc = x
> ++ for ac_prog in which
> ++ set dummy which
> ++ ac_word=which
> ++ printf '%s\n' 'configure:5755: checking for which'
> ++ printf %s 'checking for which... '
> ++ false
> ++ case $WHICH in
> ++ as_save_IFS='
> '
> ++ IFS=
>
> ???
>
> David


From erik.joelsson at oracle.com  Fri Nov 23 00:20:30 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 23 Nov 2012 09:20:30 +0100
Subject: Implicit assumptions in Images.gmk: find errors
In-Reply-To: <50AEC118.9090405@oracle.com>
References: <50AEC118.9090405@oracle.com>
Message-ID: <50AF31CE.2090203@oracle.com>

We could condition these finds on the existence of these directories. I 
think that would be the cleanest implementation as it would logically 
act the same as now, just with less noise and execs.

/Erik

On 2012-11-23 01:19, David Holmes wrote:
> Some of the constructs in Images.gmk implicitly assume that you are 
> always building a JDK image and a JRE image. Ie.:
>
> JDK_DEMO_TARGETS := $(patsubst 
> $(JDK_OUTPUTDIR)/demo/%,$(JDK_IMAGE_DIR)/demo/%,\
>                         $(shell $(FIND) $(JDK_OUTPUTDIR)/demo ! \( 
> -name "_the*" -o -name "javac_state" \) ))
>
> and:
>
> # /sample dir
> $(foreach f,$(shell $(FIND) $(JDK_OUTPUTDIR)/sample -type f),\
>     $(eval $(call 
> AddFileToCopy,$(JDK_OUTPUTDIR),$(JDK_IMAGE_DIR),$f,JDK_SAMPLE_TARGETS)))
>
>
> will both attempt to issue "find" in a directory that may not exist 
> (jdk/demo and jdk/sample respectively) if you are not building a jdk 
> image.
>
> Fortunately (or perhaps erroneously?) these find failures do not cause 
> make to fail, they just generate noisy output (which of course is how 
> I noticed it).
>
> Not sure what the solution is or if it is just something we have to 
> live with. There is an awful lot of setup needed to build images, but 
> some of it is dependent on what image has been requested.
>
> Cheers,
> David


From erik.joelsson at oracle.com  Fri Nov 23 00:24:10 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 23 Nov 2012 09:24:10 +0100
Subject: --debug-configure doesn't quite work
In-Reply-To: <50AEFFD2.5010902@oracle.com>
References: <50AEFA3A.8060702@oracle.com> <50AEFFD2.5010902@oracle.com>
Message-ID: <50AF32AA.8030900@oracle.com>

Ouch.. Having to manually keep track of every file configure might 
create in the current directory is annoying. You are most welcome to 
commit this fix to jdk8/build if you have time. Otherwise I will take 
care of it when given a chance.

/Erik

On 2012-11-23 05:47, David Holmes wrote:
> Okay some weird happened with piping the output into tee. But I got 
> past that and then hit this :)
>
> ++ files_present='confdefs.h
> config.log
> debug-configure.log'
> +++ /bin/echo 'confdefs.h
> config.log
> debug-configure.log'
> +++ /bin/sed -e s/config.log//g -e s/confdefs.h//g -e 's/ //g'
> +++ /usr/bin/tr -d '\n'
> ++ filtered_files=debug-configure.log
> ++ test xdebug-configure.log '!=' x
> ++ printf '%s\n' 'configure:7991: Current directory is 
> /java/embedded/users/dh198349/build-infra/builds/b00/se-linux
> t-ea.'
> ++ printf '%s\n' 'configure: Current directory is 
> /java/embedded/users/dh198349/build-infra/builds/b00/se-linux.
> '
> configure: Current directory is 
> /java/embedded/users/dh198349/build-infra/builds/b00/se-linux.
> configure: Since this is not the source root, configure will output 
> the configuration here
> configure: (as opposed to creating a configuration in 
> <src_root>/build/<conf-name>).
> configure: However, this directory is not empty. This is not allowed, 
> since it could
> configure: seriously mess up just about everything.
> configure: Try 'cd /java/embedded/users/dh198349/build-infra' and 
> restart configure
> configure: (or create a new empty directory and cd to it).
>
> ----
>
> Oops! The debug log causes configure to stop configuring. Simple patch 
> below:
>
> David
> -----
>
>
> diff -r 811b3b283175 common/autoconf/basics.m4
> --- a/common/autoconf/basics.m4
> +++ b/common/autoconf/basics.m4
> @@ -385,7 +385,7 @@
>        files_present=`$LS $OUTPUT_ROOT`
>        # Configure has already touched config.log and confdefs.h in 
> the current dir when this check
>        # is performed.
> -      filtered_files=`$ECHO "$files_present" | $SED -e 
> 's/config.log//g' -e 's/confdefs.h//g' -e 's/ //g' \
> +      filtered_files=`$ECHO "$files_present" | $SED -e 
> 's/config.log//g' -e 's/confdefs.h//g' -e 's/debug-configure.log//g' 
> -e 's/ //g' \
>                                               | $TR -d '\n'`
>        if test "x$filtered_files" != x; then
>          AC_MSG_NOTICE([Current directory is $CURDIR.])
>
>
>
> On 23/11/2012 2:23 PM, David Holmes wrote:
>> I used --debug-configure to try and debug configure but the resulting
>> debug log just stops abruptly:
>>
>> ++ WC=/usr/bin/wc
>> ++ test -n /usr/bin/wc
>> ++ printf '%s\n' 'configure:5726: result: /usr/bin/wc'
>> ++ printf '%s\n' /usr/bin/wc
>> ++ test -n /usr/bin/wc
>> ++ break
>> ++ test x/usr/bin/wc = x
>> ++ for ac_prog in which
>> ++ set dummy which
>> ++ ac_word=which
>> ++ printf '%s\n' 'configure:5755: checking for which'
>> ++ printf %s 'checking for which... '
>> ++ false
>> ++ case $WHICH in
>> ++ as_save_IFS='
>> '
>> ++ IFS=
>>
>> ???
>>
>> David


From erik.joelsson at oracle.com  Fri Nov 23 03:02:31 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 23 Nov 2012 11:02:31 +0000
Subject: hg: build-infra/jdk8: 7 new changesets
Message-ID: <20121123110232.DC17C47AF0@hg.openjdk.java.net>

Changeset: 0f100f10c736
Author:    tgranat
Date:      2012-11-21 10:24 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/0f100f10c736

Added accepted bin diffs for ppc builds

! common/bin/compare_exceptions.sh.incl

Changeset: 21b7150f5a7d
Author:    tgranat
Date:      2012-11-21 11:50 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/21b7150f5a7d

Don't probe for cc if building ppc, only probe for gcc

! common/autoconf/toolchain.m4

Changeset: fab9e99e1099
Author:    tgranat
Date:      2012-11-21 11:53 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/fab9e99e1099

Remove -R from X_LIBS if set by set by AC_PATH_XTRA

! common/autoconf/libraries.m4

Changeset: b16d1fd85d29
Author:    tgranat
Date:      2012-11-21 13:53 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/b16d1fd85d29

Regenerated configure

! common/autoconf/generated-configure.sh

Changeset: d7d478b0758b
Author:    erikj
Date:      2012-11-23 09:55 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/d7d478b0758b

Merge

! common/autoconf/generated-configure.sh

Changeset: 92e1d6bb2ff0
Author:    erikj
Date:      2012-11-23 12:01 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/92e1d6bb2ff0

Adding clean-docs target.

! common/makefiles/Main.gmk

Changeset: f3387295de22
Author:    erikj
Date:      2012-11-23 12:01 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/f3387295de22

Merge




From erik.joelsson at oracle.com  Fri Nov 23 03:02:51 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 23 Nov 2012 11:02:51 +0000
Subject: hg: build-infra/jdk8/jdk: 2 new changesets
Message-ID: <20121123110350.416E447AF1@hg.openjdk.java.net>

Changeset: 4d8d940e28ad
Author:    tgranat
Date:      2012-11-21 10:15 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/4d8d940e28ad

Fix error in patching of jvm.cfg, introduced when converting old makefiles.

! makefiles/CopyFiles.gmk

Changeset: 44b1534efdb9
Author:    tgranat
Date:      2012-11-21 10:22 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/44b1534efdb9

To mimic old build, do not build ppc or arm with debug symbols.

! makefiles/CompileDemos.gmk



From david.holmes at oracle.com  Fri Nov 23 04:12:04 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 23 Nov 2012 22:12:04 +1000
Subject: hg: build-infra/jdk8: 7 new changesets
In-Reply-To: <20121123110232.DC17C47AF0@hg.openjdk.java.net>
References: <20121123110232.DC17C47AF0@hg.openjdk.java.net>
Message-ID: <50AF6814.8020409@oracle.com>

Erik,

On 23/11/2012 9:02 PM, erik.joelsson at oracle.com wrote:
> Changeset: 21b7150f5a7d
> Author:    tgranat
> Date:      2012-11-21 11:50 +0100
> URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/21b7150f5a7d
>
> Don't probe for cc if building ppc, only probe for gcc
>
> ! common/autoconf/toolchain.m4

This seems related to my --with-dev-kit problem. But it seems wrong to 
me that the choice of compiler name is somehow related to the architecture.

David
-----


From erik.joelsson at oracle.com  Fri Nov 23 04:26:40 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 23 Nov 2012 13:26:40 +0100
Subject: hg: build-infra/jdk8: 7 new changesets
In-Reply-To: <50AF6814.8020409@oracle.com>
References: <20121123110232.DC17C47AF0@hg.openjdk.java.net>
	<50AF6814.8020409@oracle.com>
Message-ID: <50AF6B80.20904@oracle.com>

Yes, I understand and agree. I'm not currently familiar enough with that 
part of the code to know how to best solve it right now. This change was 
done by tgranat in his effort to get the embedded platforms to compare 
correctly.

/Erik

On 2012-11-23 13:12, David Holmes wrote:
> Erik,
>
> On 23/11/2012 9:02 PM, erik.joelsson at oracle.com wrote:
>> Changeset: 21b7150f5a7d
>> Author:    tgranat
>> Date:      2012-11-21 11:50 +0100
>> URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/21b7150f5a7d
>>
>> Don't probe for cc if building ppc, only probe for gcc
>>
>> ! common/autoconf/toolchain.m4
>
> This seems related to my --with-dev-kit problem. But it seems wrong to 
> me that the choice of compiler name is somehow related to the 
> architecture.
>
> David
> -----


From torbjorn.granat at oracle.com  Fri Nov 23 05:53:27 2012
From: torbjorn.granat at oracle.com (=?UTF-8?B?VG9yYmrDtnJuIEdyYW5hdA==?=)
Date: Fri, 23 Nov 2012 14:53:27 +0100
Subject: hg: build-infra/jdk8: 7 new changesets
In-Reply-To: <50AF6B80.20904@oracle.com>
References: <20121123110232.DC17C47AF0@hg.openjdk.java.net>
	<50AF6814.8020409@oracle.com> <50AF6B80.20904@oracle.com>
Message-ID: <50AF7FD7.8010309@oracle.com>

Hi David and Erik,

Yes, It looks like I ran into the same --with-dev-kit problem as you 
David, when trying to build ppc a couple of days ago (configure found cc 
in the local path and not in the path I gave in --with-dev-kit). I did 
my workaround in toolchain.m4, and I agree that it's a bad solution and 
probably shouldn't have been submitted now that I think of it :-) .

I saw that Magnus did an effort in October to fix a number of things in 
this area, but I don't know if this problem was introduced then.

I will open a bug, so it's not forgotten and can be fixed properly.

/Torbjorn

On 11/23/2012 01:26 PM, Erik Joelsson wrote:
> Yes, I understand and agree. I'm not currently familiar enough with 
> that part of the code to know how to best solve it right now. This 
> change was done by tgranat in his effort to get the embedded platforms 
> to compare correctly.
>
> /Erik
>
> On 2012-11-23 13:12, David Holmes wrote:
>> Erik,
>>
>> On 23/11/2012 9:02 PM, erik.joelsson at oracle.com wrote:
>>> Changeset: 21b7150f5a7d
>>> Author:    tgranat
>>> Date:      2012-11-21 11:50 +0100
>>> URL: http://hg.openjdk.java.net/build-infra/jdk8/rev/21b7150f5a7d
>>>
>>> Don't probe for cc if building ppc, only probe for gcc
>>>
>>> ! common/autoconf/toolchain.m4
>>
>> This seems related to my --with-dev-kit problem. But it seems wrong 
>> to me that the choice of compiler name is somehow related to the 
>> architecture.
>>
>> David
>> -----



From erik.joelsson at oracle.com  Fri Nov 23 07:27:26 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 23 Nov 2012 15:27:26 +0000
Subject: hg: build-infra/jdk8/langtools: Adding missing resource suffix.
Message-ID: <20121123152734.3C56447AF3@hg.openjdk.java.net>

Changeset: 1a55844d7dc0
Author:    erikj
Date:      2012-11-23 16:26 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/langtools/rev/1a55844d7dc0

Adding missing resource suffix.

! makefiles/BuildLangtools.gmk



From erik.joelsson at oracle.com  Fri Nov 23 07:39:16 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 23 Nov 2012 15:39:16 +0000
Subject: hg: build-infra/jdk8/jdk: 2 new changesets
Message-ID: <20121123153958.77E2147AF4@hg.openjdk.java.net>

Changeset: 9d5efe130c70
Author:    erikj
Date:      2012-11-23 16:21 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/9d5efe130c70

Minor cleanups.

! makefiles/CompileJavaClasses.gmk
! makefiles/CompileNativeLibraries.gmk

Changeset: 9b291401a352
Author:    erikj
Date:      2012-11-23 16:22 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/9b291401a352

Merge

! makefiles/CompileJavaClasses.gmk



From erik.joelsson at oracle.com  Fri Nov 23 07:59:13 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 23 Nov 2012 15:59:13 +0000
Subject: hg: build-infra/jdk8: Added dependencies to allow javadocs to be run
	with JOBS!=1.
Message-ID: <20121123155913.999B647AF5@hg.openjdk.java.net>

Changeset: 2d18df411e68
Author:    erikj
Date:      2012-11-23 16:59 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/2d18df411e68

Added dependencies to allow javadocs to be run with JOBS!=1.

! common/makefiles/javadoc/Javadoc.gmk



From erik.joelsson at oracle.com  Fri Nov 23 08:31:39 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 23 Nov 2012 16:31:39 +0000
Subject: hg: build-infra/jdk8: 8003945: build-infra: problems finding compiler
	when using --with-dev-kit
Message-ID: <20121123163139.A7F9347AF6@hg.openjdk.java.net>

Changeset: e3c43ba4342e
Author:    erikj
Date:      2012-11-23 17:31 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/e3c43ba4342e

8003945: build-infra: problems finding compiler when using --with-dev-kit
Summary: If tools-dir (or devkit) is set, first look for compiler only there.

! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4



From erik.joelsson at oracle.com  Fri Nov 23 08:35:13 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 23 Nov 2012 17:35:13 +0100
Subject: hg: build-infra/jdk8: 8003945: build-infra: problems finding
	compiler when using --with-dev-kit
In-Reply-To: <20121123163139.A7F9347AF6@hg.openjdk.java.net>
References: <20121123163139.A7F9347AF6@hg.openjdk.java.net>
Message-ID: <50AFA5C1.2030606@oracle.com>

I finally finished what I was doing and got to take a look at this. 
Would be good if you could try this.

/Erik

On 2012-11-23 17:31, erik.joelsson at oracle.com wrote:
> Changeset: e3c43ba4342e
> Author:    erikj
> Date:      2012-11-23 17:31 +0100
> URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/e3c43ba4342e
>
> 8003945: build-infra: problems finding compiler when using --with-dev-kit
> Summary: If tools-dir (or devkit) is set, first look for compiler only there.
>
> ! common/autoconf/generated-configure.sh
> ! common/autoconf/toolchain.m4
>


From jonathan.gibbons at oracle.com  Fri Nov 23 10:01:16 2012
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 23 Nov 2012 10:01:16 -0800
Subject: hg: build-infra/jdk8: Added dependencies to allow javadocs to
	be run with JOBS!=1.
In-Reply-To: <20121123155913.999B647AF5@hg.openjdk.java.net>
References: <20121123155913.999B647AF5@hg.openjdk.java.net>
Message-ID: <50AFB9EC.2020507@oracle.com>

On 11/23/2012 07:59 AM, erik.joelsson at oracle.com wrote:
> Changeset: 2d18df411e68
> Author:    erikj
> Date:      2012-11-23 16:59 +0100
> URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/2d18df411e68
>
> Added dependencies to allow javadocs to be run with JOBS!=1.
>
> ! common/makefiles/javadoc/Javadoc.gmk
>

Nice to see javadoc getting some build-infra TLC.

-- Jon


From david.holmes at oracle.com  Fri Nov 23 16:32:49 2012
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 24 Nov 2012 10:32:49 +1000
Subject: hg: build-infra/jdk8: 8003945: build-infra: problems finding
	compiler when using --with-dev-kit
In-Reply-To: <50AFA5C1.2030606@oracle.com>
References: <20121123163139.A7F9347AF6@hg.openjdk.java.net>
	<50AFA5C1.2030606@oracle.com>
Message-ID: <50B015B1.4080406@oracle.com>

Terrific! Thanks Erik.

I'll pull this into the profiles repo too.

David

On 24/11/2012 2:35 AM, Erik Joelsson wrote:
> I finally finished what I was doing and got to take a look at this.
> Would be good if you could try this.
>
> /Erik
>
> On 2012-11-23 17:31, erik.joelsson at oracle.com wrote:
>> Changeset: e3c43ba4342e
>> Author: erikj
>> Date: 2012-11-23 17:31 +0100
>> URL: http://hg.openjdk.java.net/build-infra/jdk8/rev/e3c43ba4342e
>>
>> 8003945: build-infra: problems finding compiler when using --with-dev-kit
>> Summary: If tools-dir (or devkit) is set, first look for compiler only
>> there.
>>
>> ! common/autoconf/generated-configure.sh
>> ! common/autoconf/toolchain.m4
>>


From Alan.Bateman at oracle.com  Sat Nov 24 09:57:30 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 24 Nov 2012 17:57:30 +0000
Subject: Building 32-bit binaries on Solaris
Message-ID: <50B10A8A.3080305@oracle.com>


I'm on a Solaris SPARC system and by default the new build generates 
solaris-sparcv9 binaries. I'm looking to create 32-bit binaries which is 
the default on the old build system (unless you specify ARCH_DATA_MODEL) 
and trying to figure out the options to specify to configure. The guide 
suggests that --with-host-bits is Windows only. Is a build of 32-bit 
binaries considered a cross compile and should I specify --host?

-Alan


From Alan.Bateman at oracle.com  Sat Nov 24 11:04:07 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 24 Nov 2012 19:04:07 +0000
Subject: Building 32-bit binaries on Solaris
In-Reply-To: <50B10A8A.3080305@oracle.com>
References: <50B10A8A.3080305@oracle.com>
Message-ID: <50B11A27.3040306@oracle.com>

On 24/11/2012 17:57, Alan Bateman wrote:
>
> I'm on a Solaris SPARC system and by default the new build generates 
> solaris-sparcv9 binaries. I'm looking to create 32-bit binaries which 
> is the default on the old build system (unless you specify 
> ARCH_DATA_MODEL) and trying to figure out the options to specify to 
> configure. The guide suggests that --with-host-bits is Windows only. 
> Is a build of 32-bit binaries considered a cross compile and should I 
> specify --host?
>
> -Alan
Never mind, I found --with-target-bits=32. It might be good to get this 
added to the guide as it's not very obvious that the default is 64-bit 
whereas we are used to it being 32-bit on Solaris.

-Alan


From Alan.Bateman at oracle.com  Sat Nov 24 11:38:20 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 24 Nov 2012 19:38:20 +0000
Subject: jarsigner
Message-ID: <50B1222C.80700@oracle.com>


In CompileLauncher.gmk then jarsigner is created to launch 
sun.security.tools.jarSigner.Main but there's a typo (should be 
"jarsigner", all lowercase). I ran into this because all tests that use 
jarsigner are failing with the new build.

-Alan


From tim.bell at oracle.com  Sat Nov 24 11:50:44 2012
From: tim.bell at oracle.com (Tim Bell)
Date: Sat, 24 Nov 2012 11:50:44 -0800
Subject: Building 32-bit binaries on Solaris
In-Reply-To: <50B10A8A.3080305@oracle.com>
References: <50B10A8A.3080305@oracle.com>
Message-ID: <50B12514.7080008@oracle.com>

Hi Alan:

> I'm on a Solaris SPARC system and by default the new build generates 
> solaris-sparcv9 binaries. I'm looking to create 32-bit binaries which 
> is the default on the old build system (unless you specify 
> ARCH_DATA_MODEL) and trying to figure out the options to specify to 
> configure. The guide suggests that --with-host-bits is Windows only. 
> Is a build of 32-bit binaries considered a cross compile and should I 
> specify --host?

On my SPARC test system, running configure using '--with-target-bits=32' 
did the job, and created a configuration called 
'solaris-sparc-normal-server-release' right beside my existing 
'solaris-sparcv9-normal-server-release':

cd <top of tree>

sh ./configure \
     --with-tools-dir=/opt/devtools/sparc/SUNWspro/sunstudio12.1/bin \
     --with-cups=/opt/devtools/share/cups \
     --with-target-bits=32
[... snip ...]
Configuration summary:
* Debug level:    release
* JDK variant:    normal
* JVM variants:   server
* OpenJDK target: OS: solaris, CPU architecture: sparc, address length: 32


The build ran in 33 minutes (this was on a SPARC LDOM with 4CPUs granted 
to it, so nothing special to write home about):


% cd build/solaris-sparc-normal-server-release
% gmake all
Building Java(TM) for target 'all' in configuration 
'solaris-sparc-normal-server-release'
[... snip ...]
Finished building Java(TM) for target 'all'

% file jdk/bin/java
jdk/bin/java:   ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ 
Required, dynamically linked, not stripped

% jdk/bin/java -version
java version "1.8.0-internal"
Java(TM) SE Runtime Environment (build 
1.8.0-internal-tbell_2012_11_24_10_59-b00)
Java HotSpot(TM) Server VM (build 25.0-b09, mixed mode)

Hope this helps-

Tim



From kelly.ohair at oracle.com  Sun Nov 25 10:05:57 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Sun, 25 Nov 2012 10:05:57 -0800
Subject: Implicit assumptions in Images.gmk: find errors
In-Reply-To: <50AF31CE.2090203@oracle.com>
References: <50AEC118.9090405@oracle.com> <50AF31CE.2090203@oracle.com>
Message-ID: <DB47D41A-2488-4701-AE92-AC5262F52BA3@oracle.com>

That sounds right.

The demos really need to be built from the built jdk image.
So in my opinion, the demos should follow the jdk image creation.

I think in the old build it was a bit mixed up as to when the demos were built.

-kto

On Nov 23, 2012, at 12:20 AM, Erik Joelsson wrote:

> We could condition these finds on the existence of these directories. I think that would be the cleanest implementation as it would logically act the same as now, just with less noise and execs.
> 
> /Erik
> 
> On 2012-11-23 01:19, David Holmes wrote:
>> Some of the constructs in Images.gmk implicitly assume that you are always building a JDK image and a JRE image. Ie.:
>> 
>> JDK_DEMO_TARGETS := $(patsubst $(JDK_OUTPUTDIR)/demo/%,$(JDK_IMAGE_DIR)/demo/%,\
>>                        $(shell $(FIND) $(JDK_OUTPUTDIR)/demo ! \( -name "_the*" -o -name "javac_state" \) ))
>> 
>> and:
>> 
>> # /sample dir
>> $(foreach f,$(shell $(FIND) $(JDK_OUTPUTDIR)/sample -type f),\
>>    $(eval $(call AddFileToCopy,$(JDK_OUTPUTDIR),$(JDK_IMAGE_DIR),$f,JDK_SAMPLE_TARGETS)))
>> 
>> 
>> will both attempt to issue "find" in a directory that may not exist (jdk/demo and jdk/sample respectively) if you are not building a jdk image.
>> 
>> Fortunately (or perhaps erroneously?) these find failures do not cause make to fail, they just generate noisy output (which of course is how I noticed it).
>> 
>> Not sure what the solution is or if it is just something we have to live with. There is an awful lot of setup needed to build images, but some of it is dependent on what image has been requested.
>> 
>> Cheers,
>> David



From david.holmes at oracle.com  Sun Nov 25 14:36:30 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 26 Nov 2012 08:36:30 +1000
Subject: Implicit assumptions in Images.gmk: find errors
In-Reply-To: <DB47D41A-2488-4701-AE92-AC5262F52BA3@oracle.com>
References: <50AEC118.9090405@oracle.com> <50AF31CE.2090203@oracle.com>
	<DB47D41A-2488-4701-AE92-AC5262F52BA3@oracle.com>
Message-ID: <50B29D6E.9060308@oracle.com>

On 26/11/2012 4:05 AM, Kelly O'Hair wrote:
> That sounds right.
>
> The demos really need to be built from the built jdk image.
> So in my opinion, the demos should follow the jdk image creation.

The actual building of the demos does.

The problem is that the logic that sets up the lists of files for 
various targets is always executed, regardless of which target has been 
requested.

David
-----

> I think in the old build it was a bit mixed up as to when the demos were built.
>
> -kto
>
> On Nov 23, 2012, at 12:20 AM, Erik Joelsson wrote:
>
>> We could condition these finds on the existence of these directories. I think that would be the cleanest implementation as it would logically act the same as now, just with less noise and execs.
>>
>> /Erik
>>
>> On 2012-11-23 01:19, David Holmes wrote:
>>> Some of the constructs in Images.gmk implicitly assume that you are always building a JDK image and a JRE image. Ie.:
>>>
>>> JDK_DEMO_TARGETS := $(patsubst $(JDK_OUTPUTDIR)/demo/%,$(JDK_IMAGE_DIR)/demo/%,\
>>>                         $(shell $(FIND) $(JDK_OUTPUTDIR)/demo ! \( -name "_the*" -o -name "javac_state" \) ))
>>>
>>> and:
>>>
>>> # /sample dir
>>> $(foreach f,$(shell $(FIND) $(JDK_OUTPUTDIR)/sample -type f),\
>>>     $(eval $(call AddFileToCopy,$(JDK_OUTPUTDIR),$(JDK_IMAGE_DIR),$f,JDK_SAMPLE_TARGETS)))
>>>
>>>
>>> will both attempt to issue "find" in a directory that may not exist (jdk/demo and jdk/sample respectively) if you are not building a jdk image.
>>>
>>> Fortunately (or perhaps erroneously?) these find failures do not cause make to fail, they just generate noisy output (which of course is how I noticed it).
>>>
>>> Not sure what the solution is or if it is just something we have to live with. There is an awful lot of setup needed to build images, but some of it is dependent on what image has been requested.
>>>
>>> Cheers,
>>> David
>


From david.holmes at oracle.com  Sun Nov 25 17:46:57 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 26 Nov 2012 11:46:57 +1000
Subject: sizer compilation has been broken for cross-compiles
Message-ID: <50B2CA11.2090301@oracle.com>

This changeset

changeset:   6067:dcee387cde81
user:        ohrstrom
date:        Mon Oct 29 13:41:38 2012 -0700
summary:     8001891: build-infra: Adding X_CFLAGS and X_LIBS to lwawt 
and sizer compilation

diff -r 5b29d6157504 -r dcee387cde81 makefiles/GensrcX11Wrappers.gmk
--- a/makefiles/GensrcX11Wrappers.gmk
+++ b/makefiles/GensrcX11Wrappers.gmk
@@ -64,6 +64,8 @@
         $(MKDIR) -p $(@D)
         $(RM) $@ $@.tmp
         (cd $(@D) && $(BUILD_CC) -m$* -o $@.tmp $< \
+              $(X_CFLAGS) \
+              $(X_LIBS) \
                -I$(JDK_OUTPUTDIR)/include \
                -I$(JDK_TOPDIR)/src/share/javavm/export \
 
-I$(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS_API_DIR)/javavm/export \

breaks cross-compilation as the values in X_CFLAGS and X_LIBS are those 
of the cross-compiler, not the build machine compiler that will create 
the sizers executable.

Not sure why sizers needs the above even when not cross-compiling - it 
is a very basic program that just needs access to the right header 
files. Does it need special compiler flags or lib options ??

I've filed https://jbs.oracle.com/bugs/browse/JDK-8003958 to track this 
as it has already 'escaped'. I'll have to pull it out of the profiles 
forest for now.

Thanks,
David
-----



From erik.joelsson at oracle.com  Mon Nov 26 00:20:34 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 26 Nov 2012 09:20:34 +0100
Subject: Implicit assumptions in Images.gmk: find errors
In-Reply-To: <50B29D6E.9060308@oracle.com>
References: <50AEC118.9090405@oracle.com> <50AF31CE.2090203@oracle.com>
	<DB47D41A-2488-4701-AE92-AC5262F52BA3@oracle.com>
	<50B29D6E.9060308@oracle.com>
Message-ID: <50B32652.1070601@oracle.com>

It can still be put inside an "ifneq ($(wildcard 
$(JDK_OUTPUTDIR)/demos),)" which should prevent it from executing.

/Erik


On 2012-11-25 23:36, David Holmes wrote:
> On 26/11/2012 4:05 AM, Kelly O'Hair wrote:
>> That sounds right.
>>
>> The demos really need to be built from the built jdk image.
>> So in my opinion, the demos should follow the jdk image creation.
>
> The actual building of the demos does.
>
> The problem is that the logic that sets up the lists of files for 
> various targets is always executed, regardless of which target has 
> been requested.
>
> David
> -----
>
>> I think in the old build it was a bit mixed up as to when the demos 
>> were built.
>>
>> -kto
>>
>> On Nov 23, 2012, at 12:20 AM, Erik Joelsson wrote:
>>
>>> We could condition these finds on the existence of these 
>>> directories. I think that would be the cleanest implementation as it 
>>> would logically act the same as now, just with less noise and execs.
>>>
>>> /Erik
>>>
>>> On 2012-11-23 01:19, David Holmes wrote:
>>>> Some of the constructs in Images.gmk implicitly assume that you are 
>>>> always building a JDK image and a JRE image. Ie.:
>>>>
>>>> JDK_DEMO_TARGETS := $(patsubst 
>>>> $(JDK_OUTPUTDIR)/demo/%,$(JDK_IMAGE_DIR)/demo/%,\
>>>>                         $(shell $(FIND) $(JDK_OUTPUTDIR)/demo ! \( 
>>>> -name "_the*" -o -name "javac_state" \) ))
>>>>
>>>> and:
>>>>
>>>> # /sample dir
>>>> $(foreach f,$(shell $(FIND) $(JDK_OUTPUTDIR)/sample -type f),\
>>>>     $(eval $(call 
>>>> AddFileToCopy,$(JDK_OUTPUTDIR),$(JDK_IMAGE_DIR),$f,JDK_SAMPLE_TARGETS))) 
>>>>
>>>>
>>>>
>>>> will both attempt to issue "find" in a directory that may not exist 
>>>> (jdk/demo and jdk/sample respectively) if you are not building a 
>>>> jdk image.
>>>>
>>>> Fortunately (or perhaps erroneously?) these find failures do not 
>>>> cause make to fail, they just generate noisy output (which of 
>>>> course is how I noticed it).
>>>>
>>>> Not sure what the solution is or if it is just something we have to 
>>>> live with. There is an awful lot of setup needed to build images, 
>>>> but some of it is dependent on what image has been requested.
>>>>
>>>> Cheers,
>>>> David
>>


From erik.joelsson at oracle.com  Mon Nov 26 00:25:17 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 26 Nov 2012 09:25:17 +0100
Subject: Implicit assumptions in Images.gmk: find errors
In-Reply-To: <DB47D41A-2488-4701-AE92-AC5262F52BA3@oracle.com>
References: <50AEC118.9090405@oracle.com> <50AF31CE.2090203@oracle.com>
	<DB47D41A-2488-4701-AE92-AC5262F52BA3@oracle.com>
Message-ID: <50B3276D.8070902@oracle.com>

The demos are built using the bootstrap javac, running on the boot jdk 
and linked against the newly built classes. The next step would be 
executing on the newly built jdk, but I don't think we need to go that 
far. The end result is logically the same (as in the same compiler is 
used and the same classes are linked against) and I would rather avoid 
the complications for cross compilation.

/Erik

On 2012-11-25 19:05, Kelly O'Hair wrote:
> That sounds right.
>
> The demos really need to be built from the built jdk image.
> So in my opinion, the demos should follow the jdk image creation.
>
> I think in the old build it was a bit mixed up as to when the demos were built.
>
> -kto
>
> On Nov 23, 2012, at 12:20 AM, Erik Joelsson wrote:
>
>> We could condition these finds on the existence of these directories. I think that would be the cleanest implementation as it would logically act the same as now, just with less noise and execs.
>>
>> /Erik
>>
>> On 2012-11-23 01:19, David Holmes wrote:
>>> Some of the constructs in Images.gmk implicitly assume that you are always building a JDK image and a JRE image. Ie.:
>>>
>>> JDK_DEMO_TARGETS := $(patsubst $(JDK_OUTPUTDIR)/demo/%,$(JDK_IMAGE_DIR)/demo/%,\
>>>                         $(shell $(FIND) $(JDK_OUTPUTDIR)/demo ! \( -name "_the*" -o -name "javac_state" \) ))
>>>
>>> and:
>>>
>>> # /sample dir
>>> $(foreach f,$(shell $(FIND) $(JDK_OUTPUTDIR)/sample -type f),\
>>>     $(eval $(call AddFileToCopy,$(JDK_OUTPUTDIR),$(JDK_IMAGE_DIR),$f,JDK_SAMPLE_TARGETS)))
>>>
>>>
>>> will both attempt to issue "find" in a directory that may not exist (jdk/demo and jdk/sample respectively) if you are not building a jdk image.
>>>
>>> Fortunately (or perhaps erroneously?) these find failures do not cause make to fail, they just generate noisy output (which of course is how I noticed it).
>>>
>>> Not sure what the solution is or if it is just something we have to live with. There is an awful lot of setup needed to build images, but some of it is dependent on what image has been requested.
>>>
>>> Cheers,
>>> David


From erik.joelsson at oracle.com  Mon Nov 26 00:32:04 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 26 Nov 2012 09:32:04 +0100
Subject: Building 32-bit binaries on Solaris
In-Reply-To: <50B11A27.3040306@oracle.com>
References: <50B10A8A.3080305@oracle.com> <50B11A27.3040306@oracle.com>
Message-ID: <50B32904.5040804@oracle.com>

On 2012-11-24 20:04, Alan Bateman wrote:
> On 24/11/2012 17:57, Alan Bateman wrote:
>>
>> I'm on a Solaris SPARC system and by default the new build generates 
>> solaris-sparcv9 binaries. I'm looking to create 32-bit binaries which 
>> is the default on the old build system (unless you specify 
>> ARCH_DATA_MODEL) and trying to figure out the options to specify to 
>> configure. The guide suggests that --with-host-bits is Windows only. 
>> Is a build of 32-bit binaries considered a cross compile and should I 
>> specify --host?
>>
>> -Alan
> Never mind, I found --with-target-bits=32. It might be good to get 
> this added to the guide as it's not very obvious that the default is 
> 64-bit whereas we are used to it being 32-bit on Solaris.
>
> -Alan

The documentation surely needs to be updated. I will try to get the 
biggest out of date info corrected today at least.

The default was changed to be consistent on all platforms. I think 
that's a good idea, but I wouldn't fight for it if 32bit would still be 
preferred as default.

Also note that by default, only server version of hotspot is built, so 
if you want what was default before, you will also need 
--with-jvm-variants=client,server, which doubles the compile time for 
hotspot.

/Erik


From erik.joelsson at oracle.com  Mon Nov 26 00:40:08 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Mon, 26 Nov 2012 08:40:08 +0000
Subject: hg: build-infra/jdk8/jdk: 8003960: build-infra: Jarsigner launcher
	has wrong classname
Message-ID: <20121126084104.100D747B1B@hg.openjdk.java.net>

Changeset: c55b30b48b55
Author:    erikj
Date:      2012-11-26 09:39 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/c55b30b48b55

8003960: build-infra: Jarsigner launcher has wrong classname
Summary: Fixed typo in package name

! makefiles/CompileLaunchers.gmk



From erik.joelsson at oracle.com  Mon Nov 26 00:46:47 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 26 Nov 2012 09:46:47 +0100
Subject: Review Request: 8003960: build-infra: Jarsigner launcher has wrong
	classname
In-Reply-To: <50B1222C.80700@oracle.com>
References: <50B1222C.80700@oracle.com>
Message-ID: <50B32C77.5050402@oracle.com>

Fix for the issue reported below:

http://cr.openjdk.java.net/~erikj/8003960/webrev.jdk.01/ 
<http://cr.openjdk.java.net/%7Eerikj/8003960/webrev.jdk.01/>

/Erik

On 2012-11-24 20:38, Alan Bateman wrote:
>
> In CompileLauncher.gmk then jarsigner is created to launch 
> sun.security.tools.jarSigner.Main but there's a typo (should be 
> "jarsigner", all lowercase). I ran into this because all tests that 
> use jarsigner are failing with the new build.
>
> -Alan


From Alan.Bateman at oracle.com  Mon Nov 26 01:32:37 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 26 Nov 2012 09:32:37 +0000
Subject: Review Request: 8003960: build-infra: Jarsigner launcher has
	wrong classname
In-Reply-To: <50B32C77.5050402@oracle.com>
References: <50B1222C.80700@oracle.com> <50B32C77.5050402@oracle.com>
Message-ID: <50B33735.6070206@oracle.com>

On 26/11/2012 08:46, Erik Joelsson wrote:
> Fix for the issue reported below:
>
> http://cr.openjdk.java.net/~erikj/8003960/webrev.jdk.01/ 
> <http://cr.openjdk.java.net/%7Eerikj/8003960/webrev.jdk.01/>
>
> /Erik
Looks good to me, thanks for fixing this (and I can confirm that tests 
that use jarsigner work again with this patch).

-Alan


From Alan.Bateman at oracle.com  Mon Nov 26 01:42:04 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 26 Nov 2012 09:42:04 +0000
Subject: Building 32-bit binaries on Solaris
In-Reply-To: <50B32904.5040804@oracle.com>
References: <50B10A8A.3080305@oracle.com> <50B11A27.3040306@oracle.com>
	<50B32904.5040804@oracle.com>
Message-ID: <50B3396C.4010307@oracle.com>

On 26/11/2012 08:32, Erik Joelsson wrote:
>
> The documentation surely needs to be updated. I will try to get the 
> biggest out of date info corrected today at least.
>
> The default was changed to be consistent on all platforms. I think 
> that's a good idea, but I wouldn't fight for it if 32bit would still 
> be preferred as default.
>
> Also note that by default, only server version of hotspot is built, so 
> if you want what was default before, you will also need 
> --with-jvm-variants=client,server, which doubles the compile time for 
> hotspot.
I think it's reasonable to default to 64-bit, just awkward on Solaris 
because the 64-bit build overlays over the 32-bit build. I've often 
thought we should move away from this anyway and just have separate 
images like we do on Linux and Windows. I realize there is a 
counter-argument to have both 32-bit and 64-bit in the same image on 
Linux and Windows too, but that is going to be highly problematic when 
we move to modules. As it stands then it looks to me that the new build 
will create a Solaris 64-bit image that is usable, although I see this 
confuses a lot of tests. FYI, in jigsaw/jigsaw then the Solaris 64-bit 
build is a also complete image, no support for overlaying.

-Alan.



From erik.joelsson at oracle.com  Mon Nov 26 01:53:31 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 26 Nov 2012 10:53:31 +0100
Subject: Building 32-bit binaries on Solaris
In-Reply-To: <50B3396C.4010307@oracle.com>
References: <50B10A8A.3080305@oracle.com> <50B11A27.3040306@oracle.com>
	<50B32904.5040804@oracle.com> <50B3396C.4010307@oracle.com>
Message-ID: <50B33C1B.1030003@oracle.com>

In build-infra we support both the full image and the overlay image for 
64-bit solaris. The images target builds the full image and 
overlay-images builds the overlay. I can imagine this confusing tests so 
default behavior might need to change, I'm not sure.

I just pushed an update to the documentation, but I believe there is a 
small delay before it goes live.

/Erik

On 2012-11-26 10:42, Alan Bateman wrote:
> On 26/11/2012 08:32, Erik Joelsson wrote:
>>
>> The documentation surely needs to be updated. I will try to get the 
>> biggest out of date info corrected today at least.
>>
>> The default was changed to be consistent on all platforms. I think 
>> that's a good idea, but I wouldn't fight for it if 32bit would still 
>> be preferred as default.
>>
>> Also note that by default, only server version of hotspot is built, 
>> so if you want what was default before, you will also need 
>> --with-jvm-variants=client,server, which doubles the compile time for 
>> hotspot.
> I think it's reasonable to default to 64-bit, just awkward on Solaris 
> because the 64-bit build overlays over the 32-bit build. I've often 
> thought we should move away from this anyway and just have separate 
> images like we do on Linux and Windows. I realize there is a 
> counter-argument to have both 32-bit and 64-bit in the same image on 
> Linux and Windows too, but that is going to be highly problematic when 
> we move to modules. As it stands then it looks to me that the new 
> build will create a Solaris 64-bit image that is usable, although I 
> see this confuses a lot of tests. FYI, in jigsaw/jigsaw then the 
> Solaris 64-bit build is a also complete image, no support for overlaying.
>
> -Alan.
>


From erik.joelsson at oracle.com  Mon Nov 26 02:21:07 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Mon, 26 Nov 2012 10:21:07 +0000
Subject: hg: build-infra/jdk8/langtools: Removing redundant suffix from list.
Message-ID: <20121126102110.1ED9D47B1C@hg.openjdk.java.net>

Changeset: 9b304e38f605
Author:    erikj
Date:      2012-11-26 11:20 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/langtools/rev/9b304e38f605

Removing redundant suffix from list.

! makefiles/BuildLangtools.gmk



From fredrik.ohrstrom at oracle.com  Mon Nov 26 02:56:25 2012
From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com)
Date: Mon, 26 Nov 2012 10:56:25 +0000
Subject: hg: build-infra/jdk8/jdk: Fix for problematic platform dependent
	sizes generation.
Message-ID: <20121126105940.714FA47B1D@hg.openjdk.java.net>

Changeset: e599b2e1f052
Author:    ohrstrom
Date:      2012-11-26 11:54 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/e599b2e1f052

Fix for problematic platform dependent sizes generation.

! makefiles/GensrcX11Wrappers.gmk
+ src/solaris/classes/sun/awt/X11/generator/sizes.32
+ src/solaris/classes/sun/awt/X11/generator/sizes.64
- src/solaris/classes/sun/awt/X11/generator/sizes.64-solaris-i386



From oehrstroem at gmail.com  Mon Nov 26 03:03:02 2012
From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=)
Date: Mon, 26 Nov 2012 12:03:02 +0100
Subject: sizer compilation has been broken for cross-compiles
In-Reply-To: <50B2CA11.2090301@oracle.com>
References: <50B2CA11.2090301@oracle.com>
Message-ID: <CALZT+jCR-ir71XSCe6CZRBK9D5_Ep=e5bPeXh+XUeLcwCUNjaA@mail.gmail.com>

Hi David! Please apply the following patch, and let me know if it
solves your problems!

//Fredrik

Changeset: e599b2e1f052
Author:    ohrstrom
Date:      2012-11-26 11:54 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/e599b2e1f052

Fix for problematic platform dependent sizes generation.

! makefiles/GensrcX11Wrappers.gmk
+ src/solaris/classes/sun/awt/X11/generator/sizes.32
+ src/solaris/classes/sun/awt/X11/generator/sizes.64
- src/solaris/classes/sun/awt/X11/generator/sizes.64-solaris-i386


2012/11/26 David Holmes <david.holmes at oracle.com>:
> This changeset
>
> changeset:   6067:dcee387cde81
> user:        ohrstrom
> date:        Mon Oct 29 13:41:38 2012 -0700
> summary:     8001891: build-infra: Adding X_CFLAGS and X_LIBS to lwawt and
> sizer compilation
>
> diff -r 5b29d6157504 -r dcee387cde81 makefiles/GensrcX11Wrappers.gmk
> --- a/makefiles/GensrcX11Wrappers.gmk
> +++ b/makefiles/GensrcX11Wrappers.gmk
> @@ -64,6 +64,8 @@
>         $(MKDIR) -p $(@D)
>         $(RM) $@ $@.tmp
>         (cd $(@D) && $(BUILD_CC) -m$* -o $@.tmp $< \
> +              $(X_CFLAGS) \
> +              $(X_LIBS) \
>                -I$(JDK_OUTPUTDIR)/include \
>                -I$(JDK_TOPDIR)/src/share/javavm/export \
>
> -I$(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS_API_DIR)/javavm/export \
>
> breaks cross-compilation as the values in X_CFLAGS and X_LIBS are those of
> the cross-compiler, not the build machine compiler that will create the
> sizers executable.
>
> Not sure why sizers needs the above even when not cross-compiling - it is a
> very basic program that just needs access to the right header files. Does it
> need special compiler flags or lib options ??
>
> I've filed https://jbs.oracle.com/bugs/browse/JDK-8003958 to track this as
> it has already 'escaped'. I'll have to pull it out of the profiles forest
> for now.
>
> Thanks,
> David
> -----
>


From david.holmes at oracle.com  Mon Nov 26 04:52:36 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 26 Nov 2012 22:52:36 +1000
Subject: sizer compilation has been broken for cross-compiles
In-Reply-To: <CALZT+jCR-ir71XSCe6CZRBK9D5_Ep=e5bPeXh+XUeLcwCUNjaA@mail.gmail.com>
References: <50B2CA11.2090301@oracle.com>
	<CALZT+jCR-ir71XSCe6CZRBK9D5_Ep=e5bPeXh+XUeLcwCUNjaA@mail.gmail.com>
Message-ID: <50B36614.2050604@oracle.com>

Hi Fredrik,

I suspect it will of course solve the build problem because you won't 
now be building anything. But is it the right solution? If we can do 
this for cross-compiling why do we ever need to generate these files? 
And why did you make the previous change? It still seems to me that 
things were working fine before that.

I don't have any means to actually validate this change.

David

On 26/11/2012 9:03 PM, Fredrik ?hrstr?m wrote:
> Hi David! Please apply the following patch, and let me know if it
> solves your problems!
>
> //Fredrik
>
> Changeset: e599b2e1f052
> Author:    ohrstrom
> Date:      2012-11-26 11:54 +0100
> URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/e599b2e1f052
>
> Fix for problematic platform dependent sizes generation.
>
> ! makefiles/GensrcX11Wrappers.gmk
> + src/solaris/classes/sun/awt/X11/generator/sizes.32
> + src/solaris/classes/sun/awt/X11/generator/sizes.64
> - src/solaris/classes/sun/awt/X11/generator/sizes.64-solaris-i386
>
>
> 2012/11/26 David Holmes<david.holmes at oracle.com>:
>> This changeset
>>
>> changeset:   6067:dcee387cde81
>> user:        ohrstrom
>> date:        Mon Oct 29 13:41:38 2012 -0700
>> summary:     8001891: build-infra: Adding X_CFLAGS and X_LIBS to lwawt and
>> sizer compilation
>>
>> diff -r 5b29d6157504 -r dcee387cde81 makefiles/GensrcX11Wrappers.gmk
>> --- a/makefiles/GensrcX11Wrappers.gmk
>> +++ b/makefiles/GensrcX11Wrappers.gmk
>> @@ -64,6 +64,8 @@
>>          $(MKDIR) -p $(@D)
>>          $(RM) $@ $@.tmp
>>          (cd $(@D)&&  $(BUILD_CC) -m$* -o $@.tmp $<  \
>> +              $(X_CFLAGS) \
>> +              $(X_LIBS) \
>>                 -I$(JDK_OUTPUTDIR)/include \
>>                 -I$(JDK_TOPDIR)/src/share/javavm/export \
>>
>> -I$(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS_API_DIR)/javavm/export \
>>
>> breaks cross-compilation as the values in X_CFLAGS and X_LIBS are those of
>> the cross-compiler, not the build machine compiler that will create the
>> sizers executable.
>>
>> Not sure why sizers needs the above even when not cross-compiling - it is a
>> very basic program that just needs access to the right header files. Does it
>> need special compiler flags or lib options ??
>>
>> I've filed https://jbs.oracle.com/bugs/browse/JDK-8003958 to track this as
>> it has already 'escaped'. I'll have to pull it out of the profiles forest
>> for now.
>>
>> Thanks,
>> David
>> -----
>>


From erik.joelsson at oracle.com  Mon Nov 26 05:21:05 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 26 Nov 2012 14:21:05 +0100
Subject: sizer compilation has been broken for cross-compiles
In-Reply-To: <50B36614.2050604@oracle.com>
References: <50B2CA11.2090301@oracle.com>	<CALZT+jCR-ir71XSCe6CZRBK9D5_Ep=e5bPeXh+XUeLcwCUNjaA@mail.gmail.com>
	<50B36614.2050604@oracle.com>
Message-ID: <50B36CC1.6090204@oracle.com>

Handling this is tricky. As I understand it, for cross compilation it 
works as long as the host and target are both 32-bit, which seems more 
like coincidence to me. Compiling the generators for the host platform 
doesn't make sense, it just happens to work in some cases.

The idea of only generating these when not cross compiling sounds weird 
to me too. The advantage is that when we aren't cross compiling these 
generators are validated. In reality, I don't think the output of the 
generators change often, if at all. This is still a reasonable compromise.

The third option would be to not generate them in the build at all, but 
to use the pre generated data.

/Erik

On 2012-11-26 13:52, David Holmes wrote:
> Hi Fredrik,
>
> I suspect it will of course solve the build problem because you won't 
> now be building anything. But is it the right solution? If we can do 
> this for cross-compiling why do we ever need to generate these files? 
> And why did you make the previous change? It still seems to me that 
> things were working fine before that.
>
> I don't have any means to actually validate this change.
>
> David
>
> On 26/11/2012 9:03 PM, Fredrik ?hrstr?m wrote:
>> Hi David! Please apply the following patch, and let me know if it
>> solves your problems!
>>
>> //Fredrik
>>
>> Changeset: e599b2e1f052
>> Author:    ohrstrom
>> Date:      2012-11-26 11:54 +0100
>> URL:       
>> http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/e599b2e1f052
>>
>> Fix for problematic platform dependent sizes generation.
>>
>> ! makefiles/GensrcX11Wrappers.gmk
>> + src/solaris/classes/sun/awt/X11/generator/sizes.32
>> + src/solaris/classes/sun/awt/X11/generator/sizes.64
>> - src/solaris/classes/sun/awt/X11/generator/sizes.64-solaris-i386
>>
>>
>> 2012/11/26 David Holmes<david.holmes at oracle.com>:
>>> This changeset
>>>
>>> changeset:   6067:dcee387cde81
>>> user:        ohrstrom
>>> date:        Mon Oct 29 13:41:38 2012 -0700
>>> summary:     8001891: build-infra: Adding X_CFLAGS and X_LIBS to 
>>> lwawt and
>>> sizer compilation
>>>
>>> diff -r 5b29d6157504 -r dcee387cde81 makefiles/GensrcX11Wrappers.gmk
>>> --- a/makefiles/GensrcX11Wrappers.gmk
>>> +++ b/makefiles/GensrcX11Wrappers.gmk
>>> @@ -64,6 +64,8 @@
>>>          $(MKDIR) -p $(@D)
>>>          $(RM) $@ $@.tmp
>>>          (cd $(@D)&&  $(BUILD_CC) -m$* -o $@.tmp $<  \
>>> +              $(X_CFLAGS) \
>>> +              $(X_LIBS) \
>>>                 -I$(JDK_OUTPUTDIR)/include \
>>>                 -I$(JDK_TOPDIR)/src/share/javavm/export \
>>>
>>> -I$(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS_API_DIR)/javavm/export \
>>>
>>> breaks cross-compilation as the values in X_CFLAGS and X_LIBS are 
>>> those of
>>> the cross-compiler, not the build machine compiler that will create the
>>> sizers executable.
>>>
>>> Not sure why sizers needs the above even when not cross-compiling - 
>>> it is a
>>> very basic program that just needs access to the right header files. 
>>> Does it
>>> need special compiler flags or lib options ??
>>>
>>> I've filed https://jbs.oracle.com/bugs/browse/JDK-8003958 to track 
>>> this as
>>> it has already 'escaped'. I'll have to pull it out of the profiles 
>>> forest
>>> for now.
>>>
>>> Thanks,
>>> David
>>> -----
>>>


From oehrstroem at gmail.com  Mon Nov 26 05:51:46 2012
From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=)
Date: Mon, 26 Nov 2012 14:51:46 +0100
Subject: sizer compilation has been broken for cross-compiles
In-Reply-To: <50B36614.2050604@oracle.com>
References: <50B2CA11.2090301@oracle.com>
	<CALZT+jCR-ir71XSCe6CZRBK9D5_Ep=e5bPeXh+XUeLcwCUNjaA@mail.gmail.com>
	<50B36614.2050604@oracle.com>
Message-ID: <CALZT+jConGewiqXZ1ehntDAB-BTvdBCxUKZBjPp1xSMtqrCzmw@mail.gmail.com>

2012/11/26 David Holmes <david.holmes at oracle.com>:
> If we can do this for cross-compiling why do we ever need to generate these files?

If you read the makefile, you will see that it always uses the
committed sources. The generation
of the offset file is a verification step, run on platforms where it
is possible, the generated
offset file is not used per se.

> make the previous change? It still seems to me that things were working fine
> before that.

Obviously, there was a problem, that triggered the changed. In this case
it was because of the latest MacOSX update that moved all the X11 libraries,
so that you had to explicitly supply the path to them........

//Fredrik


From oehrstroem at gmail.com  Mon Nov 26 05:54:28 2012
From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=)
Date: Mon, 26 Nov 2012 14:54:28 +0100
Subject: sizer compilation has been broken for cross-compiles
In-Reply-To: <50B36CC1.6090204@oracle.com>
References: <50B2CA11.2090301@oracle.com>
	<CALZT+jCR-ir71XSCe6CZRBK9D5_Ep=e5bPeXh+XUeLcwCUNjaA@mail.gmail.com>
	<50B36614.2050604@oracle.com> <50B36CC1.6090204@oracle.com>
Message-ID: <CALZT+jCvUpMgr80K83J-+TuYPTSsvmzP3gZp-xK_srtp1Sb1Ow@mail.gmail.com>

2012/11/26 Erik Joelsson <erik.joelsson at oracle.com>:
> The third option would be to not generate them in the build at all, but to
> use the pre generated data.

This is exactly what happens in this patch.

Feel free to remove the verification, that is run when possible, but I
would advise against it.
In particular since, someone might want to change the generation in
the future, it does not
hurt to have a well exercised recipe in the makefile, for how to do
the generation.

//Fredrik


From kelly.ohair at oracle.com  Mon Nov 26 07:52:08 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Mon, 26 Nov 2012 07:52:08 -0800
Subject: Review Request: 8003960: build-infra: Jarsigner launcher has
	wrong classname
In-Reply-To: <50B32C77.5050402@oracle.com>
References: <50B1222C.80700@oracle.com> <50B32C77.5050402@oracle.com>
Message-ID: <28CF95FF-BF25-4E73-B0BF-85405FCDEC23@oracle.com>

Looks fine.

-kto

On Nov 26, 2012, at 12:46 AM, Erik Joelsson wrote:

> Fix for the issue reported below:
> 
> http://cr.openjdk.java.net/~erikj/8003960/webrev.jdk.01/ <http://cr.openjdk.java.net/%7Eerikj/8003960/webrev.jdk.01/>
> 
> /Erik
> 
> On 2012-11-24 20:38, Alan Bateman wrote:
>> 
>> In CompileLauncher.gmk then jarsigner is created to launch sun.security.tools.jarSigner.Main but there's a typo (should be "jarsigner", all lowercase). I ran into this because all tests that use jarsigner are failing with the new build.
>> 
>> -Alan



From kelly.ohair at oracle.com  Mon Nov 26 08:22:23 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Mon, 26 Nov 2012 08:22:23 -0800
Subject: Implicit assumptions in Images.gmk: find errors
In-Reply-To: <50B3276D.8070902@oracle.com>
References: <50AEC118.9090405@oracle.com> <50AF31CE.2090203@oracle.com>
	<DB47D41A-2488-4701-AE92-AC5262F52BA3@oracle.com>
	<50B3276D.8070902@oracle.com>
Message-ID: <E10F62C4-E1BC-43AE-9756-CAA07EB634F8@oracle.com>

The issue I have with the demos, and samples too, is that they should be something a customer could use with
the delivered jdk image, so building it from a jdk image matches what a customer might see.
In addition, the demos and samples are being pulled out of the default jdk image and being delivered in
separate bundles, distancing them from the jdk image creation even more.

So I'm fine with the way it is now, but keep in mind that the demos are being more and more isolated
as we move forward. My tendency is to try and keep them separate, more like a required test case for the
builds, and a separate deliverable. But for now, we can stick with the status quo.

I've done quite a bit of work on the demos in the past, and they are, quite frankly, a huge pain in regards to being
inconsistent and varied in build procedures. The native code ones are particularly difficult, and I wrote many of them. :^(
They can become a huge time sink. :^(  But their value cannot be denied.

-kto

On Nov 26, 2012, at 12:25 AM, Erik Joelsson wrote:

> The demos are built using the bootstrap javac, running on the boot jdk and linked against the newly built classes. The next step would be executing on the newly built jdk, but I don't think we need to go that far. The end result is logically the same (as in the same compiler is used and the same classes are linked against) and I would rather avoid the complications for cross compilation.
> 
> /Erik
> 
> On 2012-11-25 19:05, Kelly O'Hair wrote:
>> That sounds right.
>> 
>> The demos really need to be built from the built jdk image.
>> So in my opinion, the demos should follow the jdk image creation.
>> 
>> I think in the old build it was a bit mixed up as to when the demos were built.
>> 
>> -kto
>> 
>> On Nov 23, 2012, at 12:20 AM, Erik Joelsson wrote:
>> 
>>> We could condition these finds on the existence of these directories. I think that would be the cleanest implementation as it would logically act the same as now, just with less noise and execs.
>>> 
>>> /Erik
>>> 
>>> On 2012-11-23 01:19, David Holmes wrote:
>>>> Some of the constructs in Images.gmk implicitly assume that you are always building a JDK image and a JRE image. Ie.:
>>>> 
>>>> JDK_DEMO_TARGETS := $(patsubst $(JDK_OUTPUTDIR)/demo/%,$(JDK_IMAGE_DIR)/demo/%,\
>>>>                        $(shell $(FIND) $(JDK_OUTPUTDIR)/demo ! \( -name "_the*" -o -name "javac_state" \) ))
>>>> 
>>>> and:
>>>> 
>>>> # /sample dir
>>>> $(foreach f,$(shell $(FIND) $(JDK_OUTPUTDIR)/sample -type f),\
>>>>    $(eval $(call AddFileToCopy,$(JDK_OUTPUTDIR),$(JDK_IMAGE_DIR),$f,JDK_SAMPLE_TARGETS)))
>>>> 
>>>> 
>>>> will both attempt to issue "find" in a directory that may not exist (jdk/demo and jdk/sample respectively) if you are not building a jdk image.
>>>> 
>>>> Fortunately (or perhaps erroneously?) these find failures do not cause make to fail, they just generate noisy output (which of course is how I noticed it).
>>>> 
>>>> Not sure what the solution is or if it is just something we have to live with. There is an awful lot of setup needed to build images, but some of it is dependent on what image has been requested.
>>>> 
>>>> Cheers,
>>>> David



From philip.race at oracle.com  Mon Nov 26 16:30:30 2012
From: philip.race at oracle.com (Phil Race)
Date: Mon, 26 Nov 2012 16:30:30 -0800
Subject: build problem
In-Reply-To: <50AD4C55.6060407@oracle.com>
References: <50A6C8EA.8080209@oracle.com>	<B37AB3C0-0233-487A-89C5-C7466DEEE87D@oracle.com>	<50A6CC14.30008@oracle.com>	<50AA158B.3080208@oracle.com>	<50AA61AF.3050800@oracle.com>	<50AA6242.3070908@oracle.com>	<50AA6354.6040801@oracle.com>
	<50AC934B.5090702@oracle.com>	<50AD41D7.3050508@oracle.com>
	<50AD4C55.6060407@oracle.com>
Message-ID: <50B409A6.4030900@oracle.com>

I re-ran with that flag and it succeeded this time.
I suppose some timing kind of issue, perhaps the
kind that goes away when you try to debug it :-;

-phil.


On 11/21/2012 1:49 PM, Tim Bell wrote:
> On 11/21/12 13:04, Phil Race wrote:
>> sh-4.1$ make NEWBUILD=true BUILD_DEPLOY=false BUILD_INSTALL=false 
> [... snip!...]
>> make[3]: *** 
>> [/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release/jdk/impsrc/_the.LANGTOOLS.src.imported] 
>> Error 126
>
> You are using Windows 7, right?
>
> Searching for 'Error 126' or 'anyone able to build on Win 7' uncovered 
> some email threads on mail.openjdk.java.net, but clear answer that I 
> could find.
>
>> make[3]: *** Waiting for unfinished jobs....
>> make[3]: Leaving directory `/cygdrive/c/jdks/2d/jdk/makefiles'
>> make[2]: *** [import-only] Error 2
>> make[2]: Leaving directory `/cygdrive/c/jdks/2d/jdk/makefiles'
>> make[1]: *** [jdk-only] Error 2
>> make[1]: Leaving directory 
>> `/cygdrive/c/jdks/2d/build/windows-x86_64-normal-server-release'
>> make: *** [all] Error 2
>
>
> Please add 'LOG=debug' to your make command, rerun, and send a pointer 
> to that output (or include the tail end of the output with plenty of 
> context...).
>
> Thanks-
>
> Tim
>
>



From david.holmes at oracle.com  Mon Nov 26 19:27:47 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 27 Nov 2012 13:27:47 +1000
Subject: sizer compilation has been broken for cross-compiles
In-Reply-To: <CALZT+jConGewiqXZ1ehntDAB-BTvdBCxUKZBjPp1xSMtqrCzmw@mail.gmail.com>
References: <50B2CA11.2090301@oracle.com>
	<CALZT+jCR-ir71XSCe6CZRBK9D5_Ep=e5bPeXh+XUeLcwCUNjaA@mail.gmail.com>
	<50B36614.2050604@oracle.com>
	<CALZT+jConGewiqXZ1ehntDAB-BTvdBCxUKZBjPp1xSMtqrCzmw@mail.gmail.com>
Message-ID: <50B43333.6090205@oracle.com>

On 26/11/2012 11:51 PM, Fredrik ?hrstr?m wrote:
> 2012/11/26 David Holmes<david.holmes at oracle.com>:
>> If we can do this for cross-compiling why do we ever need to generate these files?
>
> If you read the makefile, you will see that it always uses the
> committed sources. The generation
> of the offset file is a verification step, run on platforms where it
> is possible, the generated offset file is not used per se.

Okay - I hadn't gleaned that from my quick scan of the change - sorry.

This needs to be blessed by the AWT folk of course, but it seems to me 
that if these values can change then it is not likely to be based on CPU 
architecture, so common/shared values should work. Otherwise this would 
all have to be based on something OS/runtime specific, in which case 
there would be no guarantee of a match between the end system and the 
build machine anyway.

Erik: just a follow up on one of your comments, the 32-bit/64-bit aspect 
of this was being handled by having the build host compiler do an 
appropriate build. At least that was how it worked in the old build and 
I'm pretty sure we made it do that in the new build too at some stage.

>> make the previous change? It still seems to me that things were working fine
>> before that.
>
> Obviously, there was a problem, that triggered the changed. In this case
> it was because of the latest MacOSX update that moved all the X11 libraries,
> so that you had to explicitly supply the path to them........

OSX continually causes problems. We must be assuming paths without 
realizing it if we keep needing to special case the OSX forms. :(

Thanks,
David


> //Fredrik


From erik.joelsson at oracle.com  Tue Nov 27 06:52:33 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 27 Nov 2012 14:52:33 +0000
Subject: hg: build-infra/jdk8: 8004045: build-infra: Error 12 from zip when
	updating src.zip
Message-ID: <20121127145233.DCB0A47B44@hg.openjdk.java.net>

Changeset: 15ebad04c421
Author:    erikj
Date:      2012-11-27 15:52 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/15ebad04c421

8004045: build-infra: Error 12 from zip when updating src.zip

! common/makefiles/JavaCompilation.gmk



From jonathan.gibbons at oracle.com  Tue Nov 27 07:46:51 2012
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 27 Nov 2012 07:46:51 -0800
Subject: Langtools resources
Message-ID: <50B4E06B.1030207@oracle.com>

Build-infra folk,

We have recently added a new file to javadoc, but the new file is 
"ignored" in builds with the new makefiles, resulting in a broken javadoc.

We will need to add .js to the following list.

langtools/makefiles/BuildLangtools.gmk: RESOURCE_SUFFIXES:=.gif .xml 
.css javax.tools.JavaCompilerTool

We'd like to make the change and push it up through TL, with your 
approval.  Will that be OK?  If so, I'll create and post a webrev.

-- Jon


From erik.joelsson at oracle.com  Tue Nov 27 08:14:02 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 27 Nov 2012 17:14:02 +0100
Subject: Langtools resources
In-Reply-To: <50B4E06B.1030207@oracle.com>
References: <50B4E06B.1030207@oracle.com>
Message-ID: <50B4E6CA.3020808@oracle.com>

This change has been noticed and .js is being added with the javadocs patch:

8003844: build-infra: docs target isn't working properly

In that patch I'm also moving the definition of that variable (since 
it's needed for bootstrap javadoc generation too). This means that if 
you add .js it will cause a merge conflict for the integrator. I don't 
know if this is ok or not.

/Erik

On 2012-11-27 16:46, Jonathan Gibbons wrote:
> Build-infra folk,
>
> We have recently added a new file to javadoc, but the new file is 
> "ignored" in builds with the new makefiles, resulting in a broken 
> javadoc.
>
> We will need to add .js to the following list.
>
> langtools/makefiles/BuildLangtools.gmk: RESOURCE_SUFFIXES:=.gif .xml 
> .css javax.tools.JavaCompilerTool
>
> We'd like to make the change and push it up through TL, with your 
> approval.  Will that be OK?  If so, I'll create and post a webrev.
>
> -- Jon


From jonathan.gibbons at oracle.com  Tue Nov 27 08:25:03 2012
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 27 Nov 2012 08:25:03 -0800
Subject: Langtools resources
In-Reply-To: <50B4E6CA.3020808@oracle.com>
References: <50B4E06B.1030207@oracle.com> <50B4E6CA.3020808@oracle.com>
Message-ID: <50B4E95F.1050906@oracle.com>

Erik,

How soon will your change arrive in TL and/or JDK 8?  Right now, until 
we have the fix, javadoc is broken.

-- Jon

On 11/27/2012 08:14 AM, Erik Joelsson wrote:
> This change has been noticed and .js is being added with the javadocs 
> patch:
>
> 8003844: build-infra: docs target isn't working properly
>
> In that patch I'm also moving the definition of that variable (since 
> it's needed for bootstrap javadoc generation too). This means that if 
> you add .js it will cause a merge conflict for the integrator. I don't 
> know if this is ok or not.
>
> /Erik
>
> On 2012-11-27 16:46, Jonathan Gibbons wrote:
>> Build-infra folk,
>>
>> We have recently added a new file to javadoc, but the new file is 
>> "ignored" in builds with the new makefiles, resulting in a broken 
>> javadoc.
>>
>> We will need to add .js to the following list.
>>
>> langtools/makefiles/BuildLangtools.gmk: RESOURCE_SUFFIXES:=.gif .xml 
>> .css javax.tools.JavaCompilerTool
>>
>> We'd like to make the change and push it up through TL, with your 
>> approval.  Will that be OK?  If so, I'll create and post a webrev.
>>
>> -- Jon



From erik.joelsson at oracle.com  Tue Nov 27 08:38:37 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 27 Nov 2012 17:38:37 +0100
Subject: Langtools resources
In-Reply-To: <50B4E95F.1050906@oracle.com>
References: <50B4E06B.1030207@oracle.com> <50B4E6CA.3020808@oracle.com>
	<50B4E95F.1050906@oracle.com>
Message-ID: <50B4EC8D.5050903@oracle.com>

It's being reviewed now. My plan was to wait for my committer status in 
jdk8 to go through (which happens in a couple of hours) and start 
pushing these changes to jdk8/build tomorrow, in time for the merge with 
jdk8/jdk8. This might fail for a number of reasons though so if it's 
urgent, Tim could probably push that particular change today already to 
be sure it makes it.

I could also hold out on that particular change until your change gets 
into jdk8/build. How long would that take, give that build is integrated 
on Wednesdays?

/Erik

On 2012-11-27 17:25, Jonathan Gibbons wrote:
> Erik,
>
> How soon will your change arrive in TL and/or JDK 8?  Right now, until 
> we have the fix, javadoc is broken.
>
> -- Jon
>
> On 11/27/2012 08:14 AM, Erik Joelsson wrote:
>> This change has been noticed and .js is being added with the javadocs 
>> patch:
>>
>> 8003844: build-infra: docs target isn't working properly
>>
>> In that patch I'm also moving the definition of that variable (since 
>> it's needed for bootstrap javadoc generation too). This means that if 
>> you add .js it will cause a merge conflict for the integrator. I 
>> don't know if this is ok or not.
>>
>> /Erik
>>
>> On 2012-11-27 16:46, Jonathan Gibbons wrote:
>>> Build-infra folk,
>>>
>>> We have recently added a new file to javadoc, but the new file is 
>>> "ignored" in builds with the new makefiles, resulting in a broken 
>>> javadoc.
>>>
>>> We will need to add .js to the following list.
>>>
>>> langtools/makefiles/BuildLangtools.gmk: RESOURCE_SUFFIXES:=.gif .xml 
>>> .css javax.tools.JavaCompilerTool
>>>
>>> We'd like to make the change and push it up through TL, with your 
>>> approval.  Will that be OK?  If so, I'll create and post a webrev.
>>>
>>> -- Jon
>


From jonathan.gibbons at oracle.com  Tue Nov 27 08:52:02 2012
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 27 Nov 2012 08:52:02 -0800
Subject: Langtools resources
In-Reply-To: <50B4EC8D.5050903@oracle.com>
References: <50B4E06B.1030207@oracle.com> <50B4E6CA.3020808@oracle.com>
	<50B4E95F.1050906@oracle.com> <50B4EC8D.5050903@oracle.com>
Message-ID: <50B4EFB2.7010505@oracle.com>

Sounds like you have it under control. You will probably get integrated 
to the master before TL.

-- Jon

On 11/27/2012 08:38 AM, Erik Joelsson wrote:
> It's being reviewed now. My plan was to wait for my committer status 
> in jdk8 to go through (which happens in a couple of hours) and start 
> pushing these changes to jdk8/build tomorrow, in time for the merge 
> with jdk8/jdk8. This might fail for a number of reasons though so if 
> it's urgent, Tim could probably push that particular change today 
> already to be sure it makes it.
>
> I could also hold out on that particular change until your change gets 
> into jdk8/build. How long would that take, give that build is 
> integrated on Wednesdays?
>
> /Erik
>
> On 2012-11-27 17:25, Jonathan Gibbons wrote:
>> Erik,
>>
>> How soon will your change arrive in TL and/or JDK 8?  Right now, 
>> until we have the fix, javadoc is broken.
>>
>> -- Jon
>>
>> On 11/27/2012 08:14 AM, Erik Joelsson wrote:
>>> This change has been noticed and .js is being added with the 
>>> javadocs patch:
>>>
>>> 8003844: build-infra: docs target isn't working properly
>>>
>>> In that patch I'm also moving the definition of that variable (since 
>>> it's needed for bootstrap javadoc generation too). This means that 
>>> if you add .js it will cause a merge conflict for the integrator. I 
>>> don't know if this is ok or not.
>>>
>>> /Erik
>>>
>>> On 2012-11-27 16:46, Jonathan Gibbons wrote:
>>>> Build-infra folk,
>>>>
>>>> We have recently added a new file to javadoc, but the new file is 
>>>> "ignored" in builds with the new makefiles, resulting in a broken 
>>>> javadoc.
>>>>
>>>> We will need to add .js to the following list.
>>>>
>>>> langtools/makefiles/BuildLangtools.gmk: RESOURCE_SUFFIXES:=.gif 
>>>> .xml .css javax.tools.JavaCompilerTool
>>>>
>>>> We'd like to make the change and push it up through TL, with your 
>>>> approval.  Will that be OK?  If so, I'll create and post a webrev.
>>>>
>>>> -- Jon
>>



From oehrstroem at gmail.com  Wed Nov 28 00:22:10 2012
From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=)
Date: Wed, 28 Nov 2012 09:22:10 +0100
Subject: Review Request: 8003960: build-infra: Jarsigner launcher has
	wrong classname
In-Reply-To: <50B32C77.5050402@oracle.com>
References: <50B1222C.80700@oracle.com>
	<50B32C77.5050402@oracle.com>
Message-ID: <CALZT+jBfEWL42W2SPG-0zKCb5uM-O33A=3H6Ps97EX+QJ0D01A@mail.gmail.com>

Looks good!

2012/11/26 Erik Joelsson <erik.joelsson at oracle.com>:
> Fix for the issue reported below:
>
> http://cr.openjdk.java.net/~erikj/8003960/webrev.jdk.01/
> <http://cr.openjdk.java.net/%7Eerikj/8003960/webrev.jdk.01/>
>
> /Erik
>
> On 2012-11-24 20:38, Alan Bateman wrote:
>>
>>
>> In CompileLauncher.gmk then jarsigner is created to launch
>> sun.security.tools.jarSigner.Main but there's a typo (should be "jarsigner",
>> all lowercase). I ran into this because all tests that use jarsigner are
>> failing with the new build.
>>
>> -Alan


From magnus.ihse.bursie at oracle.com  Wed Nov 28 04:50:32 2012
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 28 Nov 2012 13:50:32 +0100
Subject: --debug-configure doesn't quite work
In-Reply-To: <50AF32AA.8030900@oracle.com>
References: <50AEFA3A.8060702@oracle.com> <50AEFFD2.5010902@oracle.com>
	<50AF32AA.8030900@oracle.com>
Message-ID: <B913A3A8-C10F-4DFB-ADC6-439E08580593@oracle.com>

This only happens if a debug log was created, but no spec.gmk. Presence of a spec.gmk will cause configure to continue, regardless of other files present. But if the first run if configure failed before a spec.gmk was generated, we might still end up with a few files like the debug log that we probably needs to keep track of. But that's not all files. 

/Magnus

23 nov 2012 kl. 09:24 skrev Erik Joelsson <erik.joelsson at oracle.com>:

> Ouch.. Having to manually keep track of every file configure might create in the current directory is annoying. You are most welcome to commit this fix to jdk8/build if you have time. Otherwise I will take care of it when given a chance.
> 
> /Erik
> 
> On 2012-11-23 05:47, David Holmes wrote:
>> Okay some weird happened with piping the output into tee. But I got past that and then hit this :)
>> 
>> ++ files_present='confdefs.h
>> config.log
>> debug-configure.log'
>> +++ /bin/echo 'confdefs.h
>> config.log
>> debug-configure.log'
>> +++ /bin/sed -e s/config.log//g -e s/confdefs.h//g -e 's/ //g'
>> +++ /usr/bin/tr -d '\n'
>> ++ filtered_files=debug-configure.log
>> ++ test xdebug-configure.log '!=' x
>> ++ printf '%s\n' 'configure:7991: Current directory is /java/embedded/users/dh198349/build-infra/builds/b00/se-linux
>> t-ea.'
>> ++ printf '%s\n' 'configure: Current directory is /java/embedded/users/dh198349/build-infra/builds/b00/se-linux.
>> '
>> configure: Current directory is /java/embedded/users/dh198349/build-infra/builds/b00/se-linux.
>> configure: Since this is not the source root, configure will output the configuration here
>> configure: (as opposed to creating a configuration in <src_root>/build/<conf-name>).
>> configure: However, this directory is not empty. This is not allowed, since it could
>> configure: seriously mess up just about everything.
>> configure: Try 'cd /java/embedded/users/dh198349/build-infra' and restart configure
>> configure: (or create a new empty directory and cd to it).
>> 
>> ----
>> 
>> Oops! The debug log causes configure to stop configuring. Simple patch below:
>> 
>> David
>> -----
>> 
>> 
>> diff -r 811b3b283175 common/autoconf/basics.m4
>> --- a/common/autoconf/basics.m4
>> +++ b/common/autoconf/basics.m4
>> @@ -385,7 +385,7 @@
>>       files_present=`$LS $OUTPUT_ROOT`
>>       # Configure has already touched config.log and confdefs.h in the current dir when this check
>>       # is performed.
>> -      filtered_files=`$ECHO "$files_present" | $SED -e 's/config.log//g' -e 's/confdefs.h//g' -e 's/ //g' \
>> +      filtered_files=`$ECHO "$files_present" | $SED -e 's/config.log//g' -e 's/confdefs.h//g' -e 's/debug-configure.log//g' -e 's/ //g' \
>>                                              | $TR -d '\n'`
>>       if test "x$filtered_files" != x; then
>>         AC_MSG_NOTICE([Current directory is $CURDIR.])
>> 
>> 
>> 
>> On 23/11/2012 2:23 PM, David Holmes wrote:
>>> I used --debug-configure to try and debug configure but the resulting
>>> debug log just stops abruptly:
>>> 
>>> ++ WC=/usr/bin/wc
>>> ++ test -n /usr/bin/wc
>>> ++ printf '%s\n' 'configure:5726: result: /usr/bin/wc'
>>> ++ printf '%s\n' /usr/bin/wc
>>> ++ test -n /usr/bin/wc
>>> ++ break
>>> ++ test x/usr/bin/wc = x
>>> ++ for ac_prog in which
>>> ++ set dummy which
>>> ++ ac_word=which
>>> ++ printf '%s\n' 'configure:5755: checking for which'
>>> ++ printf %s 'checking for which... '
>>> ++ false
>>> ++ case $WHICH in
>>> ++ as_save_IFS='
>>> '
>>> ++ IFS=
>>> 
>>> ???
>>> 
>>> David


From fredrik.ohrstrom at oracle.com  Thu Nov 29 05:01:46 2012
From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com)
Date: Thu, 29 Nov 2012 13:01:46 +0000
Subject: hg: build-infra/jdk8: 2 new changesets
Message-ID: <20121129130146.84D0847BC5@hg.openjdk.java.net>

Changeset: c0b87f591c5e
Author:    ohrstrom
Date:      2012-11-29 14:00 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/c0b87f591c5e

Make sure the new hgforest.sh works on Solaris.

! common/bin/hgforest.sh

Changeset: df576458b57d
Author:    ohrstrom
Date:      2012-11-29 14:01 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/df576458b57d

Switch to new hgforest.sh

! get_source.sh



From fredrik.ohrstrom at oracle.com  Thu Nov 29 05:49:07 2012
From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com)
Date: Thu, 29 Nov 2012 13:49:07 +0000
Subject: hg: build-infra/jdk8: Properly detect when python cannot be found
	from hg script.
Message-ID: <20121129134907.BA58E47BC6@hg.openjdk.java.net>

Changeset: fe40f0641f3c
Author:    ohrstrom
Date:      2012-11-29 14:48 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/fe40f0641f3c

Properly detect when python cannot be found from hg script.

! common/bin/hgforest.sh



From erik.joelsson at oracle.com  Thu Nov 29 06:17:12 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 29 Nov 2012 14:17:12 +0000
Subject: hg: build-infra/jdk8/jdk: 35 new changesets
Message-ID: <20121129142353.117CE47BC8@hg.openjdk.java.net>

Changeset: 44e845bb5f76
Author:    erikj
Date:      2012-11-28 09:47 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/44e845bb5f76

8003960: build-infra: Jarsigner launcher has wrong classname
Summary: Fixed package name in launcher
Reviewed-by: alanb, ohair, ohrstrom

! makefiles/CompileLaunchers.gmk

Changeset: ad5741112252
Author:    erikj
Date:      2012-11-28 13:20 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/ad5741112252

8001460: build-infra: Linker warnings on macosx
Summary: Remove creation of empty i386 section from fdlibm
Reviewed-by: ohair

! makefiles/CompileNativeLibraries.gmk

Changeset: 7ecc80d2ff2e
Author:    erikj
Date:      2012-11-28 13:29 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/7ecc80d2ff2e

8003477: build-infra: Remove explicit source file listings for libs when possible
Reviewed-by: ohair, ohrstrom

! makefiles/CompileNativeLibraries.gmk

Changeset: 51d2fd6d9850
Author:    erikj
Date:      2012-11-28 13:49 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/51d2fd6d9850

8003528: build-infra: Diffs in libjava and hotspot libs on solaris.
Summary: Reorder libraries on link command line to match old build.
Reviewed-by: ohair, ohrstrom

! makefiles/CompileNativeLibraries.gmk

Changeset: 54516ed0f99f
Author:    erikj
Date:      2012-11-28 14:10 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/54516ed0f99f

8003482: build-infra: Use correct manifest in security jars
Reviewed-by: ohair, ohrstrom

! makefiles/CreateJars.gmk

Changeset: c87df8b1f55e
Author:    katleman
Date:      2012-11-15 15:40 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/c87df8b1f55e

Added tag jdk8-b65 for changeset 130d3a54d28b

! .hgtags

Changeset: 03d22c98b30a
Author:    ceisserer
Date:      2012-11-13 16:12 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/03d22c98b30a

7105461: Large JTables are not rendered correctly with Xrender pipeline
Reviewed-by: flar, prr

! src/solaris/classes/sun/java2d/xr/XRRenderer.java
! src/solaris/classes/sun/java2d/xr/XRUtils.java

Changeset: ed977ca9a969
Author:    lana
Date:      2012-11-20 11:46 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/ed977ca9a969

Merge


Changeset: 11ba8795bbe9
Author:    kshefov
Date:      2012-11-14 11:37 +0000
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/11ba8795bbe9

7147408: [macosx] Add autodelay to fix a regression test
Reviewed-by: serb, alexsch

+ test/javax/swing/text/StyledEditorKit/4506788/bug4506788.html
+ test/javax/swing/text/StyledEditorKit/4506788/bug4506788.java

Changeset: f32a0aee7bb9
Author:    alitvinov
Date:      2012-11-14 18:40 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/f32a0aee7bb9

6789984: JPasswordField can not receive keyboard input
Reviewed-by: naoto, anthony

! src/share/classes/sun/awt/im/InputContext.java
! src/share/classes/sun/awt/im/InputMethodAdapter.java
! src/solaris/classes/sun/awt/X11InputMethod.java

Changeset: 0269459afe2a
Author:    malenkov
Date:      2012-11-20 18:56 +0400
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/0269459afe2a

8003333: Regression: java/beans/EventHandler/Test6277266.java fails with ACE
Reviewed-by: art

! test/java/beans/EventHandler/Test6277266.java

Changeset: ea368459cca5
Author:    lana
Date:      2012-11-20 11:47 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/ea368459cca5

Merge


Changeset: c3e7ceb22d37
Author:    alanb
Date:      2012-11-11 10:05 +0000
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/c3e7ceb22d37

8003253: TEST_BUG: java/nio/channels/AsynchronousChannelGroup/Unbounded.java hang intermittently [win]
Reviewed-by: chegar

! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java

Changeset: 5d3f8f9e6c58
Author:    okutsu
Date:      2012-11-12 11:12 +0900
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/5d3f8f9e6c58

8000986: Split java.util.spi.CalendarDataProvider into week parameters and field names portions
Reviewed-by: naoto

! make/java/java/FILES_java.gmk
! src/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java
! src/share/classes/java/util/Calendar.java
! src/share/classes/java/util/spi/CalendarDataProvider.java
+ src/share/classes/java/util/spi/CalendarNameProvider.java
! src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java
! src/share/classes/sun/util/locale/provider/CalendarDataUtility.java
+ src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java
! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java
! src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java
! test/java/util/PluggableLocale/CalendarDataProviderTest.java
! test/java/util/PluggableLocale/CalendarDataProviderTest.sh
+ test/java/util/PluggableLocale/CalendarNameProviderTest.java
+ test/java/util/PluggableLocale/CalendarNameProviderTest.sh
! test/java/util/PluggableLocale/GenericTest.java
! test/java/util/PluggableLocale/barprovider.jar
! test/java/util/PluggableLocale/fooprovider.jar
! test/java/util/PluggableLocale/providersrc/CalendarDataProviderImpl.java
+ test/java/util/PluggableLocale/providersrc/CalendarNameProviderImpl.java
! test/java/util/PluggableLocale/providersrc/Makefile
+ test/java/util/PluggableLocale/providersrc/java.util.spi.CalendarNameProvider

Changeset: be1fb42ef696
Author:    mduigou
Date:      2012-11-13 20:02 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/be1fb42ef696

7088913: Add compatible static hashCode(primitive) to primitive wrapper classes
Summary: Adds static utility methods to each primitive wrapper class to allow calculation of a hashCode value from an unboxed primitive.
Reviewed-by: darcy, smarks, dholmes

! src/share/classes/java/lang/Boolean.java
! src/share/classes/java/lang/Byte.java
! src/share/classes/java/lang/Character.java
! src/share/classes/java/lang/Double.java
! src/share/classes/java/lang/Float.java
! src/share/classes/java/lang/Integer.java
! src/share/classes/java/lang/Long.java
! src/share/classes/java/lang/Short.java
! test/java/lang/HashCode.java

Changeset: 83765e82cacb
Author:    zhouyx
Date:      2012-11-14 13:26 +0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/83765e82cacb

7201156: jar tool fails to convert file separation characters for list and extract
Reviewed-by: alanb, chegar, sherman

! src/share/classes/sun/tools/jar/Main.java
+ test/tools/jar/JarBackSlash.java

Changeset: 0f54a98f9bc9
Author:    alanb
Date:      2012-11-14 12:56 +0000
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/0f54a98f9bc9

8003285: TEST_BUG: java/nio/channels/AsynchronousChannelGroup/Unbounded.java fails again [macosx]
Reviewed-by: chegar

! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java

Changeset: 369709a13823
Author:    jjg
Date:      2012-11-14 07:08 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/369709a13823

8000404: rename javax.tools.GenerateNativeHeader to java.lang.annotation.Native
Reviewed-by: alanb

+ src/share/classes/java/lang/annotation/Native.java

Changeset: e24123de581c
Author:    mduigou
Date:      2012-11-13 20:02 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/e24123de581c

7088952: Add size in bytes constant "BYTES" to primitive type wrapper types
Summary: Adds a constant BYTES to each of the primitive wrapper classes (Byte, Character, Double, Float, Integer, Long, Short) with the calculation Primitive.SIZE / Byte.SIZE already made.
Reviewed-by: dholmes

! src/share/classes/java/lang/Byte.java
! src/share/classes/java/lang/Character.java
! src/share/classes/java/lang/Double.java
! src/share/classes/java/lang/Float.java
! src/share/classes/java/lang/Integer.java
! src/share/classes/java/lang/Long.java
! src/share/classes/java/lang/Short.java

Changeset: f4de6a38f794
Author:    lana
Date:      2012-11-14 16:41 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/f4de6a38f794

Merge


Changeset: ac22a52a732c
Author:    jgish
Date:      2012-11-15 13:46 +0000
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/ac22a52a732c

6244047: impossible to specify directories to logging FileHandler unless they exist
Reviewed-by: alanb

! src/share/classes/java/util/logging/FileHandler.java
+ test/java/util/logging/CheckLockLocationTest.java

Changeset: 51c695958712
Author:    weijun
Date:      2012-11-16 10:34 +0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/51c695958712

8003263: redundant cast build failure after 8003120
Reviewed-by: alanb

! src/share/classes/com/sun/naming/internal/ResourceManager.java

Changeset: 64a42798ea5e
Author:    naoto
Date:      2012-11-15 20:17 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/64a42798ea5e

7199750: Loading sequence of service provider is changed
Reviewed-by: okutsu

! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java
! test/java/util/PluggableLocale/CurrencyNameProviderTest.sh
! test/java/util/PluggableLocale/barprovider.jar
! test/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl2.java

Changeset: 0ee09f17361e
Author:    khazra
Date:      2012-11-16 12:28 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/0ee09f17361e

8003518: (prefs) Tests in jdk/test/java/util/prefs should not be run concurrently
Summary: Add java/util/prefs to exclusiveAccess.dirs in TEST.ROOT
Reviewed-by: alanb, mchung

! test/TEST.ROOT

Changeset: 6f20caa6e1e9
Author:    bchristi
Date:      2012-11-16 17:01 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/6f20caa6e1e9

7178922: (props) re-visit how os.name is determined on Mac
Reviewed-by: alanb, mchung, skovatch, serb

! src/solaris/native/java/lang/java_props_macosx.c

Changeset: 25e5df117021
Author:    xuelei
Date:      2012-11-18 01:31 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/25e5df117021

8003587: Warning cleanup in package javax.net.ssl
Summary: Removes unnecessary imports and adds missing Override annotations
Reviewed-by: xuelei
Contributed-by: Florian Weimer <fweimer at redhat.com>

! src/share/classes/javax/net/ssl/HandshakeCompletedEvent.java
! src/share/classes/javax/net/ssl/HostnameVerifier.java
! src/share/classes/javax/net/ssl/HttpsURLConnection.java
! src/share/classes/javax/net/ssl/KeyManagerFactory.java
! src/share/classes/javax/net/ssl/SSLContext.java
! src/share/classes/javax/net/ssl/SSLContextSpi.java
! src/share/classes/javax/net/ssl/SSLEngineResult.java
! src/share/classes/javax/net/ssl/SSLParameters.java
! src/share/classes/javax/net/ssl/SSLPermission.java
! src/share/classes/javax/net/ssl/SSLServerSocketFactory.java
! src/share/classes/javax/net/ssl/SSLSession.java
! src/share/classes/javax/net/ssl/SSLSocket.java
! src/share/classes/javax/net/ssl/SSLSocketFactory.java
! src/share/classes/javax/net/ssl/TrustManagerFactory.java
! src/share/classes/javax/net/ssl/X509KeyManager.java

Changeset: f740a9ac6eb6
Author:    weijun
Date:      2012-11-19 11:13 +0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/f740a9ac6eb6

8002344: Krb5LoginModule config class does not return proper KDC list from DNS
Reviewed-by: weijun
Contributed-by: Severin Gehwolf <sgehwolf at redhat.com>, Wang Weijun <weijun.wang at oracle.com>

! src/share/classes/sun/security/krb5/Config.java
+ test/sun/security/krb5/config/DNS.java
+ test/sun/security/krb5/config/NamingManager.java
+ test/sun/security/krb5/config/dns.sh

Changeset: 3877706701b1
Author:    alanb
Date:      2012-11-19 13:17 +0000
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/3877706701b1

8003607: More ProblemList.txt updates (11/2012)
Reviewed-by: lancea

! test/ProblemList.txt
! test/TEST.ROOT

Changeset: 2d08b404cd91
Author:    jzavgren
Date:      2012-11-20 09:26 +0000
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/2d08b404cd91

8000476: Memory Leaks and uninitialized memory access in PKCS11 and other native code
Reviewed-by: dsamersoff, valeriep, chegar

! src/share/bin/wildcard.c
! src/share/native/sun/security/jgss/wrapper/GSSLibStub.c
! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c
! src/solaris/bin/java_md_solinux.c

Changeset: 914cd9b482c8
Author:    ksrini
Date:      2012-11-19 19:49 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/914cd9b482c8

8001533: java launcher must launch javafx applications
Reviewed-by: ksrini, mchung, kcr, alanb
Contributed-by: david.dehaven at oracle.com

! src/share/bin/java.c
! src/share/classes/sun/launcher/LauncherHelper.java
! src/share/classes/sun/launcher/resources/launcher.properties
! test/tools/launcher/TestHelper.java

Changeset: b1c364c84d09
Author:    ksrini
Date:      2012-11-19 19:50 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/b1c364c84d09

8003660: (launcher) 8001533 regression tests
Reviewed-by: ksrini, mchung, kcr, ddehaven
Contributed-by: steve.sides at oracle.com

+ test/tools/launcher/FXLauncherTest.java

Changeset: 107a7a52a3c0
Author:    lana
Date:      2012-11-20 11:49 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/107a7a52a3c0

Merge


Changeset: 4d337fae2250
Author:    katleman
Date:      2012-11-28 14:06 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/4d337fae2250

Merge


Changeset: 0bc3ba1e6db3
Author:    erikj
Date:      2012-11-29 10:41 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/0bc3ba1e6db3

Merge

! makefiles/CompileLaunchers.gmk
! makefiles/CompileNativeLibraries.gmk
! makefiles/CreateJars.gmk
! src/share/classes/java/lang/Integer.java
! src/share/classes/java/lang/Long.java
! src/share/classes/java/lang/annotation/Native.java

Changeset: d3b0ef851a59
Author:    erikj
Date:      2012-11-29 15:16 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/d3b0ef851a59

Restored build equality on linux x86_64.

! makefiles/CompileJavaClasses.gmk
! makefiles/GensrcX11Wrappers.gmk



From erik.joelsson at oracle.com  Thu Nov 29 06:26:38 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 29 Nov 2012 14:26:38 +0000
Subject: hg: build-infra/jdk8/corba: 2 new changesets
Message-ID: <20121129142642.9D08547BC9@hg.openjdk.java.net>

Changeset: 65771ad1ca55
Author:    katleman
Date:      2012-11-15 15:38 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/corba/rev/65771ad1ca55

Added tag jdk8-b65 for changeset 5132f7900a8f

! .hgtags

Changeset: 6beb7ec4ba0a
Author:    erikj
Date:      2012-11-29 10:41 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/corba/rev/6beb7ec4ba0a

Merge




From erik.joelsson at oracle.com  Thu Nov 29 06:26:42 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 29 Nov 2012 14:26:42 +0000
Subject: hg: build-infra/jdk8/jaxws: 2 new changesets
Message-ID: <20121129142648.4075A47BCA@hg.openjdk.java.net>

Changeset: 3eb7f11cb4e0
Author:    katleman
Date:      2012-11-15 15:39 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jaxws/rev/3eb7f11cb4e0

Added tag jdk8-b65 for changeset fbe54291c9d3

! .hgtags

Changeset: 5e16e4a52f52
Author:    erikj
Date:      2012-11-29 10:41 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jaxws/rev/5e16e4a52f52

Merge




From erik.joelsson at oracle.com  Thu Nov 29 06:26:42 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 29 Nov 2012 14:26:42 +0000
Subject: hg: build-infra/jdk8/jaxp: 2 new changesets
Message-ID: <20121129142652.8C54647BCB@hg.openjdk.java.net>

Changeset: e6af1ad464e3
Author:    katleman
Date:      2012-11-15 15:39 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jaxp/rev/e6af1ad464e3

Added tag jdk8-b65 for changeset 5cf3c69a93d6

! .hgtags

Changeset: 0e796579fde7
Author:    erikj
Date:      2012-11-29 10:41 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jaxp/rev/0e796579fde7

Merge




From erik.joelsson at oracle.com  Thu Nov 29 06:26:42 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 29 Nov 2012 14:26:42 +0000
Subject: hg: build-infra/jdk8/hotspot: 25 new changesets
Message-ID: <20121129142733.9654847BCC@hg.openjdk.java.net>

Changeset: 4e3e685dbc9d
Author:    katleman
Date:      2012-11-15 15:39 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/4e3e685dbc9d

Added tag jdk8-b65 for changeset 0f7290a03b24

! .hgtags

Changeset: 3be318ecfae5
Author:    amurillo
Date:      2012-11-09 08:36 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/3be318ecfae5

8003231: new hotspot build - hs25-b10
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 6cb0d32b828b
Author:    bpittore
Date:      2012-11-07 17:53 -0500
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/6cb0d32b828b

8001185: parsing of sun.boot.library.path in os::dll_build_name somewhat broken
Summary: dll_dir can contain multiple paths, need to parse them correctly when loading agents
Reviewed-by: dholmes, dlong
Contributed-by: bill.pittore at oracle.com

! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/classfile/classLoader.cpp
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/thread.cpp

Changeset: d9a84e246cce
Author:    cjplummer
Date:      2012-11-09 09:45 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/d9a84e246cce

Merge

! src/share/vm/runtime/thread.cpp

Changeset: 429994fc0754
Author:    cjplummer
Date:      2012-11-14 10:13 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/429994fc0754

Merge


Changeset: 6bc207d87e5d
Author:    mgerdin
Date:      2012-11-09 00:38 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/6bc207d87e5d

7200229: NPG: possible performance issue exposed by closed/runtime/6559877/Test6559877.java
Summary: Reduce the amount of calls to ChunkManager verification code
Reviewed-by: jmasa, coleenp

! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/universe.cpp

Changeset: 0400886d2613
Author:    coleenp
Date:      2012-11-14 22:37 -0500
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/0400886d2613

8003259: NPG: Build with gcc 4.7.2 broken by 7045397
Summary: Qualify calls with this pointers to make gcc accept this code.
Reviewed-by: coleenp, andrew
Contributed-by: peter.levart at gmail.com

! src/share/vm/memory/binaryTreeDictionary.cpp

Changeset: c5d4acbb943d
Author:    johnc
Date:      2012-11-15 14:29 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/c5d4acbb943d

Merge


Changeset: bd7a7ce2e264
Author:    minqi
Date:      2012-11-12 14:03 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/bd7a7ce2e264

6830717: replay of compilations would help with debugging
Summary: When java process crashed in compiler thread, repeat the compilation process will help finding root cause. This is done with using SA dump application class data and replay data from core dump, then use debug version of jvm to recompile the problematic java method.
Reviewed-by: kvn, twisti, sspitsyn
Contributed-by: yumin.qi at oracle.com

+ agent/doc/c2replay.html
! agent/doc/clhsdb.html
! agent/doc/index.html
! agent/make/Makefile
! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java
! agent/src/share/classes/sun/jvm/hotspot/ci/ciBaseObject.java
! agent/src/share/classes/sun/jvm/hotspot/ci/ciConstant.java
! agent/src/share/classes/sun/jvm/hotspot/ci/ciEnv.java
! agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlass.java
! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethod.java
! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodData.java
! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java
! agent/src/share/classes/sun/jvm/hotspot/compiler/CompileTask.java
! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCache.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Field.java
! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Metadata.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java
! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java
! src/share/vm/ci/ciClassList.hpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciEnv.hpp
! src/share/vm/ci/ciInstanceKlass.cpp
! src/share/vm/ci/ciInstanceKlass.hpp
! src/share/vm/ci/ciMetadata.hpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/ci/ciMethodData.cpp
! src/share/vm/ci/ciMethodData.hpp
! src/share/vm/ci/ciObject.hpp
! src/share/vm/ci/ciObjectFactory.hpp
+ src/share/vm/ci/ciReplay.cpp
+ src/share/vm/ci/ciReplay.hpp
! src/share/vm/ci/ciSymbol.cpp
! src/share/vm/ci/ciSymbol.hpp
! src/share/vm/ci/ciUtilities.hpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/code/dependencies.cpp
! src/share/vm/interpreter/invocationCounter.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/symbol.cpp
! src/share/vm/oops/symbol.hpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jvmtiExport.hpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/utilities/array.hpp
! src/share/vm/utilities/utf8.cpp
! src/share/vm/utilities/utf8.hpp
! src/share/vm/utilities/vmError.cpp

Changeset: bb33c6fdcf0d
Author:    bharadwaj
Date:      2012-11-15 10:42 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/bb33c6fdcf0d

8001077: remove ciMethod::will_link
Summary: Removed will_link and changed all calls to is_loaded().
Reviewed-by: kvn

! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/ci/bcEscapeAnalyzer.cpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/opto/doCall.cpp

Changeset: 6b6ddf8c4329
Author:    neliasso
Date:      2012-11-16 09:59 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/6b6ddf8c4329

Merge


Changeset: 64812523d72e
Author:    sspitsyn
Date:      2012-10-31 16:20 -0700
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/64812523d72e

7194607: VerifyLocalVariableTableOnRetransformTest.sh fails after JSR-292 merge
Summary: Use verifier_max_size instead of max_size to get code attribute max stack size.
Reviewed-by: dcubed, minqi
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/prims/jvmtiClassFileReconstituter.cpp

Changeset: 8aaef2cee3b2
Author:    minqi
Date:      2012-11-08 16:48 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/8aaef2cee3b2

Merge

! src/share/vm/prims/jvmtiClassFileReconstituter.cpp
- test/runtime/7158800/BadUtf8.java
- test/runtime/7158800/InternTest.java
- test/runtime/7158800/Test7158800.sh
- test/runtime/7158800/badstrings.txt

Changeset: ed8b1e39ff4f
Author:    zgu
Date:      2012-11-09 11:04 -0500
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/ed8b1e39ff4f

8002273: NMT to report JNI memory leaks when -Xcheck:jni is on
Summary: Allows NMT to report that JNI thread failed to detach from JVM before exiting, which leaks the JavaThread object when check:jni option is on.
Reviewed-by: acorn, dholmes, coleenp, ctornqvi

! src/share/vm/services/memSnapshot.cpp

Changeset: 4efcd79826f2
Author:    zgu
Date:      2012-11-09 11:47 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/4efcd79826f2

Merge


Changeset: fb3190e77d3c
Author:    zgu
Date:      2012-11-09 19:24 -0500
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/fb3190e77d3c

8001592: NMT: assertion failed: assert(_amount >= amt) failed: Just check: memBaseline.hpp:180
Summary: Fixed NMT that miscounted arena memory when it is used as value or stack object.
Reviewed-by: acorn, coleenp

! src/share/vm/services/memBaseline.cpp
! src/share/vm/services/memPtr.hpp
! src/share/vm/services/memSnapshot.cpp
! src/share/vm/services/memSnapshot.hpp
! src/share/vm/services/memTracker.hpp

Changeset: e26ce0e8b666
Author:    zgu
Date:      2012-11-09 16:45 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/e26ce0e8b666

Merge


Changeset: 8c413497f434
Author:    zgu
Date:      2012-11-09 22:22 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/8c413497f434

Merge

! src/share/vm/services/memSnapshot.cpp

Changeset: e4f764ddb06a
Author:    hseigel
Date:      2012-11-12 15:58 -0500
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/e4f764ddb06a

7122219: Passed StringTableSize value not verified
Summary: Check that the values specified for -XX:StringTableSize are within a certain range.
Reviewed-by: dholmes, coleenp

! src/share/vm/classfile/symbolTable.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: 070d523b96a7
Author:    hseigel
Date:      2012-11-12 16:15 -0500
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/070d523b96a7

8001471: Klass::cast() does nothing
Summary: Remove function Klass::cast() and calls to it.
Reviewed-by: dholmes, coleenp

! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciType.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/dictionary.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/loaderConstraints.cpp
! src/share/vm/classfile/placeholders.cpp
! src/share/vm/classfile/placeholders.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/code/dependencies.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/interpreter/bytecodeInterpreter.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/memory/metaspaceShared.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/arrayKlass.cpp
! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/klassVtable.cpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/objArrayKlass.cpp
! src/share/vm/oops/objArrayKlass.hpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jniCheck.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvmtiEnv.cpp
! src/share/vm/prims/jvmtiEnvBase.cpp
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/prims/jvmtiGetLoadedClasses.cpp
! src/share/vm/prims/jvmtiImpl.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/jvmtiTagMap.cpp
! src/share/vm/prims/jvmtiTrace.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/nativeLookup.cpp
! src/share/vm/prims/unsafe.cpp
! src/share/vm/runtime/biasedLocking.cpp
! src/share/vm/runtime/reflection.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/signature.cpp
! src/share/vm/runtime/synchronizer.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vframe.cpp
! src/share/vm/services/classLoadingService.hpp
! src/share/vm/services/heapDumper.cpp
! src/share/vm/services/management.cpp
! src/share/vm/services/serviceUtil.hpp

Changeset: 24e193d2a007
Author:    coleenp
Date:      2012-11-13 15:14 -0500
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/24e193d2a007

Merge


Changeset: 80e866b1d053
Author:    coleenp
Date:      2012-11-16 09:19 -0500
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/80e866b1d053

Merge

! src/share/vm/ci/ciEnv.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/code/dependencies.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/thread.cpp

Changeset: cfc5309f03b7
Author:    amurillo
Date:      2012-11-16 09:36 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/cfc5309f03b7

Merge


Changeset: 01684f7fee1b
Author:    amurillo
Date:      2012-11-16 09:36 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/01684f7fee1b

Added tag hs25-b10 for changeset cfc5309f03b7

! .hgtags

Changeset: 244cf8446387
Author:    erikj
Date:      2012-11-29 10:41 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/244cf8446387

Merge




From erik.joelsson at oracle.com  Thu Nov 29 06:27:44 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 29 Nov 2012 14:27:44 +0000
Subject: hg: build-infra/jdk8: 8 new changesets
Message-ID: <20121129142744.9ED7247BCD@hg.openjdk.java.net>

Changeset: ecf751a69f6a
Author:    tbell
Date:      2012-11-19 14:06 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/ecf751a69f6a

8003300: build-infra: fails on solaris when objcopy is not found
Summary: Only call BASIC_FIXUP_EXECUTABLE() if objcopy was found.
Reviewed-by: tbell
Contributed-by: erik.joelsson at oracle.com

! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4

Changeset: f8b0bacd4de5
Author:    erikj
Date:      2012-11-28 13:15 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/f8b0bacd4de5

8001460: build-infra: Linker warnings on macosx
Summary: Only linking against jvm variant specific dirs if they are expected to exist.
Reviewed-by: ohair

! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4

Changeset: 6ff2e1280dc3
Author:    erikj
Date:      2012-11-28 13:40 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/6ff2e1280dc3

8003844: build-infra: docs target isn't working properly
Summary: Fixed docs and docs-clean target. Added compare support for docs.
Reviewed-by: ohair, jjg, ohrstrom

! common/bin/compare.sh
! common/makefiles/Main.gmk
! common/makefiles/javadoc/Javadoc.gmk

Changeset: 7d7dd520ebfd
Author:    erikj
Date:      2012-11-28 13:48 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/7d7dd520ebfd

8003528: build-infra: Diffs in libjava and hotspot libs on solaris.
Summary: Linking against server jvm first if available. Adding filters and exceptions for hotspot lib compare on solaris.
Reviewed-by: ohair, ohrstrom

! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4
! common/bin/compare_exceptions.sh.incl

Changeset: 0e1b5886b06c
Author:    katleman
Date:      2012-11-15 15:38 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/0e1b5886b06c

Added tag jdk8-b65 for changeset b772de306dc2

! .hgtags

Changeset: 13bb8c326e7b
Author:    katleman
Date:      2012-11-28 14:03 -0800
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/13bb8c326e7b

Merge


Changeset: 2a75cc4ccd54
Author:    erikj
Date:      2012-11-29 10:41 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/2a75cc4ccd54

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4
! common/bin/compare.sh
! common/bin/compare_exceptions.sh.incl
! common/makefiles/Main.gmk
! common/makefiles/javadoc/Javadoc.gmk

Changeset: 8b228501bed1
Author:    erikj
Date:      2012-11-29 15:27 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/8b228501bed1

Merge




From erik.joelsson at oracle.com  Fri Nov 30 01:44:14 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 30 Nov 2012 09:44:14 +0000
Subject: hg: build-infra/jdk8/jdk: Fixed x11 wrappers on solaris.
Message-ID: <20121130094449.B13D647C28@hg.openjdk.java.net>

Changeset: 48257b138189
Author:    erikj
Date:      2012-11-30 10:44 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/48257b138189

Fixed x11 wrappers on solaris.

! makefiles/GensrcX11Wrappers.gmk
+ src/solaris/classes/sun/awt/X11/generator/sizes.64-solaris-i386



From erik.joelsson at oracle.com  Fri Nov 30 08:50:09 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 30 Nov 2012 16:50:09 +0000
Subject: hg: build-infra/jdk8/jdk: 2 new changesets
Message-ID: <20121130165034.2EE8147C3D@hg.openjdk.java.net>

Changeset: 970b580732a6
Author:    erikj
Date:      2012-11-30 17:45 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/970b580732a6

Suggested fix for 8001753: build-infra: mismatch with full debug symbol control for hotspot

! makefiles/CompileNativeLibraries.gmk

Changeset: da91947faadb
Author:    erikj
Date:      2012-11-30 17:49 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/da91947faadb

Merge




From erik.joelsson at oracle.com  Fri Nov 30 08:50:48 2012
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 30 Nov 2012 16:50:48 +0000
Subject: hg: build-infra/jdk8: 2 new changesets
Message-ID: <20121130165048.2C03647C3E@hg.openjdk.java.net>

Changeset: 5d3676cba456
Author:    erikj
Date:      2012-11-30 12:25 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/5d3676cba456

8003819: build-infra: backslashes at end of LIB and INCLUDE in spec.gmk. 8003414: build-infra: fails on windows.

! common/autoconf/toolchain_windows.m4

Changeset: e7f0da563619
Author:    erikj
Date:      2012-11-30 17:48 +0100
URL:       http://hg.openjdk.java.net/build-infra/jdk8/rev/e7f0da563619

Suggested fix for 8001753: build-infra: mismatch with full debug symbol control for hotspot

! common/autoconf/generated-configure.sh
! common/autoconf/hotspot-spec.gmk.in
! common/autoconf/jdk-options.m4
! common/makefiles/NativeCompilation.gmk



From scott.kovatch at oracle.com  Thu Nov  1 12:01:26 2012
From: scott.kovatch at oracle.com (Scott Kovatch)
Date: Thu, 01 Nov 2012 19:01:26 -0000
Subject: New builds from the build-infra team
In-Reply-To: <DCA50F95-9C8E-45BB-86BE-6BE322E1E916@oracle.com>
References: <DCA50F95-9C8E-45BB-86BE-6BE322E1E916@oracle.com>
Message-ID: <737FCF2D-0568-4F87-8CF0-1BC9DB8113A1@oracle.com>

If this works on the Mac out of the box I'm buying you a beer. All of the caveats about gnumake 3.81 make me suspicious, though.

-- Scott K.

On Nov 1, 2012, at 11:38 AM, Kelly O'Hair <kelly.ohair at oracle.com> wrote:

> 
> Pardon the wide email, but this impacts everyone building the OpenJDK jdk8/jdk8 derived forests.
> 
> Please only reply to the build-infra-dev mailing list, or just me.
> 
> With some recent integrations from the build-infra project into jdk8/jdk8 repositories, the build-infra team
> would like to get more exposure of the new builds. These jdk8/jdk8 changes will start showing up in various
> jdk8 and team forests over the next few weeks. The default is still the old builds, but both builds work in most
> cases for OpenJDK as far as we know.
> 
> At a very high level, the intent is that once you get a forest:
>  hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>  cd j8
>  sh ./get_source.sh
> 
> You should be able to simply configure&&make (the ultimate goal is this simple anyway), e.g.
>   sh ./configure
>   make NEWBUILD=true     # The NEWBUILD=true will become the default when we formally switch.
> 
> Where "make" is GNU make 3.81, and your system has all the requires packages and PATH contains the
> needed tools. Note that on Windows, MKS unix utilities cannot be used with the new builds, just CYGWIN
> is recommended at this time.



From anthony.petrov at oracle.com  Wed Nov  7 06:16:20 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 07 Nov 2012 14:16:20 -0000
Subject: New builds from the build-infra team
In-Reply-To: <DCA50F95-9C8E-45BB-86BE-6BE322E1E916@oracle.com>
References: <DCA50F95-9C8E-45BB-86BE-6BE322E1E916@oracle.com>
Message-ID: <509A6D34.8090507@oracle.com>

Hi All,

(please keep me in CC since I'm not subscribed to this list)

(I'm building on Linux i586)

1. Could we add the 
/java/re/jdk/<version>/promoted/latest/binaries/<platform>/ directories 
to check for a Boot JDK to ./configure? E.g. 
/java/re/jdk/7u10/promoted/latest/binaries/linux-i586. I realize that 
this is almost useless outside of Oracle, but it would be really helpful 
for internal builds when one has already set up the /java directory 
structure properly.

2. What is the ./build/linux-x86-normal-server-release directory, and 
why is it not ./build/linux-i586 ? What does 'normal' stand for? The 
same question about the 'server' part.

3. I get the following error and the build stops:

> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `UnrollHalfToFloat':
> cmspack.c:(.text+0x1f25): undefined reference to `_cmsHalf2Float'
> cmspack.c:(.text+0x1f73): undefined reference to `_cmsHalf2Float'
> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `UnrollHalfTo16':
> cmspack.c:(.text+0x261d): undefined reference to `_cmsHalf2Float'
> cmspack.c:(.text+0x26bd): undefined reference to `_cmsHalf2Float'
> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `PackHalfFromFloat':
> cmspack.c:(.text+0x36bb): undefined reference to `_cmsFloat2Half'
> cmspack.c:(.text+0x3710): undefined reference to `_cmsFloat2Half'
> cmspack.c:(.text+0x37af): undefined reference to `_cmsFloat2Half'
> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `PackHalfFrom16':
> cmspack.c:(.text+0x38a8): undefined reference to `_cmsFloat2Half'
> cmspack.c:(.text+0x3906): undefined reference to `_cmsFloat2Half'
> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o:cmspack.c:(.text+0x39a7): more undefined references to `_cmsFloat2Half' follow
> collect2: ld returned 1 exit status
> gmake[3]: *** [/export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/lib/i386/liblcms.so] Error 1
> gmake[3]: *** Waiting for unfinished jobs....
> gmake[3]: Leaving directory `/export/anthony/8-50-full-new-build/jdk/makefiles'
> gmake[2]: *** [libs-only] Error 2
> gmake[2]: Leaving directory `/export/anthony/8-50-full-new-build/jdk/makefiles'
> make[1]: *** [jdk-only] Error 2
> make[1]: Leaving directory `/export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release'
> make: *** [all] Error 2

Is this a known issue with lcms? Note that I've almost exclusively 
always built JDK w/ closed repos, and this time I'm building OpenJDK 
repos only. I'll try to clone the closed parts and see if this 
eliminates the issue #3.

--
best regards,
Anthony

On 11/1/2012 10:38 PM, Kelly O'Hair wrote:
> Pardon the wide email, but this impacts everyone building the OpenJDK jdk8/jdk8 derived forests.
> 
> Please only reply to the build-infra-dev mailing list, or just me.
> 
> With some recent integrations from the build-infra project into jdk8/jdk8 repositories, the build-infra team
> would like to get more exposure of the new builds. These jdk8/jdk8 changes will start showing up in various
> jdk8 and team forests over the next few weeks. The default is still the old builds, but both builds work in most
> cases for OpenJDK as far as we know.
> 
> At a very high level, the intent is that once you get a forest:
>   hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>   cd j8
>   sh ./get_source.sh
> 
> You should be able to simply configure&&make (the ultimate goal is this simple anyway), e.g.
>    sh ./configure
>    make NEWBUILD=true     # The NEWBUILD=true will become the default when we formally switch.
> 
> Where "make" is GNU make 3.81, and your system has all the requires packages and PATH contains the
> needed tools. Note that on Windows, MKS unix utilities cannot be used with the new builds, just CYGWIN
> is recommended at this time.
> 
> Of course, we know, it's never as easy as a simple configure&&make, and often you will need to pass in
> configure options.
> 
> What we would like to know is where a simple configure&&make does not work, and anything people had
> to do to make it work.
> 
> I know many of you are quite used to the old builds, so I have a temporary  "bridgeBuild" target
> people can try that will attempt to map the ALT_* environment variables to an appropriate configure command
> and then run that configure command and do the build, e.g.
> 
>   make NEWBUILD=true bridgeBuild
> 
> People willing to do comparisons between the old and new builds could:
>   rm -f -r build
>   time make NEWBUILD=true bridgeBuild
>   rm -f -r build
>   time make NO_DOCS=true     # Old builds do not generate javadocs by default
> 
> Any observations about speed of the builds would be appreciated, as will any impressions on what you see.
> 
> At this time, we think this is working pretty well with a few caveats:
>   * GNU make with the new builds is doing much more parallel processing and this can stress out a system
>     - Use "make JOBS=1" if you suspect a problem, then try adjusting it up slowly.
>   * Partial builds are limited, right now full builds of the entire OpenJDK is the target
>     - Hotspot can still be built on it's own, but everyone else needs to build hotspot at least once
>   * Paths with multiple names can cause problems, e.g. being on system svc6, and access an exported share
>     area as /net/svc6/export/foobar  instead of /export/foobar  will cause problems. Use local paths.
> 
> We know there are still issues and we will be focusing heavily on the critical ones in the next few weeks, but
> we do need the community to tell us what the critical issues really are.
> 
> Our number one priority at this time is that everyone that was able to build the old way, should be able to build
> with the new build-infra makefiles. Please help us verify that.
> 
> -kto
> 


From anthony.petrov at oracle.com  Wed Nov  7 07:14:43 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 07 Nov 2012 15:14:43 -0000
Subject: New builds from the build-infra team
In-Reply-To: <509A6D34.8090507@oracle.com>
References: <DCA50F95-9C8E-45BB-86BE-6BE322E1E916@oracle.com>
	<509A6D34.8090507@oracle.com>
Message-ID: <509A7AE4.1060805@oracle.com>

Update on issue #3: after cloning the closed repos my build succeeded. 
Must be an issue related to OPENJDK=true builds only. Still, I'd like to 
get some comments regarding #1 and #2 below. Thanks in advance.

--
best regards,
Anthony

On 11/7/2012 6:16 PM, Anthony Petrov wrote:
> Hi All,
> 
> (please keep me in CC since I'm not subscribed to this list)
> 
> (I'm building on Linux i586)
> 
> 1. Could we add the 
> /java/re/jdk/<version>/promoted/latest/binaries/<platform>/ directories 
> to check for a Boot JDK to ./configure? E.g. 
> /java/re/jdk/7u10/promoted/latest/binaries/linux-i586. I realize that 
> this is almost useless outside of Oracle, but it would be really helpful 
> for internal builds when one has already set up the /java directory 
> structure properly.
> 
> 2. What is the ./build/linux-x86-normal-server-release directory, and 
> why is it not ./build/linux-i586 ? What does 'normal' stand for? The 
> same question about the 'server' part.
> 
> 3. I get the following error and the build stops:
> 
>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: 
>> In function `UnrollHalfToFloat':
>> cmspack.c:(.text+0x1f25): undefined reference to `_cmsHalf2Float'
>> cmspack.c:(.text+0x1f73): undefined reference to `_cmsHalf2Float'
>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: 
>> In function `UnrollHalfTo16':
>> cmspack.c:(.text+0x261d): undefined reference to `_cmsHalf2Float'
>> cmspack.c:(.text+0x26bd): undefined reference to `_cmsHalf2Float'
>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: 
>> In function `PackHalfFromFloat':
>> cmspack.c:(.text+0x36bb): undefined reference to `_cmsFloat2Half'
>> cmspack.c:(.text+0x3710): undefined reference to `_cmsFloat2Half'
>> cmspack.c:(.text+0x37af): undefined reference to `_cmsFloat2Half'
>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: 
>> In function `PackHalfFrom16':
>> cmspack.c:(.text+0x38a8): undefined reference to `_cmsFloat2Half'
>> cmspack.c:(.text+0x3906): undefined reference to `_cmsFloat2Half'
>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o:cmspack.c:(.text+0x39a7): 
>> more undefined references to `_cmsFloat2Half' follow
>> collect2: ld returned 1 exit status
>> gmake[3]: *** 
>> [/export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/lib/i386/liblcms.so] 
>> Error 1
>> gmake[3]: *** Waiting for unfinished jobs....
>> gmake[3]: Leaving directory 
>> `/export/anthony/8-50-full-new-build/jdk/makefiles'
>> gmake[2]: *** [libs-only] Error 2
>> gmake[2]: Leaving directory 
>> `/export/anthony/8-50-full-new-build/jdk/makefiles'
>> make[1]: *** [jdk-only] Error 2
>> make[1]: Leaving directory 
>> `/export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release' 
>>
>> make: *** [all] Error 2
> 
> Is this a known issue with lcms? Note that I've almost exclusively 
> always built JDK w/ closed repos, and this time I'm building OpenJDK 
> repos only. I'll try to clone the closed parts and see if this 
> eliminates the issue #3.
> 
> -- 
> best regards,
> Anthony
> 
> On 11/1/2012 10:38 PM, Kelly O'Hair wrote:
>> Pardon the wide email, but this impacts everyone building the OpenJDK 
>> jdk8/jdk8 derived forests.
>>
>> Please only reply to the build-infra-dev mailing list, or just me.
>>
>> With some recent integrations from the build-infra project into 
>> jdk8/jdk8 repositories, the build-infra team
>> would like to get more exposure of the new builds. These jdk8/jdk8 
>> changes will start showing up in various
>> jdk8 and team forests over the next few weeks. The default is still 
>> the old builds, but both builds work in most
>> cases for OpenJDK as far as we know.
>>
>> At a very high level, the intent is that once you get a forest:
>>   hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>>   cd j8
>>   sh ./get_source.sh
>>
>> You should be able to simply configure&&make (the ultimate goal is 
>> this simple anyway), e.g.
>>    sh ./configure
>>    make NEWBUILD=true     # The NEWBUILD=true will become the default 
>> when we formally switch.
>>
>> Where "make" is GNU make 3.81, and your system has all the requires 
>> packages and PATH contains the
>> needed tools. Note that on Windows, MKS unix utilities cannot be used 
>> with the new builds, just CYGWIN
>> is recommended at this time.
>>
>> Of course, we know, it's never as easy as a simple configure&&make, 
>> and often you will need to pass in
>> configure options.
>>
>> What we would like to know is where a simple configure&&make does not 
>> work, and anything people had
>> to do to make it work.
>>
>> I know many of you are quite used to the old builds, so I have a 
>> temporary  "bridgeBuild" target
>> people can try that will attempt to map the ALT_* environment 
>> variables to an appropriate configure command
>> and then run that configure command and do the build, e.g.
>>
>>   make NEWBUILD=true bridgeBuild
>>
>> People willing to do comparisons between the old and new builds could:
>>   rm -f -r build
>>   time make NEWBUILD=true bridgeBuild
>>   rm -f -r build
>>   time make NO_DOCS=true     # Old builds do not generate javadocs by 
>> default
>>
>> Any observations about speed of the builds would be appreciated, as 
>> will any impressions on what you see.
>>
>> At this time, we think this is working pretty well with a few caveats:
>>   * GNU make with the new builds is doing much more parallel 
>> processing and this can stress out a system
>>     - Use "make JOBS=1" if you suspect a problem, then try adjusting 
>> it up slowly.
>>   * Partial builds are limited, right now full builds of the entire 
>> OpenJDK is the target
>>     - Hotspot can still be built on it's own, but everyone else needs 
>> to build hotspot at least once
>>   * Paths with multiple names can cause problems, e.g. being on system 
>> svc6, and access an exported share
>>     area as /net/svc6/export/foobar  instead of /export/foobar  will 
>> cause problems. Use local paths.
>>
>> We know there are still issues and we will be focusing heavily on the 
>> critical ones in the next few weeks, but
>> we do need the community to tell us what the critical issues really are.
>>
>> Our number one priority at this time is that everyone that was able to 
>> build the old way, should be able to build
>> with the new build-infra makefiles. Please help us verify that.
>>
>> -kto
>>
> 


From anthony.petrov at oracle.com  Wed Nov  7 07:25:52 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 07 Nov 2012 15:25:52 -0000
Subject: New builds from the build-infra team
In-Reply-To: <509A7AE4.1060805@oracle.com>
References: <DCA50F95-9C8E-45BB-86BE-6BE322E1E916@oracle.com>
	<509A6D34.8090507@oracle.com> <509A7AE4.1060805@oracle.com>
Message-ID: <509A7D7F.60608@oracle.com>

A follow up message. Generally, the new builds work fine. A couple 
suggestions:

1. Can we make hotspot builds less noisy? Unless there are warnings or 
errors, there's no need to print out the name of each file being compiled.

2. There's a lot of warnings generated when compiling JDK native code. I 
think some of them can be related to the new build. After they are 
analyzed, can somebody from build-infra file bugs against appropriate 
teams to fix them up?

--
best regards,
Anthony

On 11/7/2012 7:14 PM, Anthony Petrov wrote:
> Update on issue #3: after cloning the closed repos my build succeeded. 
> Must be an issue related to OPENJDK=true builds only. Still, I'd like to 
> get some comments regarding #1 and #2 below. Thanks in advance.
> 
> -- 
> best regards,
> Anthony
> 
> On 11/7/2012 6:16 PM, Anthony Petrov wrote:
>> Hi All,
>>
>> (please keep me in CC since I'm not subscribed to this list)
>>
>> (I'm building on Linux i586)
>>
>> 1. Could we add the 
>> /java/re/jdk/<version>/promoted/latest/binaries/<platform>/ 
>> directories to check for a Boot JDK to ./configure? E.g. 
>> /java/re/jdk/7u10/promoted/latest/binaries/linux-i586. I realize that 
>> this is almost useless outside of Oracle, but it would be really 
>> helpful for internal builds when one has already set up the /java 
>> directory structure properly.
>>
>> 2. What is the ./build/linux-x86-normal-server-release directory, and 
>> why is it not ./build/linux-i586 ? What does 'normal' stand for? The 
>> same question about the 'server' part.
>>
>> 3. I get the following error and the build stops:
>>
>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: 
>>> In function `UnrollHalfToFloat':
>>> cmspack.c:(.text+0x1f25): undefined reference to `_cmsHalf2Float'
>>> cmspack.c:(.text+0x1f73): undefined reference to `_cmsHalf2Float'
>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: 
>>> In function `UnrollHalfTo16':
>>> cmspack.c:(.text+0x261d): undefined reference to `_cmsHalf2Float'
>>> cmspack.c:(.text+0x26bd): undefined reference to `_cmsHalf2Float'
>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: 
>>> In function `PackHalfFromFloat':
>>> cmspack.c:(.text+0x36bb): undefined reference to `_cmsFloat2Half'
>>> cmspack.c:(.text+0x3710): undefined reference to `_cmsFloat2Half'
>>> cmspack.c:(.text+0x37af): undefined reference to `_cmsFloat2Half'
>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: 
>>> In function `PackHalfFrom16':
>>> cmspack.c:(.text+0x38a8): undefined reference to `_cmsFloat2Half'
>>> cmspack.c:(.text+0x3906): undefined reference to `_cmsFloat2Half'
>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o:cmspack.c:(.text+0x39a7): 
>>> more undefined references to `_cmsFloat2Half' follow
>>> collect2: ld returned 1 exit status
>>> gmake[3]: *** 
>>> [/export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/lib/i386/liblcms.so] 
>>> Error 1
>>> gmake[3]: *** Waiting for unfinished jobs....
>>> gmake[3]: Leaving directory 
>>> `/export/anthony/8-50-full-new-build/jdk/makefiles'
>>> gmake[2]: *** [libs-only] Error 2
>>> gmake[2]: Leaving directory 
>>> `/export/anthony/8-50-full-new-build/jdk/makefiles'
>>> make[1]: *** [jdk-only] Error 2
>>> make[1]: Leaving directory 
>>> `/export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release' 
>>>
>>> make: *** [all] Error 2
>>
>> Is this a known issue with lcms? Note that I've almost exclusively 
>> always built JDK w/ closed repos, and this time I'm building OpenJDK 
>> repos only. I'll try to clone the closed parts and see if this 
>> eliminates the issue #3.
>>
>> -- 
>> best regards,
>> Anthony
>>
>> On 11/1/2012 10:38 PM, Kelly O'Hair wrote:
>>> Pardon the wide email, but this impacts everyone building the OpenJDK 
>>> jdk8/jdk8 derived forests.
>>>
>>> Please only reply to the build-infra-dev mailing list, or just me.
>>>
>>> With some recent integrations from the build-infra project into 
>>> jdk8/jdk8 repositories, the build-infra team
>>> would like to get more exposure of the new builds. These jdk8/jdk8 
>>> changes will start showing up in various
>>> jdk8 and team forests over the next few weeks. The default is still 
>>> the old builds, but both builds work in most
>>> cases for OpenJDK as far as we know.
>>>
>>> At a very high level, the intent is that once you get a forest:
>>>   hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>>>   cd j8
>>>   sh ./get_source.sh
>>>
>>> You should be able to simply configure&&make (the ultimate goal is 
>>> this simple anyway), e.g.
>>>    sh ./configure
>>>    make NEWBUILD=true     # The NEWBUILD=true will become the default 
>>> when we formally switch.
>>>
>>> Where "make" is GNU make 3.81, and your system has all the requires 
>>> packages and PATH contains the
>>> needed tools. Note that on Windows, MKS unix utilities cannot be used 
>>> with the new builds, just CYGWIN
>>> is recommended at this time.
>>>
>>> Of course, we know, it's never as easy as a simple configure&&make, 
>>> and often you will need to pass in
>>> configure options.
>>>
>>> What we would like to know is where a simple configure&&make does not 
>>> work, and anything people had
>>> to do to make it work.
>>>
>>> I know many of you are quite used to the old builds, so I have a 
>>> temporary  "bridgeBuild" target
>>> people can try that will attempt to map the ALT_* environment 
>>> variables to an appropriate configure command
>>> and then run that configure command and do the build, e.g.
>>>
>>>   make NEWBUILD=true bridgeBuild
>>>
>>> People willing to do comparisons between the old and new builds could:
>>>   rm -f -r build
>>>   time make NEWBUILD=true bridgeBuild
>>>   rm -f -r build
>>>   time make NO_DOCS=true     # Old builds do not generate javadocs by 
>>> default
>>>
>>> Any observations about speed of the builds would be appreciated, as 
>>> will any impressions on what you see.
>>>
>>> At this time, we think this is working pretty well with a few caveats:
>>>   * GNU make with the new builds is doing much more parallel 
>>> processing and this can stress out a system
>>>     - Use "make JOBS=1" if you suspect a problem, then try adjusting 
>>> it up slowly.
>>>   * Partial builds are limited, right now full builds of the entire 
>>> OpenJDK is the target
>>>     - Hotspot can still be built on it's own, but everyone else needs 
>>> to build hotspot at least once
>>>   * Paths with multiple names can cause problems, e.g. being on 
>>> system svc6, and access an exported share
>>>     area as /net/svc6/export/foobar  instead of /export/foobar  will 
>>> cause problems. Use local paths.
>>>
>>> We know there are still issues and we will be focusing heavily on the 
>>> critical ones in the next few weeks, but
>>> we do need the community to tell us what the critical issues really are.
>>>
>>> Our number one priority at this time is that everyone that was able 
>>> to build the old way, should be able to build
>>> with the new build-infra makefiles. Please help us verify that.
>>>
>>> -kto
>>>
>>
> 


From anthony.petrov at oracle.com  Fri Nov  9 06:04:28 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 09 Nov 2012 14:04:28 -0000
Subject: New builds from the build-infra team
In-Reply-To: <DEF58201-75C0-4D4B-A063-7C8622C4F9D5@oracle.com>
References: <DCA50F95-9C8E-45BB-86BE-6BE322E1E916@oracle.com>
	<509A6D34.8090507@oracle.com>
	<DEF58201-75C0-4D4B-A063-7C8622C4F9D5@oracle.com>
Message-ID: <509D0D9F.9090207@oracle.com>

On 11/8/2012 12:22 AM, Kelly O'Hair wrote:
> On Nov 7, 2012, at 6:16 AM, Anthony Petrov wrote:
>> (please keep me in CC since I'm not subscribed to this list)
>>
>> (I'm building on Linux i586)
> 
> Fedora 9 x86 or something else?  The specific Linux distro and release 
> number is always a big help.

I run Mandriva 2010.2 i586.


>> 1. Could we add the 
>> /java/re/jdk/<version>/promoted/latest/binaries/<platform>/ 
>> directories to check for a Boot JDK to ./configure? E.g. 
>> /java/re/jdk/7u10/promoted/latest/binaries/linux-i586. I realize that 
>> this is almost useless outside of Oracle, but it would be really 
>> helpful for internal builds when one has already set up the /java 
>> directory structure properly.
> 
> I'm not sure that "... set up the /java directory structure properly." 
> is a very well-defined thing. That's been part of the issue
> with the /java/ layout, many people think they know what the layout is, 
> but nobody has the same layout. :^(
> I generally put the boot jdk java in the PATH, and that seems to work fine.
> With the /java/re path being an automount NFS path, I have a very hard 
> time making that something we will find by default.
> 
> But Magnus added a --with-java-path option that will use the /java 
> paths, just have not used it.
> 
> We have tried hard to make the builds as fast as possible and reliable, 
> and local installs of the tools is what
> should be preferred.

I realize that I could put it on path, or specify --with-java-path, or 
--with-boot-jdk. But I want to do neither of these. The old builds could 
always automatically find the correct boot jdk from the default 
location, which is:

/java/re/jdk/1.7.0/archive/fcs/binaries/linux-i586

(for JDK 8 builds on Linux i586).

When building JDK 7, for instance, it would be:

/java/re/jdk/1.6.0/archive/fcs/binaries/linux-i586

I see that ./configure already checks several paths under /usr/java/ and 
  /usr/lib/jvm/. I would like it to know about the standard /java/ paths 
as well, and wouldn't require any command-line options if I have a 
correct boot JDK there.

Could we do that?


>> 2. What is the ./build/linux-x86-normal-server-release directory, and 
>> why is it not ./build/linux-i586 ? What does 'normal' stand for? The 
>> same question about the 'server' part.
>>
> 
> The configure allows for many variations on builds, and the basic 
> variation is put into the directory name.
> 
> I have been tempted to soft link linux-i586 
> to linux-x86-normal-server-release or whatever linux-x86-*name is generated
> (assuming only one exists), but it gets a little complicated.

Well, I'm fine with any directory name. I just want to understand the 
reason why we have to change it to something other than simple 
"linux-i586" (at least for default builds).

--
best regards,
Anthony



>> 3. I get the following error and the build stops:
>>
>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: 
>>> In function `UnrollHalfToFloat':
>>> cmspack.c:(.text+0x1f25): undefined reference to `_cmsHalf2Float'
>>> cmspack.c:(.text+0x1f73): undefined reference to `_cmsHalf2Float'
>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: 
>>> In function `UnrollHalfTo16':
>>> cmspack.c:(.text+0x261d): undefined reference to `_cmsHalf2Float'
>>> cmspack.c:(.text+0x26bd): undefined reference to `_cmsHalf2Float'
>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: 
>>> In function `PackHalfFromFloat':
>>> cmspack.c:(.text+0x36bb): undefined reference to `_cmsFloat2Half'
>>> cmspack.c:(.text+0x3710): undefined reference to `_cmsFloat2Half'
>>> cmspack.c:(.text+0x37af): undefined reference to `_cmsFloat2Half'
>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: 
>>> In function `PackHalfFrom16':
>>> cmspack.c:(.text+0x38a8): undefined reference to `_cmsFloat2Half'
>>> cmspack.c:(.text+0x3906): undefined reference to `_cmsFloat2Half'
>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o:cmspack.c:(.text+0x39a7): 
>>> more undefined references to `_cmsFloat2Half' follow
>>> collect2: ld returned 1 exit status
>>> gmake[3]: *** 
>>> [/export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/lib/i386/liblcms.so] 
>>> Error 1
>>> gmake[3]: *** Waiting for unfinished jobs....
>>> gmake[3]: Leaving directory 
>>> `/export/anthony/8-50-full-new-build/jdk/makefiles'
>>> gmake[2]: *** [libs-only] Error 2
>>> gmake[2]: Leaving directory 
>>> `/export/anthony/8-50-full-new-build/jdk/makefiles'
>>> make[1]: *** [jdk-only] Error 2
>>> make[1]: Leaving directory 
>>> `/export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release'
>>> make: *** [all] Error 2
>>
>> Is this a known issue with lcms? Note that I've almost exclusively 
>> always built JDK w/ closed repos, and this time I'm building OpenJDK 
>> repos only. I'll try to clone the closed parts and see if this 
>> eliminates the issue #3.
> 
> Never seen this problem before.
> 
> -kto
> 
>>
>> --
>> best regards,
>> Anthony
>>
>> On 11/1/2012 10:38 PM, Kelly O'Hair wrote:
>>> Pardon the wide email, but this impacts everyone building the OpenJDK 
>>> jdk8/jdk8 derived forests.
>>> Please only reply to the build-infra-dev mailing list, or just me.
>>> With some recent integrations from the build-infra project into 
>>> jdk8/jdk8 repositories, the build-infra team
>>> would like to get more exposure of the new builds. These jdk8/jdk8 
>>> changes will start showing up in various
>>> jdk8 and team forests over the next few weeks. The default is still 
>>> the old builds, but both builds work in most
>>> cases for OpenJDK as far as we know.
>>> At a very high level, the intent is that once you get a forest:
>>>  hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>>>  cd j8
>>>  sh ./get_source.sh
>>> You should be able to simply configure&&make (the ultimate goal is 
>>> this simple anyway), e.g.
>>>   sh ./configure
>>>   make NEWBUILD=true     # The NEWBUILD=true will become the default 
>>> when we formally switch.
>>> Where "make" is GNU make 3.81, and your system has all the requires 
>>> packages and PATH contains the
>>> needed tools. Note that on Windows, MKS unix utilities cannot be used 
>>> with the new builds, just CYGWIN
>>> is recommended at this time.
>>> Of course, we know, it's never as easy as a simple configure&&make, 
>>> and often you will need to pass in
>>> configure options.
>>> What we would like to know is where a simple configure&&make does not 
>>> work, and anything people had
>>> to do to make it work.
>>> I know many of you are quite used to the old builds, so I have a 
>>> temporary  "bridgeBuild" target
>>> people can try that will attempt to map the ALT_* environment 
>>> variables to an appropriate configure command
>>> and then run that configure command and do the build, e.g.
>>>  make NEWBUILD=true bridgeBuild
>>> People willing to do comparisons between the old and new builds could:
>>>  rm -f -r build
>>>  time make NEWBUILD=true bridgeBuild
>>>  rm -f -r build
>>>  time make NO_DOCS=true     # Old builds do not generate javadocs by 
>>> default
>>> Any observations about speed of the builds would be appreciated, as 
>>> will any impressions on what you see.
>>> At this time, we think this is working pretty well with a few caveats:
>>>  * GNU make with the new builds is doing much more parallel 
>>> processing and this can stress out a system
>>>    - Use "make JOBS=1" if you suspect a problem, then try adjusting 
>>> it up slowly.
>>>  * Partial builds are limited, right now full builds of the entire 
>>> OpenJDK is the target
>>>    - Hotspot can still be built on it's own, but everyone else needs 
>>> to build hotspot at least once
>>>  * Paths with multiple names can cause problems, e.g. being on system 
>>> svc6, and access an exported share
>>>    area as /net/svc6/export/foobar  instead of /export/foobar  will 
>>> cause problems. Use local paths.
>>> We know there are still issues and we will be focusing heavily on the 
>>> critical ones in the next few weeks, but
>>> we do need the community to tell us what the critical issues really are.
>>> Our number one priority at this time is that everyone that was able 
>>> to build the old way, should be able to build
>>> with the new build-infra makefiles. Please help us verify that.
>>> -kto
> 


From anthony.petrov at oracle.com  Fri Nov  9 06:15:58 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 09 Nov 2012 14:15:58 -0000
Subject: New builds from the build-infra team
In-Reply-To: <D06266B6-A104-4FF1-9262-62477B7FC259@oracle.com>
References: <DCA50F95-9C8E-45BB-86BE-6BE322E1E916@oracle.com>
	<509A6D34.8090507@oracle.com> <509A7AE4.1060805@oracle.com>
	<509A7D7F.60608@oracle.com>
	<D06266B6-A104-4FF1-9262-62477B7FC259@oracle.com>
Message-ID: <509D1023.7070003@oracle.com>

On 11/8/2012 12:30 AM, Kelly O'Hair wrote:
> On Nov 7, 2012, at 7:25 AM, Anthony Petrov wrote:
> 
>> A follow up message. Generally, the new builds work fine. A couple suggestions:
>>
>> 1. Can we make hotspot builds less noisy? Unless there are warnings or errors, there's no need to print out the name of each file being compiled.
> 
> It's hard to know before hand if a file has errors or warnings but the hotspot makefiles are actually
> unchanged for the most part, so you are seeing the old and traditional hotspot build output.
> 
> There is a great deal of debate on this noisy vs. quiet logging issue, and Magnus at least tried to deal with
> it by adding a LOG option, so you can try:
>    make LOG=warn
> if I remember right. But it may be a while before we can get the hotspot makefiles to obey this setting.

I see. I just seen how much less noise the JDK build produces now (and 
this is cool, IMO), and been under impression that HotSpot makefiles 
differ a little in this respect. It appears they differ a lot... yet. 
All right, will wait then till HotSpot folks fix them.


>> 2. There's a lot of warnings generated when compiling JDK native code. I think some of them can be related to the new build. After they are analyzed, can somebody from build-infra file bugs against appropriate teams to fix them up?
> 
> I don't think the new build is adding warnings, but I can't be sure. These should be the same warnings as the old
> build, but may be more visible when the compile lines are not echo'd.

Exactly!

> The last time I filed a whole bunch of bugs against warnings in the build, it was a royal pain, like herding cats
> to get all the various teams to do anything about it. But at some point we will do another warning hunt fix,
> just not sure the build team will be driving it or not.

Well, I don't think we should actively drive this effort. But at least 
just filing the bugs would be a very good thing to do. As we slowly 
switching to the new build, I think we should just tell people to file 
bugs against warnings whenever they see them. I guess that after closing 
dozens of duplicates, the responsible teams will finally fix them.

And, btw, -Werror would make the issues P1. Just saying. :))

--
best regards,
Anthony

> 
> -kto
> 
>> --
>> best regards,
>> Anthony
>>
>> On 11/7/2012 7:14 PM, Anthony Petrov wrote:
>>> Update on issue #3: after cloning the closed repos my build succeeded. Must be an issue related to OPENJDK=true builds only. Still, I'd like to get some comments regarding #1 and #2 below. Thanks in advance.
>>> -- 
>>> best regards,
>>> Anthony
>>> On 11/7/2012 6:16 PM, Anthony Petrov wrote:
>>>> Hi All,
>>>>
>>>> (please keep me in CC since I'm not subscribed to this list)
>>>>
>>>> (I'm building on Linux i586)
>>>>
>>>> 1. Could we add the /java/re/jdk/<version>/promoted/latest/binaries/<platform>/ directories to check for a Boot JDK to ./configure? E.g. /java/re/jdk/7u10/promoted/latest/binaries/linux-i586. I realize that this is almost useless outside of Oracle, but it would be really helpful for internal builds when one has already set up the /java directory structure properly.
>>>>
>>>> 2. What is the ./build/linux-x86-normal-server-release directory, and why is it not ./build/linux-i586 ? What does 'normal' stand for? The same question about the 'server' part.
>>>>
>>>> 3. I get the following error and the build stops:
>>>>
>>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `UnrollHalfToFloat':
>>>>> cmspack.c:(.text+0x1f25): undefined reference to `_cmsHalf2Float'
>>>>> cmspack.c:(.text+0x1f73): undefined reference to `_cmsHalf2Float'
>>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `UnrollHalfTo16':
>>>>> cmspack.c:(.text+0x261d): undefined reference to `_cmsHalf2Float'
>>>>> cmspack.c:(.text+0x26bd): undefined reference to `_cmsHalf2Float'
>>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `PackHalfFromFloat':
>>>>> cmspack.c:(.text+0x36bb): undefined reference to `_cmsFloat2Half'
>>>>> cmspack.c:(.text+0x3710): undefined reference to `_cmsFloat2Half'
>>>>> cmspack.c:(.text+0x37af): undefined reference to `_cmsFloat2Half'
>>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `PackHalfFrom16':
>>>>> cmspack.c:(.text+0x38a8): undefined reference to `_cmsFloat2Half'
>>>>> cmspack.c:(.text+0x3906): undefined reference to `_cmsFloat2Half'
>>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o:cmspack.c:(.text+0x39a7): more undefined references to `_cmsFloat2Half' follow
>>>>> collect2: ld returned 1 exit status
>>>>> gmake[3]: *** [/export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/lib/i386/liblcms.so] Error 1
>>>>> gmake[3]: *** Waiting for unfinished jobs....
>>>>> gmake[3]: Leaving directory `/export/anthony/8-50-full-new-build/jdk/makefiles'
>>>>> gmake[2]: *** [libs-only] Error 2
>>>>> gmake[2]: Leaving directory `/export/anthony/8-50-full-new-build/jdk/makefiles'
>>>>> make[1]: *** [jdk-only] Error 2
>>>>> make[1]: Leaving directory `/export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release' 
>>>>> make: *** [all] Error 2
>>>> Is this a known issue with lcms? Note that I've almost exclusively always built JDK w/ closed repos, and this time I'm building OpenJDK repos only. I'll try to clone the closed parts and see if this eliminates the issue #3.
>>>>
>>>> -- 
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 11/1/2012 10:38 PM, Kelly O'Hair wrote:
>>>>> Pardon the wide email, but this impacts everyone building the OpenJDK jdk8/jdk8 derived forests.
>>>>>
>>>>> Please only reply to the build-infra-dev mailing list, or just me.
>>>>>
>>>>> With some recent integrations from the build-infra project into jdk8/jdk8 repositories, the build-infra team
>>>>> would like to get more exposure of the new builds. These jdk8/jdk8 changes will start showing up in various
>>>>> jdk8 and team forests over the next few weeks. The default is still the old builds, but both builds work in most
>>>>> cases for OpenJDK as far as we know.
>>>>>
>>>>> At a very high level, the intent is that once you get a forest:
>>>>>  hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>>>>>  cd j8
>>>>>  sh ./get_source.sh
>>>>>
>>>>> You should be able to simply configure&&make (the ultimate goal is this simple anyway), e.g.
>>>>>   sh ./configure
>>>>>   make NEWBUILD=true     # The NEWBUILD=true will become the default when we formally switch.
>>>>>
>>>>> Where "make" is GNU make 3.81, and your system has all the requires packages and PATH contains the
>>>>> needed tools. Note that on Windows, MKS unix utilities cannot be used with the new builds, just CYGWIN
>>>>> is recommended at this time.
>>>>>
>>>>> Of course, we know, it's never as easy as a simple configure&&make, and often you will need to pass in
>>>>> configure options.
>>>>>
>>>>> What we would like to know is where a simple configure&&make does not work, and anything people had
>>>>> to do to make it work.
>>>>>
>>>>> I know many of you are quite used to the old builds, so I have a temporary  "bridgeBuild" target
>>>>> people can try that will attempt to map the ALT_* environment variables to an appropriate configure command
>>>>> and then run that configure command and do the build, e.g.
>>>>>
>>>>>  make NEWBUILD=true bridgeBuild
>>>>>
>>>>> People willing to do comparisons between the old and new builds could:
>>>>>  rm -f -r build
>>>>>  time make NEWBUILD=true bridgeBuild
>>>>>  rm -f -r build
>>>>>  time make NO_DOCS=true     # Old builds do not generate javadocs by default
>>>>>
>>>>> Any observations about speed of the builds would be appreciated, as will any impressions on what you see.
>>>>>
>>>>> At this time, we think this is working pretty well with a few caveats:
>>>>>  * GNU make with the new builds is doing much more parallel processing and this can stress out a system
>>>>>    - Use "make JOBS=1" if you suspect a problem, then try adjusting it up slowly.
>>>>>  * Partial builds are limited, right now full builds of the entire OpenJDK is the target
>>>>>    - Hotspot can still be built on it's own, but everyone else needs to build hotspot at least once
>>>>>  * Paths with multiple names can cause problems, e.g. being on system svc6, and access an exported share
>>>>>    area as /net/svc6/export/foobar  instead of /export/foobar  will cause problems. Use local paths.
>>>>>
>>>>> We know there are still issues and we will be focusing heavily on the critical ones in the next few weeks, but
>>>>> we do need the community to tell us what the critical issues really are.
>>>>>
>>>>> Our number one priority at this time is that everyone that was able to build the old way, should be able to build
>>>>> with the new build-infra makefiles. Please help us verify that.
>>>>>
>>>>> -kto
>>>>>
> 


From anthony.petrov at oracle.com  Fri Nov  9 06:22:51 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 09 Nov 2012 14:22:51 -0000
Subject: New builds from the build-infra team
In-Reply-To: <509B29CC.2050409@oracle.com>
References: <DCA50F95-9C8E-45BB-86BE-6BE322E1E916@oracle.com>
	<509A6D34.8090507@oracle.com>
	<DEF58201-75C0-4D4B-A063-7C8622C4F9D5@oracle.com>
	<509B29CC.2050409@oracle.com>
Message-ID: <509D11BD.1000302@oracle.com>

On 11/8/2012 7:41 AM, David Holmes wrote:
> On 8/11/2012 6:22 AM, Kelly O'Hair wrote:
>> On Nov 7, 2012, at 6:16 AM, Anthony Petrov wrote:
>>> 2. What is the ./build/linux-x86-normal-server-release directory, and 
>>> why is it not ./build/linux-i586 ? What does 'normal' stand for? The 
>>> same question about the 'server' part.
>>>
>>
>> The configure allows for many variations on builds, and the basic 
>> variation is put into the directory name.
>>
>> I have been tempted to soft link linux-i586 to 
>> linux-x86-normal-server-release or whatever linux-x86-*name is generated
>> (assuming only one exists), but it gets a little complicated.
> 
> A couple of comments on this. As Kelly says a "configuration" can be set 
> up to build a range of different, well, configurations, and the default 
> output name reflects what you have chosen (directly or implicitly).
> 
> The "normal" is in contrast to "embedded" (which of course is not 
> applicable to OpenJDK builds). When the conversion was first started the 
> embedded build support was in the open and so two JDK variants were 
> defined. Now that the embedded build support is in the closed repo we 
> still need two variants but people only using open repos can't see there 
> is any alternative to "normal".
> 
> The "server" part is important as it indicates what flavor(s) of hotspot 
> this configuration will build. By default (why?) only the server VM is 
> built - whereas in the old build both client and server are built. So 
> you need to add --with-jvm-variant=client,server if you want both.
> 
> The "release" indicates a product build as opposed to fastdebug, for 
> example.

Thanks for the insight. Now it's clear. I can live with the new 
directory names.


> Personally I never let configure define or name the output directory. My 
> preferred approach is (via scripts) to do:
> 
> mkdir <output-dir>
> cd <output-dir>
> bash <path-to-configure> configure.sh <options>
> 
> There may also be a configure option to name the output directory 
> explicitly.

And I'm on the opposite side here, preferring to pass no 
options/environment variables to the configure/make commands at all.


>>> 3. I get the following error and the build stops:
> 
> This might not be relevant but you need to be careful if you are 
> building 32-bit on an x64 machine. If you do that you need to pass 
> --with-target-bits=32. Otherwise the default build on x64 is 64-bit.

Thanks, that's useful to know, but no, in my case both the system and 
the builds are 32-bit.

--
best regards,
Anthony


From anthony.petrov at oracle.com  Tue Nov 13 06:04:25 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 13 Nov 2012 14:04:25 -0000
Subject: New builds from the build-infra team
In-Reply-To: <A59F3F35-8DDF-407A-8449-5EEF4759F493@oracle.com>
References: <DCA50F95-9C8E-45BB-86BE-6BE322E1E916@oracle.com>
	<509A6D34.8090507@oracle.com>
	<DEF58201-75C0-4D4B-A063-7C8622C4F9D5@oracle.com>
	<509D0D9F.9090207@oracle.com>
	<A59F3F35-8DDF-407A-8449-5EEF4759F493@oracle.com>
Message-ID: <50A25343.4000606@oracle.com>

On 11/10/2012 1:05 AM, Kelly O'Hair wrote:
>>>> (I'm building on Linux i586)
>>> Fedora 9 x86 or something else?  The specific Linux distro and release number is always a big help.
>> I run Mandriva 2010.2 i586.
> 
> Interesting, never tried it before.  So I'm impressed it's working well. ;^)
> We'll put Anthony Petrov down as the Mandriva expert. ;^)

Feel free to do so. :)


>>>> 1. Could we add the /java/re/jdk/<version>/promoted/latest/binaries/<platform>/ directories to check for a Boot JDK to ./configure? E.g. /java/re/jdk/7u10/promoted/latest/binaries/linux-i586. I realize that this is almost useless outside of Oracle, but it would be really helpful for internal builds when one has already set up the /java directory structure properly.
>>> I'm not sure that "... set up the /java directory structure properly." is a very well-defined thing. That's been part of the issue
>>> with the /java/ layout, many people think they know what the layout is, but nobody has the same layout. :^(
>>> I generally put the boot jdk java in the PATH, and that seems to work fine.
>>> With the /java/re path being an automount NFS path, I have a very hard time making that something we will find by default.
>>> But Magnus added a --with-java-path option that will use the /java paths, just have not used it.
>>> We have tried hard to make the builds as fast as possible and reliable, and local installs of the tools is what
>>> should be preferred.
>> I realize that I could put it on path, or specify --with-java-path, or --with-boot-jdk. But I want to do neither of these. The old builds could always automatically find the correct boot jdk from the default location, which is:
>>
>> /java/re/jdk/1.7.0/archive/fcs/binaries/linux-i586
>>
>> (for JDK 8 builds on Linux i586).
>>
>> When building JDK 7, for instance, it would be:
>>
>> /java/re/jdk/1.6.0/archive/fcs/binaries/linux-i586
> 
> Technically, those are the wrong boot jdks in both cases. It's jdk7u7 for jdk8 now, and jdk6u18 for jdk7 update builds.
> The jdk Makefiles are actually going after the wrong ones. :^( Nobody has ever keep these paths in the Makefiles up-to-date. :^(
> The RE and JPRT builds explicitly set the boot jdk to local disk copies.

Yes, this is a problem. And I think this is something that we can fix. 
The minimum required version of boot JDK must be specified somewhere in 
the makefiles (as a minimum, to perform a sanity check). Hence, we can 
use this specified value to construct a proper /java path to the boot jdk.

> But the big issue is that maybe /java works for you, but not for many others, and even if we found this /java jdk,
> if the NFS location is really slow (often hard to tell initially), do we automatically pick a boot jdk that could
> cause the builds to be like 15X slower due to the NFS network being slow?

No. I don't propose to check /java first. Let the /usr/java and 
/usr/lib/jvm be checked first, and if there's a proper boot jdk found, 
let's use it. Of course, an explicit override --with-boot-jdk will 
always get the preference. But if neither is found/specified, there's no 
reason to not also check the /java path, is there? We could print out a 
warning in this case ("you may expect a slow build"), but this doesn't 
look like an error to me.

> I have occasionally managed to get my /java automounts to go after the US East coast mirror instead of the
> closer West coast /java area and everything gets so slow that it's impossible to get any work done until you
> realize that your automounts are messed up due to some temporary system outage and a backup mount point.
> So you in general cannot trust that /java will be there or be fast access.
> 
> So many people report to me that their builds are slow or unreliable, and I find out they are using NFS paths all over  the place.

This is true. My /java is on my local disks, so the network is not an issue.


> I'm just not sure that looking for /java by default is a good idea when we cannot trust it.
> 
> I would rather explore a solution where we check the local disk areas for an appropriate java, and if none
> is found, copy one over from the /java area. Or rsync the image in.
> Are you in  a situation where the system being used is low on local disk space?

No, I don't have a problem with disk space. But if /java is on local 
disks already (like in my case), copying it over just doesn't make any 
sense.


>> I see that ./configure already checks several paths under /usr/java/ and  /usr/lib/jvm/. I would like it to know about the standard /java/ paths as well, and wouldn't require any command-line options if I have a correct boot JDK there.
>>
>> Could we do that?
> 
> Not sure I want to, but let me talk to the rest of the team about this.
> 
>>
>>>> 2. What is the ./build/linux-x86-normal-server-release directory, and why is it not ./build/linux-i586 ? What does 'normal' stand for? The same question about the 'server' part.
>>>>
>>> The configure allows for many variations on builds, and the basic variation is put into the directory name.
>>> I have been tempted to soft link linux-i586 to linux-x86-normal-server-release or whatever linux-x86-*name is generated
>>> (assuming only one exists), but it gets a little complicated.
>> Well, I'm fine with any directory name. I just want to understand the reason why we have to change it to something other than simple "linux-i586" (at least for default builds).
>>
> 
> Ah, one person's default is another person's custom one, it is hard to point at one configuration and say that's the default
> for everybody, but let me talk to the others on this and see what they think.

David has already explained this, and the name looks reasonable to me.

--
best regards,
Anthony

> 
> -kto
> 
>> --
>> best regards,
>> Anthony
>>
>>
>>
>>>> 3. I get the following error and the build stops:
>>>>
>>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `UnrollHalfToFloat':
>>>>> cmspack.c:(.text+0x1f25): undefined reference to `_cmsHalf2Float'
>>>>> cmspack.c:(.text+0x1f73): undefined reference to `_cmsHalf2Float'
>>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `UnrollHalfTo16':
>>>>> cmspack.c:(.text+0x261d): undefined reference to `_cmsHalf2Float'
>>>>> cmspack.c:(.text+0x26bd): undefined reference to `_cmsHalf2Float'
>>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `PackHalfFromFloat':
>>>>> cmspack.c:(.text+0x36bb): undefined reference to `_cmsFloat2Half'
>>>>> cmspack.c:(.text+0x3710): undefined reference to `_cmsFloat2Half'
>>>>> cmspack.c:(.text+0x37af): undefined reference to `_cmsFloat2Half'
>>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `PackHalfFrom16':
>>>>> cmspack.c:(.text+0x38a8): undefined reference to `_cmsFloat2Half'
>>>>> cmspack.c:(.text+0x3906): undefined reference to `_cmsFloat2Half'
>>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o:cmspack.c:(.text+0x39a7): more undefined references to `_cmsFloat2Half' follow
>>>>> collect2: ld returned 1 exit status
>>>>> gmake[3]: *** [/export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/lib/i386/liblcms.so] Error 1
>>>>> gmake[3]: *** Waiting for unfinished jobs....
>>>>> gmake[3]: Leaving directory `/export/anthony/8-50-full-new-build/jdk/makefiles'
>>>>> gmake[2]: *** [libs-only] Error 2
>>>>> gmake[2]: Leaving directory `/export/anthony/8-50-full-new-build/jdk/makefiles'
>>>>> make[1]: *** [jdk-only] Error 2
>>>>> make[1]: Leaving directory `/export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release'
>>>>> make: *** [all] Error 2
>>>> Is this a known issue with lcms? Note that I've almost exclusively always built JDK w/ closed repos, and this time I'm building OpenJDK repos only. I'll try to clone the closed parts and see if this eliminates the issue #3.
>>> Never seen this problem before.
>>> -kto
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 11/1/2012 10:38 PM, Kelly O'Hair wrote:
>>>>> Pardon the wide email, but this impacts everyone building the OpenJDK jdk8/jdk8 derived forests.
>>>>> Please only reply to the build-infra-dev mailing list, or just me.
>>>>> With some recent integrations from the build-infra project into jdk8/jdk8 repositories, the build-infra team
>>>>> would like to get more exposure of the new builds. These jdk8/jdk8 changes will start showing up in various
>>>>> jdk8 and team forests over the next few weeks. The default is still the old builds, but both builds work in most
>>>>> cases for OpenJDK as far as we know.
>>>>> At a very high level, the intent is that once you get a forest:
>>>>> hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>>>>> cd j8
>>>>> sh ./get_source.sh
>>>>> You should be able to simply configure&&make (the ultimate goal is this simple anyway), e.g.
>>>>>  sh ./configure
>>>>>  make NEWBUILD=true     # The NEWBUILD=true will become the default when we formally switch.
>>>>> Where "make" is GNU make 3.81, and your system has all the requires packages and PATH contains the
>>>>> needed tools. Note that on Windows, MKS unix utilities cannot be used with the new builds, just CYGWIN
>>>>> is recommended at this time.
>>>>> Of course, we know, it's never as easy as a simple configure&&make, and often you will need to pass in
>>>>> configure options.
>>>>> What we would like to know is where a simple configure&&make does not work, and anything people had
>>>>> to do to make it work.
>>>>> I know many of you are quite used to the old builds, so I have a temporary  "bridgeBuild" target
>>>>> people can try that will attempt to map the ALT_* environment variables to an appropriate configure command
>>>>> and then run that configure command and do the build, e.g.
>>>>> make NEWBUILD=true bridgeBuild
>>>>> People willing to do comparisons between the old and new builds could:
>>>>> rm -f -r build
>>>>> time make NEWBUILD=true bridgeBuild
>>>>> rm -f -r build
>>>>> time make NO_DOCS=true     # Old builds do not generate javadocs by default
>>>>> Any observations about speed of the builds would be appreciated, as will any impressions on what you see.
>>>>> At this time, we think this is working pretty well with a few caveats:
>>>>> * GNU make with the new builds is doing much more parallel processing and this can stress out a system
>>>>>   - Use "make JOBS=1" if you suspect a problem, then try adjusting it up slowly.
>>>>> * Partial builds are limited, right now full builds of the entire OpenJDK is the target
>>>>>   - Hotspot can still be built on it's own, but everyone else needs to build hotspot at least once
>>>>> * Paths with multiple names can cause problems, e.g. being on system svc6, and access an exported share
>>>>>   area as /net/svc6/export/foobar  instead of /export/foobar  will cause problems. Use local paths.
>>>>> We know there are still issues and we will be focusing heavily on the critical ones in the next few weeks, but
>>>>> we do need the community to tell us what the critical issues really are.
>>>>> Our number one priority at this time is that everyone that was able to build the old way, should be able to build
>>>>> with the new build-infra makefiles. Please help us verify that.
>>>>> -kto
> 


From anthony.petrov at oracle.com  Tue Nov 13 06:11:31 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 13 Nov 2012 14:11:31 -0000
Subject: New builds from the build-infra team
In-Reply-To: <A6ABECEE-5F9D-4620-AF5F-74686A8549CA@oracle.com>
References: <DCA50F95-9C8E-45BB-86BE-6BE322E1E916@oracle.com>
	<509A6D34.8090507@oracle.com> <509A7AE4.1060805@oracle.com>
	<509A7D7F.60608@oracle.com>
	<D06266B6-A104-4FF1-9262-62477B7FC259@oracle.com>
	<509D1023.7070003@oracle.com>
	<A6ABECEE-5F9D-4620-AF5F-74686A8549CA@oracle.com>
Message-ID: <50A254EF.2040709@oracle.com>

On 11/10/2012 1:14 AM, Kelly O'Hair wrote:
>>> The last time I filed a whole bunch of bugs against warnings in the build, it was a royal pain, like herding cats
>>> to get all the various teams to do anything about it. But at some point we will do another warning hunt fix,
>>> just not sure the build team will be driving it or not.
>> Well, I don't think we should actively drive this effort. But at least just filing the bugs would be a very good thing to do. As we slowly switching to the new build, I think we should just tell people to file bugs against warnings whenever they see them. I guess that after closing dozens of duplicates, the responsible teams will finally fix them.
>>
> 
> Interesting, have everyone file bugs and annoy the teams to fix them.   Not sure I want to advocate that,
> some of these guys might be armed with sharp pens and pencils, I don't want to be attacked. ;^)

Agree! :)


>> And, btw, -Werror would make the issues P1. Just saying. :))
> 
> The goal with javac compilations is to get to -Werror, but with the native C/C++ compilers it is a bit trickier.
> Sometimes fixing C/C++ warnings for gcc will trigger different warning errors from the Windows Visual Studio
> compiler, or the Solaris Studio compilers. Not saying any of them are wrong, they are all different.
> Since the gcc used on each Linux system can be different versions, adding -Werror has been problematic and
> in many cases they had to turn it off to get the build to work.

Interesting. There's not a lot of code that needs to be compiled by both 
VS and gcc/Solaris Studio. But different gcc versions are really a 
problem. I think the warnings in native code are still worth 
investigating. In the worst case we could try to add some #pragma's to 
suppress some of them. But I believe that most of them should be fixable.

--
best regards,
Anthony

> I don't have a better idea on using -Werror with C/C++ compilers when we use so many different ones.
> 
> We do control javac compilations and the version used, and it's the same on all systems, so that one we
> can strive to get -Werror on all javac compile lines.
> 
> -kto
> 
>> --
>> best regards,
>> Anthony
>>
>>> -kto
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 11/7/2012 7:14 PM, Anthony Petrov wrote:
>>>>> Update on issue #3: after cloning the closed repos my build succeeded. Must be an issue related to OPENJDK=true builds only. Still, I'd like to get some comments regarding #1 and #2 below. Thanks in advance.
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>> On 11/7/2012 6:16 PM, Anthony Petrov wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> (please keep me in CC since I'm not subscribed to this list)
>>>>>>
>>>>>> (I'm building on Linux i586)
>>>>>>
>>>>>> 1. Could we add the /java/re/jdk/<version>/promoted/latest/binaries/<platform>/ directories to check for a Boot JDK to ./configure? E.g. /java/re/jdk/7u10/promoted/latest/binaries/linux-i586. I realize that this is almost useless outside of Oracle, but it would be really helpful for internal builds when one has already set up the /java directory structure properly.
>>>>>>
>>>>>> 2. What is the ./build/linux-x86-normal-server-release directory, and why is it not ./build/linux-i586 ? What does 'normal' stand for? The same question about the 'server' part.
>>>>>>
>>>>>> 3. I get the following error and the build stops:
>>>>>>
>>>>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `UnrollHalfToFloat':
>>>>>>> cmspack.c:(.text+0x1f25): undefined reference to `_cmsHalf2Float'
>>>>>>> cmspack.c:(.text+0x1f73): undefined reference to `_cmsHalf2Float'
>>>>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `UnrollHalfTo16':
>>>>>>> cmspack.c:(.text+0x261d): undefined reference to `_cmsHalf2Float'
>>>>>>> cmspack.c:(.text+0x26bd): undefined reference to `_cmsHalf2Float'
>>>>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `PackHalfFromFloat':
>>>>>>> cmspack.c:(.text+0x36bb): undefined reference to `_cmsFloat2Half'
>>>>>>> cmspack.c:(.text+0x3710): undefined reference to `_cmsFloat2Half'
>>>>>>> cmspack.c:(.text+0x37af): undefined reference to `_cmsFloat2Half'
>>>>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o: In function `PackHalfFrom16':
>>>>>>> cmspack.c:(.text+0x38a8): undefined reference to `_cmsFloat2Half'
>>>>>>> cmspack.c:(.text+0x3906): undefined reference to `_cmsFloat2Half'
>>>>>>> /export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/objs/liblcms/cmspack.o:cmspack.c:(.text+0x39a7): more undefined references to `_cmsFloat2Half' follow
>>>>>>> collect2: ld returned 1 exit status
>>>>>>> gmake[3]: *** [/export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release/jdk/lib/i386/liblcms.so] Error 1
>>>>>>> gmake[3]: *** Waiting for unfinished jobs....
>>>>>>> gmake[3]: Leaving directory `/export/anthony/8-50-full-new-build/jdk/makefiles'
>>>>>>> gmake[2]: *** [libs-only] Error 2
>>>>>>> gmake[2]: Leaving directory `/export/anthony/8-50-full-new-build/jdk/makefiles'
>>>>>>> make[1]: *** [jdk-only] Error 2
>>>>>>> make[1]: Leaving directory `/export/anthony/8-50-full-new-build/build/linux-x86-normal-server-release' make: *** [all] Error 2
>>>>>> Is this a known issue with lcms? Note that I've almost exclusively always built JDK w/ closed repos, and this time I'm building OpenJDK repos only. I'll try to clone the closed parts and see if this eliminates the issue #3.
>>>>>>
>>>>>> -- 
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>> On 11/1/2012 10:38 PM, Kelly O'Hair wrote:
>>>>>>> Pardon the wide email, but this impacts everyone building the OpenJDK jdk8/jdk8 derived forests.
>>>>>>>
>>>>>>> Please only reply to the build-infra-dev mailing list, or just me.
>>>>>>>
>>>>>>> With some recent integrations from the build-infra project into jdk8/jdk8 repositories, the build-infra team
>>>>>>> would like to get more exposure of the new builds. These jdk8/jdk8 changes will start showing up in various
>>>>>>> jdk8 and team forests over the next few weeks. The default is still the old builds, but both builds work in most
>>>>>>> cases for OpenJDK as far as we know.
>>>>>>>
>>>>>>> At a very high level, the intent is that once you get a forest:
>>>>>>> hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>>>>>>> cd j8
>>>>>>> sh ./get_source.sh
>>>>>>>
>>>>>>> You should be able to simply configure&&make (the ultimate goal is this simple anyway), e.g.
>>>>>>>  sh ./configure
>>>>>>>  make NEWBUILD=true     # The NEWBUILD=true will become the default when we formally switch.
>>>>>>>
>>>>>>> Where "make" is GNU make 3.81, and your system has all the requires packages and PATH contains the
>>>>>>> needed tools. Note that on Windows, MKS unix utilities cannot be used with the new builds, just CYGWIN
>>>>>>> is recommended at this time.
>>>>>>>
>>>>>>> Of course, we know, it's never as easy as a simple configure&&make, and often you will need to pass in
>>>>>>> configure options.
>>>>>>>
>>>>>>> What we would like to know is where a simple configure&&make does not work, and anything people had
>>>>>>> to do to make it work.
>>>>>>>
>>>>>>> I know many of you are quite used to the old builds, so I have a temporary  "bridgeBuild" target
>>>>>>> people can try that will attempt to map the ALT_* environment variables to an appropriate configure command
>>>>>>> and then run that configure command and do the build, e.g.
>>>>>>>
>>>>>>> make NEWBUILD=true bridgeBuild
>>>>>>>
>>>>>>> People willing to do comparisons between the old and new builds could:
>>>>>>> rm -f -r build
>>>>>>> time make NEWBUILD=true bridgeBuild
>>>>>>> rm -f -r build
>>>>>>> time make NO_DOCS=true     # Old builds do not generate javadocs by default
>>>>>>>
>>>>>>> Any observations about speed of the builds would be appreciated, as will any impressions on what you see.
>>>>>>>
>>>>>>> At this time, we think this is working pretty well with a few caveats:
>>>>>>> * GNU make with the new builds is doing much more parallel processing and this can stress out a system
>>>>>>>   - Use "make JOBS=1" if you suspect a problem, then try adjusting it up slowly.
>>>>>>> * Partial builds are limited, right now full builds of the entire OpenJDK is the target
>>>>>>>   - Hotspot can still be built on it's own, but everyone else needs to build hotspot at least once
>>>>>>> * Paths with multiple names can cause problems, e.g. being on system svc6, and access an exported share
>>>>>>>   area as /net/svc6/export/foobar  instead of /export/foobar  will cause problems. Use local paths.
>>>>>>>
>>>>>>> We know there are still issues and we will be focusing heavily on the critical ones in the next few weeks, but
>>>>>>> we do need the community to tell us what the critical issues really are.
>>>>>>>
>>>>>>> Our number one priority at this time is that everyone that was able to build the old way, should be able to build
>>>>>>> with the new build-infra makefiles. Please help us verify that.
>>>>>>>
>>>>>>> -kto
>>>>>>>
> 


From vincent.x.ryan at oracle.com  Fri Nov  2 08:47:53 2012
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Fri, 02 Nov 2012 15:47:53 -0000
Subject: New builds from the build-infra team
In-Reply-To: <DCA50F95-9C8E-45BB-86BE-6BE322E1E916@oracle.com>
References: <DCA50F95-9C8E-45BB-86BE-6BE322E1E916@oracle.com>
Message-ID: <70C78781-9057-4B6C-9F80-E39F637A9AD5@oracle.com>

I tried this out on the latest Solaris 11 Update 1 (sparc) but the build encountered problems locating libc when
building jdk. (BTW the old build works correctly, just slower)

 :
 :
strerror                            /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
vfprintf                            /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_error.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
fprintf                             /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_init.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
gethrvtime                          /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/objs/libhprof_jvmti/hprof_md.o  (symbol belongs to implicit dependency /lib/sparcv9/libc.so.1)
ld: fatal: symbol referencing errors. No output written to /export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so
gmake[3]: *** [/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release/jdk/lib/sparcv9/libhprof.so] Error 1
gmake[3]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
gmake[2]: *** [libs-only] Error 2
gmake[2]: Leaving directory `/export/home/vinryan/jdk8-master/jdk/makefiles'
make[1]: *** [jdk-only] Error 2
make[1]: Leaving directory `/export/home/vinryan/jdk8-master/build/solaris-sparcv9-normal-server-release'
make: *** [all] Error 2
t4%




FYI I've attached the config script that was generated by configure.sh.

-------------- next part --------------



On 1 Nov 2012, at 18:38, Kelly O'Hair wrote:

> 
> Pardon the wide email, but this impacts everyone building the OpenJDK jdk8/jdk8 derived forests.
> 
> Please only reply to the build-infra-dev mailing list, or just me.
> 
> With some recent integrations from the build-infra project into jdk8/jdk8 repositories, the build-infra team
> would like to get more exposure of the new builds. These jdk8/jdk8 changes will start showing up in various
> jdk8 and team forests over the next few weeks. The default is still the old builds, but both builds work in most
> cases for OpenJDK as far as we know.
> 
> At a very high level, the intent is that once you get a forest:
>  hg clone http://hg.openjdk.java.net/jdk8/jdk8    j8
>  cd j8
>  sh ./get_source.sh
> 
> You should be able to simply configure&&make (the ultimate goal is this simple anyway), e.g.
>   sh ./configure
>   make NEWBUILD=true     # The NEWBUILD=true will become the default when we formally switch.
> 
> Where "make" is GNU make 3.81, and your system has all the requires packages and PATH contains the
> needed tools. Note that on Windows, MKS unix utilities cannot be used with the new builds, just CYGWIN
> is recommended at this time.
> 
> Of course, we know, it's never as easy as a simple configure&&make, and often you will need to pass in
> configure options.
> 
> What we would like to know is where a simple configure&&make does not work, and anything people had
> to do to make it work.
> 
> I know many of you are quite used to the old builds, so I have a temporary  "bridgeBuild" target
> people can try that will attempt to map the ALT_* environment variables to an appropriate configure command
> and then run that configure command and do the build, e.g.
> 
>  make NEWBUILD=true bridgeBuild
> 
> People willing to do comparisons between the old and new builds could:
>  rm -f -r build
>  time make NEWBUILD=true bridgeBuild
>  rm -f -r build
>  time make NO_DOCS=true     # Old builds do not generate javadocs by default
> 
> Any observations about speed of the builds would be appreciated, as will any impressions on what you see.
> 
> At this time, we think this is working pretty well with a few caveats:
>  * GNU make with the new builds is doing much more parallel processing and this can stress out a system
>    - Use "make JOBS=1" if you suspect a problem, then try adjusting it up slowly.
>  * Partial builds are limited, right now full builds of the entire OpenJDK is the target
>    - Hotspot can still be built on it's own, but everyone else needs to build hotspot at least once
>  * Paths with multiple names can cause problems, e.g. being on system svc6, and access an exported share
>    area as /net/svc6/export/foobar  instead of /export/foobar  will cause problems. Use local paths.
> 
> We know there are still issues and we will be focusing heavily on the critical ones in the next few weeks, but
> we do need the community to tell us what the critical issues really are.
> 
> Our number one priority at this time is that everyone that was able to build the old way, should be able to build
> with the new build-infra makefiles. Please help us verify that.
> 
> -kto
>