From goetz.lindenmaier at sap.com Mon Jul 2 01:08:47 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 2 Jul 2012 10:08:47 +0200 Subject: AIX Changes In-Reply-To: References: <123B6025-4F07-4B88-82CD-DDABEB2FBB24@linux.vnet.ibm.com> Message-ID: <140FA3E3585AD840A3316D2853F974DC096F5472E6@DEWDFECCR03.wdf.sap.corp> Hi Steve, sorry, I can't help you with that. Freetype is only used in OpenJDK, therefore we did not port it. We use code that is not available in the open, so we may not share it. Sorry for that, Goetz. -----Original Message----- From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Steve Poole Sent: Samstag, 30. Juni 2012 10:47 To: ppc-aix-port-dev at openjdk.java.net Subject: Re: AIX Changes Hi Goetz, As we discussed via the phone yesterday I started to do a sanity build with this patch applied. One thing I've found already is that the freetypecheck fails to build as its makefile is not AIX aware and tries to use -rpath. Your patch correctly fixes the same sort of problem in Program.gmk so I assume that either you missed make/tools/freetypecheck/Makefile or you have another sort of work-around? On 28 Jun 2012, at 11:00, Steve Poole wrote: > > Hi guys - we've taken a look at Goetz's AIX changes and we would really like them to be committed. I think it would be best if someone for SAP did that :-) > > Attempting to reconcile the different approaches between the IBM and the SAP code bases in a piecemeal manner just means it will take a long time before we have a working codebase - which is somewhat mad given you already have one. > > If you're happy with doing a bulk commit , then, once the changes are in the codebase, we can work through any remaining IBM changes we think are needed and offer them up. > > What do you think? > > > Cheers > > Steve From spoole at linux.vnet.ibm.com Mon Jul 2 01:23:04 2012 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Mon, 2 Jul 2012 09:23:04 +0100 Subject: AIX Changes In-Reply-To: <140FA3E3585AD840A3316D2853F974DC096F5472E6@DEWDFECCR03.wdf.sap.corp> References: <123B6025-4F07-4B88-82CD-DDABEB2FBB24@linux.vnet.ibm.com> <140FA3E3585AD840A3316D2853F974DC096F5472E6@DEWDFECCR03.wdf.sap.corp> Message-ID: <0B3B2F10-3C70-4DDD-B68F-7176E744BB9F@linux.vnet.ibm.com> On 2 Jul 2012, at 09:08, Lindenmaier, Goetz wrote: > Hi Steve, > > sorry, I can't help you with that. Freetype is only used in OpenJDK, therefore > we did not port it. We use code that is not available in the open, so we may > not share it. > Ok that's fine. Next question.. How do I build Hotspot on AIX? I used the instructions in the PPC guide in the root of the repo - specifically HOTSPOT_TARGET=all_debugcore CC_INTERP=true OPENJDK=true CORE_BUILD=true but I'm getting a build failure of: make[6]: *** No rule to make target `/home/spoole/hudson/workspace/sp.ppcaix.jdk7u.aix.ppc64/work/hotspot/make/aix/makefiles/tiered.make.o', needed by `/home/spoole/hudson/workspace/sp.ppcaix.jdk7u.aix.ppc64/work/hotspot/make/aix/makefiles/tiered.make'. Stop. Does that problem sound familiar? > Sorry for that, > Goetz. > > -----Original Message----- > From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Steve Poole > Sent: Samstag, 30. Juni 2012 10:47 > To: ppc-aix-port-dev at openjdk.java.net > Subject: Re: AIX Changes > > Hi Goetz, > > As we discussed via the phone yesterday I started to do a sanity build with this patch applied. > > One thing I've found already is that the freetypecheck fails to build as its makefile is not AIX aware and tries to use -rpath. > Your patch correctly fixes the same sort of problem in Program.gmk so I assume that either you missed make/tools/freetypecheck/Makefile or you have another sort of work-around? > > > > > On 28 Jun 2012, at 11:00, Steve Poole wrote: > >> >> Hi guys - we've taken a look at Goetz's AIX changes and we would really like them to be committed. I think it would be best if someone for SAP did that :-) >> >> Attempting to reconcile the different approaches between the IBM and the SAP code bases in a piecemeal manner just means it will take a long time before we have a working codebase - which is somewhat mad given you already have one. >> >> If you're happy with doing a bulk commit , then, once the changes are in the codebase, we can work through any remaining IBM changes we think are needed and offer them up. >> >> What do you think? >> >> >> Cheers >> >> Steve > From goetz.lindenmaier at sap.com Mon Jul 2 03:08:28 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 2 Jul 2012 12:08:28 +0200 Subject: AIX Changes In-Reply-To: <0B3B2F10-3C70-4DDD-B68F-7176E744BB9F@linux.vnet.ibm.com> References: <123B6025-4F07-4B88-82CD-DDABEB2FBB24@linux.vnet.ibm.com> <140FA3E3585AD840A3316D2853F974DC096F5472E6@DEWDFECCR03.wdf.sap.corp> <0B3B2F10-3C70-4DDD-B68F-7176E744BB9F@linux.vnet.ibm.com> Message-ID: <140FA3E3585AD840A3316D2853F974DC096F8D6B0A@DEWDFECCR03.wdf.sap.corp> Hi Steve, tiered.make is a makefile needed to build the jit compiler. As you set all_debugcore and CORE_BUILD=true, the jit compiler should not be built. So I assume, these flags did not make their way to the hotspot build. Have a look at the build log Volker published: http://cr.openjdk.java.net/~simonis/ppc-aix-port/build-logs/output_ppc-aix-port_dbg.log It says "Entering hotspot for target(s) all_debugcore" at some point. Can you see that in your build log? Else the flag is not properly passed to the hotspot build. I am building hotspot on aix by going to .../hotspot/make and calling make ALT_BOOTDIR=/sapmnt/depot/tools/gen/rs6000_64/licenseware/jse/1.6.0 ALT_OUTPUTDIR=/usr/work/d045726/oJ/builds_aix-hotspot/build-is3036-asm ARCH_DATA_MODEL=64 HOTSPOT_BUILD_JOBS=8 VERBOSE=true CC_INTERP=true OPENJDK=true CORE_BUILD=true all_debugcore so I'm sure that is working. Unfortunately, we can't easily make the full build on aix ... Volker is trying. Maybe you can mail me a build log? I'll also have a further look at the makefiles. Cheers, Goetz. -----Original Message----- From: Steve Poole [mailto:spoole at linux.vnet.ibm.com] Sent: Montag, 2. Juli 2012 10:23 To: Lindenmaier, Goetz Cc: ppc-aix-port-dev at openjdk.java.net Subject: Re: AIX Changes On 2 Jul 2012, at 09:08, Lindenmaier, Goetz wrote: > Hi Steve, > > sorry, I can't help you with that. Freetype is only used in OpenJDK, therefore > we did not port it. We use code that is not available in the open, so we may > not share it. > Ok that's fine. Next question.. How do I build Hotspot on AIX? I used the instructions in the PPC guide in the root of the repo - specifically HOTSPOT_TARGET=all_debugcore CC_INTERP=true OPENJDK=true CORE_BUILD=true but I'm getting a build failure of: make[6]: *** No rule to make target `/home/spoole/hudson/workspace/sp.ppcaix.jdk7u.aix.ppc64/work/hotspot/make/aix/makefiles/tiered.make.o', needed by `/home/spoole/hudson/workspace/sp.ppcaix.jdk7u.aix.ppc64/work/hotspot/make/aix/makefiles/tiered.make'. Stop. Does that problem sound familiar? > Sorry for that, > Goetz. > > -----Original Message----- > From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Steve Poole > Sent: Samstag, 30. Juni 2012 10:47 > To: ppc-aix-port-dev at openjdk.java.net > Subject: Re: AIX Changes > > Hi Goetz, > > As we discussed via the phone yesterday I started to do a sanity build with this patch applied. > > One thing I've found already is that the freetypecheck fails to build as its makefile is not AIX aware and tries to use -rpath. > Your patch correctly fixes the same sort of problem in Program.gmk so I assume that either you missed make/tools/freetypecheck/Makefile or you have another sort of work-around? > > > > > On 28 Jun 2012, at 11:00, Steve Poole wrote: > >> >> Hi guys - we've taken a look at Goetz's AIX changes and we would really like them to be committed. I think it would be best if someone for SAP did that :-) >> >> Attempting to reconcile the different approaches between the IBM and the SAP code bases in a piecemeal manner just means it will take a long time before we have a working codebase - which is somewhat mad given you already have one. >> >> If you're happy with doing a bulk commit , then, once the changes are in the codebase, we can work through any remaining IBM changes we think are needed and offer them up. >> >> What do you think? >> >> >> Cheers >> >> Steve > From spoole at linux.vnet.ibm.com Mon Jul 2 05:08:45 2012 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Mon, 2 Jul 2012 13:08:45 +0100 Subject: AIX Changes In-Reply-To: <140FA3E3585AD840A3316D2853F974DC096F8D6B0A@DEWDFECCR03.wdf.sap.corp> References: <123B6025-4F07-4B88-82CD-DDABEB2FBB24@linux.vnet.ibm.com> <140FA3E3585AD840A3316D2853F974DC096F5472E6@DEWDFECCR03.wdf.sap.corp> <0B3B2F10-3C70-4DDD-B68F-7176E744BB9F@linux.vnet.ibm.com> <140FA3E3585AD840A3316D2853F974DC096F8D6B0A@DEWDFECCR03.wdf.sap.corp> Message-ID: <552E8C00-D384-4E97-91E9-0702C95B025B@linux.vnet.ibm.com> I'm doing a full build too - so looks like you're actually hitting similar problems. I'm going to get the class libs building first (setting BUILD_HOTSPOT=false) and let Volker sort out how to get hotspot building as part a full build! On 2 Jul 2012, at 11:08, Lindenmaier, Goetz wrote: > Hi Steve, > > tiered.make is a makefile needed to build the jit compiler. As you set all_debugcore and > CORE_BUILD=true, the jit compiler should not be built. So I assume, these flags did not > make their way to the hotspot build. > Have a look at the build log Volker published: > http://cr.openjdk.java.net/~simonis/ppc-aix-port/build-logs/output_ppc-aix-port_dbg.log > > It says "Entering hotspot for target(s) all_debugcore" at some point. Can you see that in > your build log? Else the flag is not properly passed to the hotspot build. > > I am building hotspot on aix by going to .../hotspot/make and calling > make ALT_BOOTDIR=/sapmnt/depot/tools/gen/rs6000_64/licenseware/jse/1.6.0 ALT_OUTPUTDIR=/usr/work/d045726/oJ/builds_aix-hotspot/build-is3036-asm ARCH_DATA_MODEL=64 HOTSPOT_BUILD_JOBS=8 VERBOSE=true CC_INTERP=true OPENJDK=true CORE_BUILD=true all_debugcore > so I'm sure that is working. > > Unfortunately, we can't easily make the full build on aix ... Volker is trying. > Maybe you can mail me a build log? > I'll also have a further look at the makefiles. > > Cheers, > Goetz. > > > -----Original Message----- > From: Steve Poole [mailto:spoole at linux.vnet.ibm.com] > Sent: Montag, 2. Juli 2012 10:23 > To: Lindenmaier, Goetz > Cc: ppc-aix-port-dev at openjdk.java.net > Subject: Re: AIX Changes > > > > On 2 Jul 2012, at 09:08, Lindenmaier, Goetz wrote: > >> Hi Steve, >> >> sorry, I can't help you with that. Freetype is only used in OpenJDK, therefore >> we did not port it. We use code that is not available in the open, so we may >> not share it. >> > Ok that's fine. Next question.. > > How do I build Hotspot on AIX? I used the instructions in the PPC guide in the root of the repo - specifically > > > HOTSPOT_TARGET=all_debugcore > CC_INTERP=true > OPENJDK=true > CORE_BUILD=true > > but I'm getting a build failure of: > > make[6]: *** No rule to make target `/home/spoole/hudson/workspace/sp.ppcaix.jdk7u.aix.ppc64/work/hotspot/make/aix/makefiles/tiered.make.o', needed by `/home/spoole/hudson/workspace/sp.ppcaix.jdk7u.aix.ppc64/work/hotspot/make/aix/makefiles/tiered.make'. Stop. > > Does that problem sound familiar? > > >> Sorry for that, >> Goetz. >> >> -----Original Message----- >> From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Steve Poole >> Sent: Samstag, 30. Juni 2012 10:47 >> To: ppc-aix-port-dev at openjdk.java.net >> Subject: Re: AIX Changes >> >> Hi Goetz, >> >> As we discussed via the phone yesterday I started to do a sanity build with this patch applied. >> >> One thing I've found already is that the freetypecheck fails to build as its makefile is not AIX aware and tries to use -rpath. >> Your patch correctly fixes the same sort of problem in Program.gmk so I assume that either you missed make/tools/freetypecheck/Makefile or you have another sort of work-around? >> >> >> >> >> On 28 Jun 2012, at 11:00, Steve Poole wrote: >> >>> >>> Hi guys - we've taken a look at Goetz's AIX changes and we would really like them to be committed. I think it would be best if someone for SAP did that :-) >>> >>> Attempting to reconcile the different approaches between the IBM and the SAP code bases in a piecemeal manner just means it will take a long time before we have a working codebase - which is somewhat mad given you already have one. >>> >>> If you're happy with doing a bulk commit , then, once the changes are in the codebase, we can work through any remaining IBM changes we think are needed and offer them up. >>> >>> What do you think? >>> >>> >>> Cheers >>> >>> Steve >> > From spoole at linux.vnet.ibm.com Mon Jul 2 08:36:53 2012 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Mon, 2 Jul 2012 16:36:53 +0100 Subject: AIX Changes In-Reply-To: <552E8C00-D384-4E97-91E9-0702C95B025B@linux.vnet.ibm.com> References: <123B6025-4F07-4B88-82CD-DDABEB2FBB24@linux.vnet.ibm.com> <140FA3E3585AD840A3316D2853F974DC096F5472E6@DEWDFECCR03.wdf.sap.corp> <0B3B2F10-3C70-4DDD-B68F-7176E744BB9F@linux.vnet.ibm.com> <140FA3E3585AD840A3316D2853F974DC096F8D6B0A@DEWDFECCR03.wdf.sap.corp> <552E8C00-D384-4E97-91E9-0702C95B025B@linux.vnet.ibm.com> Message-ID: <32550005-88B9-4154-8C3A-C903899EB378@linux.vnet.ibm.com> Update: Unfortunately I've quickly hit two java compilation problems with the big patch so far. One is a missing brace in src/share/classes/java/security/AccessControlContext.java. The other is , probably , to do with missing changes in src/share/classes/sun/net/www/http/HttpClient.java that gives me the following ../../../src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java:1772: error: failedOnce is not public in HttpClient; cannot be accessed from outside package http.failedOnce = this.failedOnce; Neither of the changes that caused these problems seem to be related to the basics of getting an AIX build going. So I'm going to start again. This time I will take the IBM changes and feed them in one by one and use the big patch as a reference to see what SAP did in the same circumstances. Hopefully I can get a basic AIX build running fairly quickly. On 2 Jul 2012, at 13:08, Steve Poole wrote: > I'm doing a full build too - so looks like you're actually hitting similar problems. > > I'm going to get the class libs building first (setting BUILD_HOTSPOT=false) and let Volker sort out how to get hotspot building as part a full build! > > > On 2 Jul 2012, at 11:08, Lindenmaier, Goetz wrote: > >> Hi Steve, >> >> tiered.make is a makefile needed to build the jit compiler. As you set all_debugcore and >> CORE_BUILD=true, the jit compiler should not be built. So I assume, these flags did not >> make their way to the hotspot build. >> Have a look at the build log Volker published: >> http://cr.openjdk.java.net/~simonis/ppc-aix-port/build-logs/output_ppc-aix-port_dbg.log >> >> It says "Entering hotspot for target(s) all_debugcore" at some point. Can you see that in >> your build log? Else the flag is not properly passed to the hotspot build. >> >> I am building hotspot on aix by going to .../hotspot/make and calling >> make ALT_BOOTDIR=/sapmnt/depot/tools/gen/rs6000_64/licenseware/jse/1.6.0 ALT_OUTPUTDIR=/usr/work/d045726/oJ/builds_aix-hotspot/build-is3036-asm ARCH_DATA_MODEL=64 HOTSPOT_BUILD_JOBS=8 VERBOSE=true CC_INTERP=true OPENJDK=true CORE_BUILD=true all_debugcore >> so I'm sure that is working. >> >> Unfortunately, we can't easily make the full build on aix ... Volker is trying. >> Maybe you can mail me a build log? >> I'll also have a further look at the makefiles. >> >> Cheers, >> Goetz. >> >> >> -----Original Message----- >> From: Steve Poole [mailto:spoole at linux.vnet.ibm.com] >> Sent: Montag, 2. Juli 2012 10:23 >> To: Lindenmaier, Goetz >> Cc: ppc-aix-port-dev at openjdk.java.net >> Subject: Re: AIX Changes >> >> >> >> On 2 Jul 2012, at 09:08, Lindenmaier, Goetz wrote: >> >>> Hi Steve, >>> >>> sorry, I can't help you with that. Freetype is only used in OpenJDK, therefore >>> we did not port it. We use code that is not available in the open, so we may >>> not share it. >>> >> Ok that's fine. Next question.. >> >> How do I build Hotspot on AIX? I used the instructions in the PPC guide in the root of the repo - specifically >> >> >> HOTSPOT_TARGET=all_debugcore >> CC_INTERP=true >> OPENJDK=true >> CORE_BUILD=true >> >> but I'm getting a build failure of: >> >> make[6]: *** No rule to make target `/home/spoole/hudson/workspace/sp.ppcaix.jdk7u.aix.ppc64/work/hotspot/make/aix/makefiles/tiered.make.o', needed by `/home/spoole/hudson/workspace/sp.ppcaix.jdk7u.aix.ppc64/work/hotspot/make/aix/makefiles/tiered.make'. Stop. >> >> Does that problem sound familiar? >> >> >>> Sorry for that, >>> Goetz. >>> >>> -----Original Message----- >>> From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Steve Poole >>> Sent: Samstag, 30. Juni 2012 10:47 >>> To: ppc-aix-port-dev at openjdk.java.net >>> Subject: Re: AIX Changes >>> >>> Hi Goetz, >>> >>> As we discussed via the phone yesterday I started to do a sanity build with this patch applied. >>> >>> One thing I've found already is that the freetypecheck fails to build as its makefile is not AIX aware and tries to use -rpath. >>> Your patch correctly fixes the same sort of problem in Program.gmk so I assume that either you missed make/tools/freetypecheck/Makefile or you have another sort of work-around? >>> >>> >>> >>> >>> On 28 Jun 2012, at 11:00, Steve Poole wrote: >>> >>>> >>>> Hi guys - we've taken a look at Goetz's AIX changes and we would really like them to be committed. I think it would be best if someone for SAP did that :-) >>>> >>>> Attempting to reconcile the different approaches between the IBM and the SAP code bases in a piecemeal manner just means it will take a long time before we have a working codebase - which is somewhat mad given you already have one. >>>> >>>> If you're happy with doing a bulk commit , then, once the changes are in the codebase, we can work through any remaining IBM changes we think are needed and offer them up. >>>> >>>> What do you think? >>>> >>>> >>>> Cheers >>>> >>>> Steve >>> >> > From goetz.lindenmaier at sap.com Tue Jul 3 01:45:16 2012 From: goetz.lindenmaier at sap.com (goetz.lindenmaier at sap.com) Date: Tue, 03 Jul 2012 08:45:16 +0000 Subject: hg: ppc-aix-port/jdk7u/hotspot: 2 new changesets Message-ID: <20120703084523.6C55F47C66@hg.openjdk.java.net> Changeset: 80b9e64868a1 Author: Goetz Lindenmaier Date: 2012-07-02 13:00 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/80b9e64868a1 PPC specific flags: add macro PD_FLAGS to global flag definitions. We need a row of PPC only flags. This new macro allows to define flags in globals_.hpp without defining them in globals.hpp, so they will not be compiled into VMs on other platforms. Can be used on any other platform, too. ! src/cpu/ppc/vm/globals_ppc.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp Changeset: d4feae2ae9ce Author: Goetz Lindenmaier Date: 2012-07-02 13:02 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/d4feae2ae9ce PPC assembler and register definitions. ! src/cpu/ppc/vm/assembler_ppc.cpp ! src/cpu/ppc/vm/assembler_ppc.hpp ! src/cpu/ppc/vm/assembler_ppc.inline.hpp ! src/cpu/ppc/vm/register_definitions_ppc.cpp ! src/cpu/ppc/vm/register_ppc.hpp From luchsh at linux.vnet.ibm.com Thu Jul 5 01:24:21 2012 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Thu, 05 Jul 2012 16:24:21 +0800 Subject: Build error on Linux PPC64 platform Message-ID: <4FF54F35.7010204@linux.vnet.ibm.com> Hello Volker, I met following problem when trying to build on my Power 5 box, OS is RedHat Enterprise Linux 5, bootstrapping JDK is also IBMSDK 7. /root/ppc-aix-port/depends/sdk7/bin/java -cp /root/ppc-aix-port/depends/sdk7/lib/tools.jar sun.rmi.rmic.Main -classpath "/root/ppc-aix-port/output_ppc-aix-port_dbg/../output_ppc-aix-port_dbg-debug/classes" \ -d /root/ppc-aix-port/output_ppc-aix-port_dbg/../output_ppc-aix-port_dbg-debug/classes \ -iiop -v1.2 \ -standardPackage \ javax.management.remote.rmi.RMIConnectionImpl -standardPackage is an invalid option or argument. The "-standardPackage" option does not seem to be supported, but I found this command passed in your build log, have you got any other changes to make this pass? Many thanks! Jonathan From volker.simonis at gmail.com Thu Jul 5 02:59:48 2012 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 5 Jul 2012 11:59:48 +0200 Subject: Build error on Linux PPC64 platform In-Reply-To: <4FF54F35.7010204@linux.vnet.ibm.com> References: <4FF54F35.7010204@linux.vnet.ibm.com> Message-ID: Hi Jonathan, that's strange. We speciall set the 'rmic' compiler to RMIC='$(ALT_BOOTDIR)/bin/java -cp $(ALT_BOOTDIR)/lib/tools.jar sun.rmi.rmic.Main' in order to use the original, Oracle version of the compiler which should understand this option. Could you try the following on the command line (with your JDK version): /sapmnt/depot/tools/gen/linuxppc64/licenseware/jse/1.7.0/bin/java -showversion -cp /sapmnt/depot/tools/gen/linuxppc64/licenseware/jse/1.7.0/lib/tools.jar sun.rmi.rmic.Main -d /tmp/rmic_output/ -iiop -v1.2 -standardPackage -verbose javax.management.remote.rmi.RMIConnectionImpl java version "1.7.0" Java(TM) SE Runtime Environment (build pxp6470-20110827_01) IBM J9 VM (build 2.6, JRE 1.7.0 Linux ppc64-64 20110810_88604 (JIT enabled, AOT enabled) J9VM - R26_Java726_GA_20110810_1208_B88592 JIT - r11_20110810_20466 GC - R26_Java726_GA_20110810_1208_B88592 J9CL - 20110810_88604) JCL - 20110809_01 based on Oracle 7b147 [loaded /net/sapmnt.depot/tools/gen/linuxppc64/licenseware/jse/1.7.0/jre/lib/rt.jar(javax/management/remote/rmi/RMIConnectionImpl.class) in 134 ms] [loaded /net/sapmnt.depot/tools/gen/linuxppc64/licenseware/jse/1.7.0/jre/lib/rt.jar(javax/management/remote/rmi/RMIConnection.class) in 60 ms] [loaded /net/sapmnt.depot/tools/gen/linuxppc64/licenseware/jse/1.7.0/jre/lib/rt.jar(java/io/Closeable.class) in 0 ms] [loaded /net/sapmnt.depot/tools/gen/linuxppc64/licenseware/jse/1.7.0/jre/lib/rt.jar(java/lang/AutoCloseable.class) in 0 ms] ... [wrote /tmp/rmic_output/javax/management/remote/rmi/RMIConnectionImpl_Stub.class] [done in 26763 ms] Perhaps you have another version of IBMSDK and/or tools.jar? By the way, while analysing your problem I just realized that our current solution to set RMIC='$(ALT_BOOTDIR)/bin/java -cp $(ALT_BOOTDIR)/lib/tools.jar sun.rmi.rmic.Main' isn't perfect, because as you can see in the above output, not only 'sun.rmi.rmic.Main' is resolved from 'tools.jar' but also the class 'javax.management.remote.rmi.RMIConnectionImpl' for which we we want to create the RMI interfaces. But this class should be resolved from the newly build JDK instead. I first thought I'll have to fix it but on the other hand the problem will disappear once we can bootstrap with our VM. Regards, Volker On Thu, Jul 5, 2012 at 10:24 AM, Jonathan Lu wrote: > Hello Volker, > > I met following problem when trying to build on my Power 5 box, > OS is RedHat Enterprise Linux 5, bootstrapping JDK is also IBMSDK 7. > > /root/ppc-aix-port/depends/sdk7/bin/java -cp > /root/ppc-aix-port/depends/sdk7/lib/tools.jar sun.rmi.rmic.Main -classpath > "/root/ppc-aix-port/output_ppc-aix-port_dbg/../output_ppc-aix-port_dbg-debug/classes" > \ > -d > /root/ppc-aix-port/output_ppc-aix-port_dbg/../output_ppc-aix-port_dbg-debug/classes > \ > -iiop -v1.2 \ > -standardPackage \ > javax.management.remote.rmi.RMIConnectionImpl > -standardPackage is an invalid option or argument. > > The "-standardPackage" option does not seem to be supported, but I found > this command passed in your build log, have you got any other changes to > make this pass? > > Many thanks! > Jonathan > From neil.richards at ngmr.net Thu Jul 5 05:43:14 2012 From: neil.richards at ngmr.net (Neil Richards) Date: Thu, 05 Jul 2012 13:43:14 +0100 Subject: Build error on Linux PPC64 platform In-Reply-To: References: <4FF54F35.7010204@linux.vnet.ibm.com> Message-ID: <1341492194.22277.152.camel@chalkhill> On Thu, 2012-07-05 at 11:59 +0200, Volker Simonis wrote: > Hi Jonathan, > > that's strange. We speciall set the 'rmic' compiler to > > RMIC='$(ALT_BOOTDIR)/bin/java -cp $(ALT_BOOTDIR)/lib/tools.jar > sun.rmi.rmic.Main' > > in order to use the original, Oracle version of the compiler which > should understand this option. I fear that this is not altogether sufficient to avoid using IBM's version of the rmic compiler for IIOP-related artifact generation. rmic is the command for producing both Java Remote Method Protocol (JRMP) and Internet Inter-ORB Protocol (IIOP) artifacts. (Associated with IIOP generation, it also can produce IDL code and a "Mangled Name Table"). Each of these types of generation is done by a separate "back-end" to rmic. The back-end implementation for each generator can be specified (usually by an SDK provider) using the properties file 'sun/rmi/rmic/resources/rmicext.properties' (and its associated locale-specific variants). (These properties settings are picked up by the common rmic front-end, using a call to ResourceBundle.getBundle().) These properties files (if they exist) tend to be held within a jar file, alongside the code for the backend implementations. In an IBM SDK, that code, as so that properties file, is held in lib/ibmorbtools.jar. (The IBM SDK's lib/tools.jar has a 'Class-Path:' entry in it, which chains onto ibmorbtools.jar). So, in all cases, the rmic command invocation calls sun.rmi.rmic.Main, but the settings in the rmicext.properties file controls what backend code gets used. (Note: This is different to the way the idlj command works, for example, where there is no common front-end). Hope this helps to explain why the current approach is not having the desired effect. Regards, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From volker.simonis at gmail.com Thu Jul 5 08:07:24 2012 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 5 Jul 2012 17:07:24 +0200 Subject: Build error on Linux PPC64 platform In-Reply-To: <1341492194.22277.152.camel@chalkhill> References: <4FF54F35.7010204@linux.vnet.ibm.com> <1341492194.22277.152.camel@chalkhill> Message-ID: Hi Neil, thanks again for the detailed explanation. But it's still strange, why the same 'rmic' invocation succeeds on my machine but not on Jonathan's. As posted I use the following IBM JDK: java version "1.7.0" Java(TM) SE Runtime Environment (build pxp6470-20110827_01) IBM J9 VM (build 2.6, JRE 1.7.0 Linux ppc64-64 20110810_88604 (JIT enabled, AOT enabled) J9VM - R26_Java726_GA_20110810_1208_B88592 JIT - r11_20110810_20466 GC - R26_Java726_GA_20110810_1208_B88592 J9CL - 20110810_88604) JCL - 20110809_01 based on Oracle 7b147 I checked "rmicext.properties" from ibmorbtools.jar. It has the followng entries: generator.args=v1.1,vcompat,v1.2,iiop,idl,xprint,mnt generator.class.default=sun.rmi.rmic.RMIGenerator generator.class.v1.1=sun.rmi.rmic.RMIGenerator generator.class.vcompat=sun.rmi.rmic.RMIGenerator generator.class.v1.2=sun.rmi.rmic.RMIGenerator generator.class.iiop=com.ibm.tools.rmic.iiop.StubGenerator generator.class.idl=com.ibm.tools.rmic.iiop.IDLGenerator generator.class.xprint=com.ibm.tools.rmic.iiop.PrintGenerator generator.class.mnt=com.ibm.tools.rmic.iiop.MangledNameTableGenerator So according to your explanation, Jonathan should get the same results for running "/bin/java -cp /lib/tools.jar sun.rmi.rmic.Main -d /tmp/rmic_output/ -iiop -v1.2 -standardPackage javax.management.remote.rmi.RMIConnectionImpl" as I did. Or is there something else which can influence the choice of the generator class. As far as I can see, the only place in Oracle's JDK which parses the "-standardPackage" option is in sun.rmi.rmic.iiop.StubGenerator (http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/file/tip/src/share/classes/sun/rmi/rmic/iiop/StubGenerator.java) but according to your explanation, my IBM JDK should choose "generator.class.iiop=com.ibm.tools.rmic.iiop.StubGenerator" in that case. However if I do: /bin/java -showversion -verbose:class -cp /lib/tools.jar sun.rmi.rmic.Main -d /tmp/rmic_output/ -iiop -v1.2 -standardPackage javax.management.remote.rmi.RMIConnectionImpl 2>&1 | grep iiop.StubGenerator class load: sun.rmi.rmic.iiop.StubGenerator from: file:/net/sapmnt.depot/tools/gen/linuxppc64/licenseware/jse/1.7.0/lib/tools.jar I can see that it uses sun.rmi.rmic.iiop.StubGenerator instead. So there must some other configuration magic (at least on my machine). @Jonathan: could you please try the above command to check which version of StubGenerator you get. Regards, Volker On Thu, Jul 5, 2012 at 2:43 PM, Neil Richards wrote: > On Thu, 2012-07-05 at 11:59 +0200, Volker Simonis wrote: >> Hi Jonathan, >> >> that's strange. We speciall set the 'rmic' compiler to >> >> RMIC='$(ALT_BOOTDIR)/bin/java -cp $(ALT_BOOTDIR)/lib/tools.jar >> sun.rmi.rmic.Main' >> >> in order to use the original, Oracle version of the compiler which >> should understand this option. > > I fear that this is not altogether sufficient to avoid using IBM's > version of the rmic compiler for IIOP-related artifact generation. > > rmic is the command for producing both Java Remote Method Protocol > (JRMP) and Internet Inter-ORB Protocol (IIOP) artifacts. > (Associated with IIOP generation, it also can produce IDL code and a > "Mangled Name Table"). > > Each of these types of generation is done by a separate "back-end" to > rmic. > > The back-end implementation for each generator can be specified (usually > by an SDK provider) using the properties file > 'sun/rmi/rmic/resources/rmicext.properties' (and its associated > locale-specific variants). > > (These properties settings are picked up by the common rmic front-end, > using a call to ResourceBundle.getBundle().) > > These properties files (if they exist) tend to be held within a jar > file, alongside the code for the backend implementations. > > In an IBM SDK, that code, as so that properties file, is held in > lib/ibmorbtools.jar. > (The IBM SDK's lib/tools.jar has a 'Class-Path:' entry in it, which > chains onto ibmorbtools.jar). > > So, in all cases, the rmic command invocation calls sun.rmi.rmic.Main, > but the settings in the rmicext.properties file controls what backend > code gets used. > > (Note: This is different to the way the idlj command works, for example, > where there is no common front-end). > > Hope this helps to explain why the current approach is not having the > desired effect. > > Regards, > Neil > > -- > Unless stated above: > IBM email: neil_richards at uk.ibm.com > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From luchsh at linux.vnet.ibm.com Fri Jul 6 01:09:03 2012 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Fri, 06 Jul 2012 16:09:03 +0800 Subject: Build error on Linux PPC64 platform In-Reply-To: References: <4FF54F35.7010204@linux.vnet.ibm.com> <1341492194.22277.152.camel@chalkhill> Message-ID: <4FF69D1F.8040105@linux.vnet.ibm.com> Hello Volker, The command "/bin/java -cp /lib/tools.jar sun.rmi.rmic.Main -d /tmp/rmic_output/ -iiop -v1.2 -standardPackage javax.management.remote.rmi.RMIConnectionImpl " still gives the same error: "-standardPackage is an invalid option or argument." I think the problem is I'm using the latest release of IBMJDK, which is 70 SR1 (http://www.ibm.com/developerworks/java/jdk/linux/download.html#java7). java version "1.7.0" Java(TM) SE Runtime Environment (build pxp6470sr1-20120330_01(SR1)) IBM J9 VM (build 2.6, JRE 1.7.0 Linux ppc64-64 20120322_106209 (JIT enabled, AOT enabled) J9VM - R26_Java726_SR1_20120322_1720_B106209 JIT - r11_20120322_22976 GC - R26_Java726_SR1_20120322_1720_B106209 J9CL - 20120322_106209) JCL - 20120322_01 based on Oracle 7u3-b05 When I use pxp6470-20110827_01 to run the build, it will pass. The rmicext.properties is almost the same between these two builds, except for some copyright/date differences. So shall we define a fixed level of bootstrapping JDK before HotSpot gets to work? Regards Jonathan On 07/05/2012 11:07 PM, Volker Simonis wrote: > Hi Neil, > > thanks again for the detailed explanation. But it's still strange, why > the same 'rmic' invocation succeeds on my machine but not on > Jonathan's. > > As posted I use the following IBM JDK: > > java version "1.7.0" > Java(TM) SE Runtime Environment (build pxp6470-20110827_01) > IBM J9 VM (build 2.6, JRE 1.7.0 Linux ppc64-64 20110810_88604 (JIT > enabled, AOT enabled) > J9VM - R26_Java726_GA_20110810_1208_B88592 > JIT - r11_20110810_20466 > GC - R26_Java726_GA_20110810_1208_B88592 > J9CL - 20110810_88604) > JCL - 20110809_01 based on Oracle 7b147 > > I checked "rmicext.properties" from ibmorbtools.jar. It has the > followng entries: > > generator.args=v1.1,vcompat,v1.2,iiop,idl,xprint,mnt > > generator.class.default=sun.rmi.rmic.RMIGenerator > > generator.class.v1.1=sun.rmi.rmic.RMIGenerator > generator.class.vcompat=sun.rmi.rmic.RMIGenerator > generator.class.v1.2=sun.rmi.rmic.RMIGenerator > generator.class.iiop=com.ibm.tools.rmic.iiop.StubGenerator > generator.class.idl=com.ibm.tools.rmic.iiop.IDLGenerator > generator.class.xprint=com.ibm.tools.rmic.iiop.PrintGenerator > generator.class.mnt=com.ibm.tools.rmic.iiop.MangledNameTableGenerator > > So according to your explanation, Jonathan should get the same results > for running "/bin/java -cp /lib/tools.jar > sun.rmi.rmic.Main -d /tmp/rmic_output/ -iiop -v1.2 -standardPackage > javax.management.remote.rmi.RMIConnectionImpl" as I did. Or is there > something else which can influence the choice of the generator class. > > As far as I can see, the only place in Oracle's JDK which parses the > "-standardPackage" option is in sun.rmi.rmic.iiop.StubGenerator > (http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/file/tip/src/share/classes/sun/rmi/rmic/iiop/StubGenerator.java) > but according to your explanation, my IBM JDK should choose > "generator.class.iiop=com.ibm.tools.rmic.iiop.StubGenerator" in that > case. However if I do: > > /bin/java -showversion -verbose:class -cp > /lib/tools.jar sun.rmi.rmic.Main -d /tmp/rmic_output/ -iiop > -v1.2 -standardPackage javax.management.remote.rmi.RMIConnectionImpl > 2>&1 | grep iiop.StubGenerator > class load: sun.rmi.rmic.iiop.StubGenerator from: > file:/net/sapmnt.depot/tools/gen/linuxppc64/licenseware/jse/1.7.0/lib/tools.jar > > I can see that it uses sun.rmi.rmic.iiop.StubGenerator instead. So > there must some other configuration magic (at least on my machine). > > @Jonathan: could you please try the above command to check which > version of StubGenerator you get. > > Regards, > Volker > > > On Thu, Jul 5, 2012 at 2:43 PM, Neil Richards wrote: >> On Thu, 2012-07-05 at 11:59 +0200, Volker Simonis wrote: >>> Hi Jonathan, >>> >>> that's strange. We speciall set the 'rmic' compiler to >>> >>> RMIC='$(ALT_BOOTDIR)/bin/java -cp $(ALT_BOOTDIR)/lib/tools.jar >>> sun.rmi.rmic.Main' >>> >>> in order to use the original, Oracle version of the compiler which >>> should understand this option. >> I fear that this is not altogether sufficient to avoid using IBM's >> version of the rmic compiler for IIOP-related artifact generation. >> >> rmic is the command for producing both Java Remote Method Protocol >> (JRMP) and Internet Inter-ORB Protocol (IIOP) artifacts. >> (Associated with IIOP generation, it also can produce IDL code and a >> "Mangled Name Table"). >> >> Each of these types of generation is done by a separate "back-end" to >> rmic. >> >> The back-end implementation for each generator can be specified (usually >> by an SDK provider) using the properties file >> 'sun/rmi/rmic/resources/rmicext.properties' (and its associated >> locale-specific variants). >> >> (These properties settings are picked up by the common rmic front-end, >> using a call to ResourceBundle.getBundle().) >> >> These properties files (if they exist) tend to be held within a jar >> file, alongside the code for the backend implementations. >> >> In an IBM SDK, that code, as so that properties file, is held in >> lib/ibmorbtools.jar. >> (The IBM SDK's lib/tools.jar has a 'Class-Path:' entry in it, which >> chains onto ibmorbtools.jar). >> >> So, in all cases, the rmic command invocation calls sun.rmi.rmic.Main, >> but the settings in the rmicext.properties file controls what backend >> code gets used. >> >> (Note: This is different to the way the idlj command works, for example, >> where there is no common front-end). >> >> Hope this helps to explain why the current approach is not having the >> desired effect. >> >> Regards, >> Neil >> >> -- >> Unless stated above: >> IBM email: neil_richards at uk.ibm.com >> IBM United Kingdom Limited - Registered in England and Wales with number 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> From neil.richards at ngmr.net Fri Jul 6 05:04:22 2012 From: neil.richards at ngmr.net (Neil Richards) Date: Fri, 06 Jul 2012 13:04:22 +0100 Subject: Build error on Linux PPC64 platform In-Reply-To: <4FF69D1F.8040105@linux.vnet.ibm.com> References: <4FF54F35.7010204@linux.vnet.ibm.com> <1341492194.22277.152.camel@chalkhill> <4FF69D1F.8040105@linux.vnet.ibm.com> Message-ID: <1341576262.23269.26.camel@chalkhill> Hi all, I'm not sure why your seeing inconsistent results between a 6 and 7, or how you're getting to the Sun/Oracle/OpenJDK IIOP generator impl without eliminating the effects of the rmicext.properties settings. However, I've a (hopefully) simple approach that will ensure you're not using the IBM generator, which should work in all cases (in SDKs for 6 & 7, anyhow) ... Just rename lib/ibmorbtools.jar to be something else. As the tools.jar tries to chain onto a file of that name, and that file contains the rmicext.properties files with the IBM-impl settings, moving that file off to one side should consistently cause rmic invocations to use the OpenJDK rmic IIOP generator. Approaching things this way would also mean one would not need to use the RMIC setting. (NB: One still need to use the IDLJ setting to use the OpenJDK idlj implementation, especially as moving the ibmorbtools.jar file aside also eliminates the IBM idlj implementation from the classpath). Hope this helps. Regards, Neil On Fri, 2012-07-06 at 16:09 +0800, Jonathan Lu wrote: > Hello Volker, > > The command > > "/bin/java -cp /lib/tools.jar sun.rmi.rmic.Main -d > /tmp/rmic_output/ -iiop -v1.2 -standardPackage > javax.management.remote.rmi.RMIConnectionImpl " > > still gives the same error: > "-standardPackage is an invalid option or argument." > > I think the problem is I'm using the latest release of IBMJDK, which is > 70 SR1 > (http://www.ibm.com/developerworks/java/jdk/linux/download.html#java7). > > java version "1.7.0" > Java(TM) SE Runtime Environment (build pxp6470sr1-20120330_01(SR1)) > IBM J9 VM (build 2.6, JRE 1.7.0 Linux ppc64-64 20120322_106209 (JIT > enabled, AOT enabled) > J9VM - R26_Java726_SR1_20120322_1720_B106209 > JIT - r11_20120322_22976 > GC - R26_Java726_SR1_20120322_1720_B106209 > J9CL - 20120322_106209) > JCL - 20120322_01 based on Oracle 7u3-b05 > > When I use pxp6470-20110827_01 to run the build, it will pass. The > rmicext.properties is almost the same between these two builds, except > for some copyright/date differences. So shall we define a fixed level of > bootstrapping JDK before HotSpot gets to work? > > Regards > Jonathan > > On 07/05/2012 11:07 PM, Volker Simonis wrote: > > Hi Neil, > > > > thanks again for the detailed explanation. But it's still strange, why > > the same 'rmic' invocation succeeds on my machine but not on > > Jonathan's. > > > > As posted I use the following IBM JDK: > > > > java version "1.7.0" > > Java(TM) SE Runtime Environment (build pxp6470-20110827_01) > > IBM J9 VM (build 2.6, JRE 1.7.0 Linux ppc64-64 20110810_88604 (JIT > > enabled, AOT enabled) > > J9VM - R26_Java726_GA_20110810_1208_B88592 > > JIT - r11_20110810_20466 > > GC - R26_Java726_GA_20110810_1208_B88592 > > J9CL - 20110810_88604) > > JCL - 20110809_01 based on Oracle 7b147 > > > > I checked "rmicext.properties" from ibmorbtools.jar. It has the > > followng entries: > > > > generator.args=v1.1,vcompat,v1.2,iiop,idl,xprint,mnt > > > > generator.class.default=sun.rmi.rmic.RMIGenerator > > > > generator.class.v1.1=sun.rmi.rmic.RMIGenerator > > generator.class.vcompat=sun.rmi.rmic.RMIGenerator > > generator.class.v1.2=sun.rmi.rmic.RMIGenerator > > generator.class.iiop=com.ibm.tools.rmic.iiop.StubGenerator > > generator.class.idl=com.ibm.tools.rmic.iiop.IDLGenerator > > generator.class.xprint=com.ibm.tools.rmic.iiop.PrintGenerator > > generator.class.mnt=com.ibm.tools.rmic.iiop.MangledNameTableGenerator > > > > So according to your explanation, Jonathan should get the same results > > for running "/bin/java -cp /lib/tools.jar > > sun.rmi.rmic.Main -d /tmp/rmic_output/ -iiop -v1.2 -standardPackage > > javax.management.remote.rmi.RMIConnectionImpl" as I did. Or is there > > something else which can influence the choice of the generator class. > > > > As far as I can see, the only place in Oracle's JDK which parses the > > "-standardPackage" option is in sun.rmi.rmic.iiop.StubGenerator > > (http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/file/tip/src/share/classes/sun/rmi/rmic/iiop/StubGenerator.java) > > but according to your explanation, my IBM JDK should choose > > "generator.class.iiop=com.ibm.tools.rmic.iiop.StubGenerator" in that > > case. However if I do: > > > > /bin/java -showversion -verbose:class -cp > > /lib/tools.jar sun.rmi.rmic.Main -d /tmp/rmic_output/ -iiop > > -v1.2 -standardPackage javax.management.remote.rmi.RMIConnectionImpl > > 2>&1 | grep iiop.StubGenerator > > class load: sun.rmi.rmic.iiop.StubGenerator from: > > file:/net/sapmnt.depot/tools/gen/linuxppc64/licenseware/jse/1.7.0/lib/tools.jar > > > > I can see that it uses sun.rmi.rmic.iiop.StubGenerator instead. So > > there must some other configuration magic (at least on my machine). > > > > @Jonathan: could you please try the above command to check which > > version of StubGenerator you get. > > > > Regards, > > Volker > > > > > > On Thu, Jul 5, 2012 at 2:43 PM, Neil Richards wrote: > >> On Thu, 2012-07-05 at 11:59 +0200, Volker Simonis wrote: > >>> Hi Jonathan, > >>> > >>> that's strange. We speciall set the 'rmic' compiler to > >>> > >>> RMIC='$(ALT_BOOTDIR)/bin/java -cp $(ALT_BOOTDIR)/lib/tools.jar > >>> sun.rmi.rmic.Main' > >>> > >>> in order to use the original, Oracle version of the compiler which > >>> should understand this option. > >> I fear that this is not altogether sufficient to avoid using IBM's > >> version of the rmic compiler for IIOP-related artifact generation. > >> > >> rmic is the command for producing both Java Remote Method Protocol > >> (JRMP) and Internet Inter-ORB Protocol (IIOP) artifacts. > >> (Associated with IIOP generation, it also can produce IDL code and a > >> "Mangled Name Table"). > >> > >> Each of these types of generation is done by a separate "back-end" to > >> rmic. > >> > >> The back-end implementation for each generator can be specified (usually > >> by an SDK provider) using the properties file > >> 'sun/rmi/rmic/resources/rmicext.properties' (and its associated > >> locale-specific variants). > >> > >> (These properties settings are picked up by the common rmic front-end, > >> using a call to ResourceBundle.getBundle().) > >> > >> These properties files (if they exist) tend to be held within a jar > >> file, alongside the code for the backend implementations. > >> > >> In an IBM SDK, that code, as so that properties file, is held in > >> lib/ibmorbtools.jar. > >> (The IBM SDK's lib/tools.jar has a 'Class-Path:' entry in it, which > >> chains onto ibmorbtools.jar). > >> > >> So, in all cases, the rmic command invocation calls sun.rmi.rmic.Main, > >> but the settings in the rmicext.properties file controls what backend > >> code gets used. > >> > >> (Note: This is different to the way the idlj command works, for example, > >> where there is no common front-end). > >> > >> Hope this helps to explain why the current approach is not having the > >> desired effect. > >> > >> Regards, > >> Neil > >> > >> -- > >> Unless stated above: > >> IBM email: neil_richards at uk.ibm.com > >> IBM United Kingdom Limited - Registered in England and Wales with number 741598. > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > >> > > -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From luchsh at linux.vnet.ibm.com Sun Jul 8 22:54:37 2012 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Mon, 09 Jul 2012 13:54:37 +0800 Subject: Build error on Linux PPC64 platform In-Reply-To: <1341576262.23269.26.camel@chalkhill> References: <4FF54F35.7010204@linux.vnet.ibm.com> <1341492194.22277.152.camel@chalkhill> <4FF69D1F.8040105@linux.vnet.ibm.com> <1341576262.23269.26.camel@chalkhill> Message-ID: <4FFA721D.6020505@linux.vnet.ibm.com> Hello Neil, I've tested this approach on my LinuxPPC box by moving /lib/ibmorbtools.jar away, it works. Thanks! Regards Jonathan On 07/06/2012 08:04 PM, Neil Richards wrote: > Hi all, > I'm not sure why your seeing inconsistent results between a 6 and 7, or > how you're getting to the Sun/Oracle/OpenJDK IIOP generator impl without > eliminating the effects of the rmicext.properties settings. > > However, I've a (hopefully) simple approach that will ensure you're not > using the IBM generator, which should work in all cases (in SDKs for 6 & > 7, anyhow) ... > > Just rename lib/ibmorbtools.jar to be something else. > As the tools.jar tries to chain onto a file of that name, and that file > contains the rmicext.properties files with the IBM-impl settings, moving > that file off to one side should consistently cause rmic invocations to > use the OpenJDK rmic IIOP generator. > > Approaching things this way would also mean one would not need to use > the RMIC setting. > > (NB: One still need to use the IDLJ setting to use the OpenJDK idlj > implementation, especially as moving the ibmorbtools.jar file aside also > eliminates the IBM idlj implementation from the classpath). > > Hope this helps. > Regards, > Neil > > On Fri, 2012-07-06 at 16:09 +0800, Jonathan Lu wrote: >> Hello Volker, >> >> The command >> >> "/bin/java -cp /lib/tools.jar sun.rmi.rmic.Main -d >> /tmp/rmic_output/ -iiop -v1.2 -standardPackage >> javax.management.remote.rmi.RMIConnectionImpl " >> >> still gives the same error: >> "-standardPackage is an invalid option or argument." >> >> I think the problem is I'm using the latest release of IBMJDK, which is >> 70 SR1 >> (http://www.ibm.com/developerworks/java/jdk/linux/download.html#java7). >> >> java version "1.7.0" >> Java(TM) SE Runtime Environment (build pxp6470sr1-20120330_01(SR1)) >> IBM J9 VM (build 2.6, JRE 1.7.0 Linux ppc64-64 20120322_106209 (JIT >> enabled, AOT enabled) >> J9VM - R26_Java726_SR1_20120322_1720_B106209 >> JIT - r11_20120322_22976 >> GC - R26_Java726_SR1_20120322_1720_B106209 >> J9CL - 20120322_106209) >> JCL - 20120322_01 based on Oracle 7u3-b05 >> >> When I use pxp6470-20110827_01 to run the build, it will pass. The >> rmicext.properties is almost the same between these two builds, except >> for some copyright/date differences. So shall we define a fixed level of >> bootstrapping JDK before HotSpot gets to work? >> >> Regards >> Jonathan >> >> On 07/05/2012 11:07 PM, Volker Simonis wrote: >>> Hi Neil, >>> >>> thanks again for the detailed explanation. But it's still strange, why >>> the same 'rmic' invocation succeeds on my machine but not on >>> Jonathan's. >>> >>> As posted I use the following IBM JDK: >>> >>> java version "1.7.0" >>> Java(TM) SE Runtime Environment (build pxp6470-20110827_01) >>> IBM J9 VM (build 2.6, JRE 1.7.0 Linux ppc64-64 20110810_88604 (JIT >>> enabled, AOT enabled) >>> J9VM - R26_Java726_GA_20110810_1208_B88592 >>> JIT - r11_20110810_20466 >>> GC - R26_Java726_GA_20110810_1208_B88592 >>> J9CL - 20110810_88604) >>> JCL - 20110809_01 based on Oracle 7b147 >>> >>> I checked "rmicext.properties" from ibmorbtools.jar. It has the >>> followng entries: >>> >>> generator.args=v1.1,vcompat,v1.2,iiop,idl,xprint,mnt >>> >>> generator.class.default=sun.rmi.rmic.RMIGenerator >>> >>> generator.class.v1.1=sun.rmi.rmic.RMIGenerator >>> generator.class.vcompat=sun.rmi.rmic.RMIGenerator >>> generator.class.v1.2=sun.rmi.rmic.RMIGenerator >>> generator.class.iiop=com.ibm.tools.rmic.iiop.StubGenerator >>> generator.class.idl=com.ibm.tools.rmic.iiop.IDLGenerator >>> generator.class.xprint=com.ibm.tools.rmic.iiop.PrintGenerator >>> generator.class.mnt=com.ibm.tools.rmic.iiop.MangledNameTableGenerator >>> >>> So according to your explanation, Jonathan should get the same results >>> for running "/bin/java -cp /lib/tools.jar >>> sun.rmi.rmic.Main -d /tmp/rmic_output/ -iiop -v1.2 -standardPackage >>> javax.management.remote.rmi.RMIConnectionImpl" as I did. Or is there >>> something else which can influence the choice of the generator class. >>> >>> As far as I can see, the only place in Oracle's JDK which parses the >>> "-standardPackage" option is in sun.rmi.rmic.iiop.StubGenerator >>> (http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/file/tip/src/share/classes/sun/rmi/rmic/iiop/StubGenerator.java) >>> but according to your explanation, my IBM JDK should choose >>> "generator.class.iiop=com.ibm.tools.rmic.iiop.StubGenerator" in that >>> case. However if I do: >>> >>> /bin/java -showversion -verbose:class -cp >>> /lib/tools.jar sun.rmi.rmic.Main -d /tmp/rmic_output/ -iiop >>> -v1.2 -standardPackage javax.management.remote.rmi.RMIConnectionImpl >>> 2>&1 | grep iiop.StubGenerator >>> class load: sun.rmi.rmic.iiop.StubGenerator from: >>> file:/net/sapmnt.depot/tools/gen/linuxppc64/licenseware/jse/1.7.0/lib/tools.jar >>> >>> I can see that it uses sun.rmi.rmic.iiop.StubGenerator instead. So >>> there must some other configuration magic (at least on my machine). >>> >>> @Jonathan: could you please try the above command to check which >>> version of StubGenerator you get. >>> >>> Regards, >>> Volker >>> >>> >>> On Thu, Jul 5, 2012 at 2:43 PM, Neil Richards wrote: >>>> On Thu, 2012-07-05 at 11:59 +0200, Volker Simonis wrote: >>>>> Hi Jonathan, >>>>> >>>>> that's strange. We speciall set the 'rmic' compiler to >>>>> >>>>> RMIC='$(ALT_BOOTDIR)/bin/java -cp $(ALT_BOOTDIR)/lib/tools.jar >>>>> sun.rmi.rmic.Main' >>>>> >>>>> in order to use the original, Oracle version of the compiler which >>>>> should understand this option. >>>> I fear that this is not altogether sufficient to avoid using IBM's >>>> version of the rmic compiler for IIOP-related artifact generation. >>>> >>>> rmic is the command for producing both Java Remote Method Protocol >>>> (JRMP) and Internet Inter-ORB Protocol (IIOP) artifacts. >>>> (Associated with IIOP generation, it also can produce IDL code and a >>>> "Mangled Name Table"). >>>> >>>> Each of these types of generation is done by a separate "back-end" to >>>> rmic. >>>> >>>> The back-end implementation for each generator can be specified (usually >>>> by an SDK provider) using the properties file >>>> 'sun/rmi/rmic/resources/rmicext.properties' (and its associated >>>> locale-specific variants). >>>> >>>> (These properties settings are picked up by the common rmic front-end, >>>> using a call to ResourceBundle.getBundle().) >>>> >>>> These properties files (if they exist) tend to be held within a jar >>>> file, alongside the code for the backend implementations. >>>> >>>> In an IBM SDK, that code, as so that properties file, is held in >>>> lib/ibmorbtools.jar. >>>> (The IBM SDK's lib/tools.jar has a 'Class-Path:' entry in it, which >>>> chains onto ibmorbtools.jar). >>>> >>>> So, in all cases, the rmic command invocation calls sun.rmi.rmic.Main, >>>> but the settings in the rmicext.properties file controls what backend >>>> code gets used. >>>> >>>> (Note: This is different to the way the idlj command works, for example, >>>> where there is no common front-end). >>>> >>>> Hope this helps to explain why the current approach is not having the >>>> desired effect. >>>> >>>> Regards, >>>> Neil >>>> >>>> -- >>>> Unless stated above: >>>> IBM email: neil_richards at uk.ibm.com >>>> IBM United Kingdom Limited - Registered in England and Wales with number 741598. >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >>>> >> > From spoole at linux.vnet.ibm.com Mon Jul 9 00:58:55 2012 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Mon, 9 Jul 2012 08:58:55 +0100 Subject: AIX class library changes - update and questions Message-ID: Hi all - quick update and some questions. I've been going through the IBM and SAP changes and building them incrementally. I'm not finished yet but I wanted to float a couple of questions. 1 - use of #ifdef _AIX versus #ifdef AIX. SAP uses "_AIX" while IBM uses "AIX". For other platforms we see "__linux__" or "__solaris__" Any preference on _AIX vs AIX or something else? Currently I'm using AIX and changing any _AIX I find. 2 - We are relying on Open Source packages for some of the tools (find for instance). I'd like to make sure we are all using the same set of packages and that their installed location is the same - OR - we just agree that PATH has to be set correctly first :-) A concrete example: I noticed that SAP's common/Defs-aix.gmk file has a hard coded reference to find being in '/usr/local/bin' If you use the oss4aix packages then the relevant RPM installs find into '/opt/freeware/bin' Any thoughts on this ? From goetz.lindenmaier at sap.com Mon Jul 9 05:26:12 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 9 Jul 2012 14:26:12 +0200 Subject: AIX class library changes - update and questions In-Reply-To: References: Message-ID: <140FA3E3585AD840A3316D2853F974DC096FEE4BDF@DEWDFECCR03.wdf.sap.corp> Hi Steve, yes, in both cases we would follow your approach. In the hotspot code we anyways (mostly) use AIX without underscore, and we will adapt the jdk accordingly. Also we should use the Open Source packages, and the standard path settings. Yours, Goetz & Volker -----Original Message----- From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Steve Poole Sent: Montag, 9. Juli 2012 09:59 To: ppc-aix-port-dev at openjdk.java.net Subject: AIX class library changes - update and questions Hi all - quick update and some questions. I've been going through the IBM and SAP changes and building them incrementally. I'm not finished yet but I wanted to float a couple of questions. 1 - use of #ifdef _AIX versus #ifdef AIX. SAP uses "_AIX" while IBM uses "AIX". For other platforms we see "__linux__" or "__solaris__" Any preference on _AIX vs AIX or something else? Currently I'm using AIX and changing any _AIX I find. 2 - We are relying on Open Source packages for some of the tools (find for instance). I'd like to make sure we are all using the same set of packages and that their installed location is the same - OR - we just agree that PATH has to be set correctly first :-) A concrete example: I noticed that SAP's common/Defs-aix.gmk file has a hard coded reference to find being in '/usr/local/bin' If you use the oss4aix packages then the relevant RPM installs find into '/opt/freeware/bin' Any thoughts on this ? From spoole at linux.vnet.ibm.com Tue Jul 10 01:02:40 2012 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Tue, 10 Jul 2012 09:02:40 +0100 Subject: Missing pase_ni_helpers.h Message-ID: <7B09D154-0D8E-44FC-9503-3D627BA6DC4E@linux.vnet.ibm.com> hi guys - Goetz's big patch makes reference to pase_ni_helpers.h but doesn't include it. Any chance you can share a copy? Cheers Steve From spoole at linux.vnet.ibm.com Tue Jul 10 01:02:40 2012 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Tue, 10 Jul 2012 09:02:40 +0100 Subject: Missing pase_ni_helpers.h Message-ID: <7B09D154-0D8E-44FC-9503-3D627BA6DC4E@linux.vnet.ibm.com> hi guys - Goetz's big patch makes reference to pase_ni_helpers.h but doesn't include it. Any chance you can share a copy? Cheers Steve From spoole at linux.vnet.ibm.com Tue Jul 10 01:02:40 2012 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Tue, 10 Jul 2012 09:02:40 +0100 Subject: Missing pase_ni_helpers.h Message-ID: <7B09D154-0D8E-44FC-9503-3D627BA6DC4E@linux.vnet.ibm.com> hi guys - Goetz's big patch makes reference to pase_ni_helpers.h but doesn't include it. Any chance you can share a copy? Cheers Steve From goetz.lindenmaier at sap.com Tue Jul 10 02:03:20 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 10 Jul 2012 11:03:20 +0200 Subject: Missing pase_ni_helpers.h In-Reply-To: <7B09D154-0D8E-44FC-9503-3D627BA6DC4E@linux.vnet.ibm.com> References: <7B09D154-0D8E-44FC-9503-3D627BA6DC4E@linux.vnet.ibm.com> Message-ID: <140FA3E3585AD840A3316D2853F974DC096FEE59CA@DEWDFECCR03.wdf.sap.corp> Hi Steve, this is a file we got from IBM under closed license. ;) I thought it's only needed for PASE/as400. There is also a corresponding .c file. I'll check with my colleague who did the aix port. Unfortunately he is out of office, but reads his email. Best regards, Goetz. -----Original Message----- From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Steve Poole Sent: Dienstag, 10. Juli 2012 10:03 To: ppc-aix-port-dev at openjdk.java.net Subject: Missing pase_ni_helpers.h hi guys - Goetz's big patch makes reference to pase_ni_helpers.h but doesn't include it. Any chance you can share a copy? Cheers Steve From spoole at linux.vnet.ibm.com Tue Jul 10 03:18:04 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Tue, 10 Jul 2012 10:18:04 +0000 Subject: hg: ppc-aix-port/jdk7u/corba: Added AIX specific build defs file Message-ID: <20120710101806.4660947EE3@hg.openjdk.java.net> Changeset: 325250aef90a Author: Steve Poole Date: 2012-07-10 11:11 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/325250aef90a Added AIX specific build defs file + make/common/Defs-aix.gmk From spoole at linux.vnet.ibm.com Tue Jul 10 03:28:01 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Tue, 10 Jul 2012 10:28:01 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Initial AIX build config files primarily based on changes from SAP. This is to preserve any Hotspot speciific settings Message-ID: <20120710102820.A3FB347EE6@hg.openjdk.java.net> Changeset: ef2483557937 Author: Steve Poole Date: 2012-07-10 11:26 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/ef2483557937 Initial AIX build config files primarily based on changes from SAP. This is to preserve any Hotspot speciific settings + make/common/Defs-aix.gmk + make/common/shared/Compiler-xlc_r.gmk + make/common/shared/Defs-aix.gmk ! make/common/shared/Platform.gmk From spoole at linux.vnet.ibm.com Tue Jul 10 03:48:07 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Tue, 10 Jul 2012 10:48:07 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Updated Defs-versions to understand about using xlc compiler on AIX Message-ID: <20120710104817.D6DBB47EEC@hg.openjdk.java.net> Changeset: 7262c76ae5ec Author: spoole Date: 2012-07-10 11:47 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/7262c76ae5ec Updated Defs-versions to understand about using xlc compiler on AIX ! make/common/shared/Defs-versions.gmk From thomas.stuefe at gmail.com Tue Jul 10 04:56:27 2012 From: thomas.stuefe at gmail.com (=?ISO-8859-1?Q?Thomas_St=FCfe?=) Date: Tue, 10 Jul 2012 13:56:27 +0200 Subject: Missing pase_ni_helpers.h Message-ID: Hi, that header and its implementation derive from code we originally got from AS/400 PASE developers in Rochester. I felt unsure about its legal status, that's why it is not included in our initial checkin. I will contact the the original programmer. Kind Regards, Thomas Stuefe SAP Germany > hi guys - Goetz's big patch makes reference to pase_ni_helpers.h but doesn't include it. Any chance you can share a copy? > > Cheers > > Steve From spoole at linux.vnet.ibm.com Tue Jul 10 05:14:27 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Tue, 10 Jul 2012 12:14:27 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Updated Platform.gmk to set PLATFORM=aix when uname is AIX Message-ID: <20120710121446.74E3847EF0@hg.openjdk.java.net> Changeset: 17c5a7c7c7a4 Author: spoole Date: 2012-07-10 13:13 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/17c5a7c7c7a4 Updated Platform.gmk to set PLATFORM=aix when uname is AIX ! make/common/shared/Platform.gmk From thomas.stuefe at gmail.com Tue Jul 10 05:57:45 2012 From: thomas.stuefe at gmail.com (=?ISO-8859-1?Q?Thomas_St=FCfe?=) Date: Tue, 10 Jul 2012 14:57:45 +0200 Subject: AIX class library changes - update and questions Message-ID: Hi, I usually prefer _AIX to AIX because the former is an predefined compiler macro in xlc and therefore always works. Same reason for __linux__and __sun and so on. But I admit this clashes with what Oracle is doing in their make files... Kind Regards, Thomas > Hi Steve, > > yes, in both cases we would follow your approach. > > In the hotspot code we anyways (mostly) use AIX without underscore, and we > will adapt the jdk accordingly. > > Also we should use the Open Source packages, and the standard path settings. > > Yours, > Goetz & Volker > > > > -----Original Message----- > > From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Steve Poole > > Sent: Montag, 9. Juli 2012 09:59 > > To: AIX class library changes - update and questions > > Subject: AIX class library changes - update and questions > > > > Hi all - quick update and some questions. > > > > I've been going through the IBM and SAP changes and building them incrementally. I'm not finished yet but I wanted to float a couple of questions. > > > > 1 - use of #ifdef _AIX versus #ifdef AIX. SAP uses "_AIX" while IBM uses "AIX". For other platforms we see "__linux__" or "__solaris__" > > > > Any preference on _AIX vs AIX or something else? Currently I'm using AIX and changing any _AIX I find. > > > > 2 - We are relying on Open Source packages for some of the tools (find for instance). I'd like to make sure we are all using the same set of packages and that their installed location is the same - OR - we just agree that PATH has to be set correctly first :-) > > > > A concrete example: I noticed that SAP's common/Defs-aix.gmk file has a hard coded reference to find being in '/usr/local/bin' If you use the oss4aix packages then the relevant RPM installs find into '/opt/freeware/bin' > > > > Any thoughts on this ? From spoole at linux.vnet.ibm.com Tue Jul 10 07:17:58 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Tue, 10 Jul 2012 14:17:58 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Switched LD path setup for freetype version check so AIX can be covered by the 'everything else' part Message-ID: <20120710141815.357BA47EF9@hg.openjdk.java.net> Changeset: f189e9aac516 Author: spoole Date: 2012-07-10 15:17 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/f189e9aac516 Switched LD path setup for freetype version check so AIX can be covered by the 'everything else' part ! make/tools/freetypecheck/Makefile From spoole at linux.vnet.ibm.com Tue Jul 10 07:35:51 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Tue, 10 Jul 2012 14:35:51 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Added AIX version of classlist Message-ID: <20120710143602.4212347EFA@hg.openjdk.java.net> Changeset: c024f98a5876 Author: spoole Date: 2012-07-10 15:35 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/c024f98a5876 Added AIX version of classlist + make/tools/sharing/classlist.aix From spoole at linux.vnet.ibm.com Tue Jul 10 09:12:45 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Tue, 10 Jul 2012 16:12:45 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Added initial AIX version of UNIXProcess.java copied from existing Solaris one Message-ID: <20120710161304.D620447EFB@hg.openjdk.java.net> Changeset: a7ef2b633cac Author: spoole Date: 2012-07-10 17:12 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/a7ef2b633cac Added initial AIX version of UNIXProcess.java copied from existing Solaris one + src/solaris/classes/java/lang/UNIXProcess.java.aix From spoole at linux.vnet.ibm.com Tue Jul 10 09:27:07 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Tue, 10 Jul 2012 16:27:07 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Updated genUnixConstants.c to compile on AIX. Made location of fcntl.h file platform specific and added a default value for O_NOFOLLOW as not supported on AIX Message-ID: <20120710162718.0C30847EFE@hg.openjdk.java.net> Changeset: c7f829700d3e Author: spoole Date: 2012-07-10 17:26 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/c7f829700d3e Updated genUnixConstants.c to compile on AIX. Made location of fcntl.h file platform specific and added a default value for O_NOFOLLOW as not supported on AIX ! src/solaris/native/sun/nio/fs/genUnixConstants.c From spoole at linux.vnet.ibm.com Tue Jul 10 15:05:57 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Tue, 10 Jul 2012 22:05:57 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Expanded check for which wait.h to use. Changed so on AIX sys/wait.h is used. Message-ID: <20120710220616.2074747F1A@hg.openjdk.java.net> Changeset: 790043a5f08e Author: spoole Date: 2012-07-10 23:05 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/790043a5f08e Expanded check for which wait.h to use. Changed so on AIX sys/wait.h is used. ! src/solaris/native/java/lang/UNIXProcess_md.c From spoole at linux.vnet.ibm.com Tue Jul 10 23:27:42 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Wed, 11 Jul 2012 06:27:42 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Extended BSD remapping of special 64 bit directory function names to generic versions to now apply to AIX. Message-ID: <20120711062802.7CB9147F52@hg.openjdk.java.net> Changeset: cb8c02a0bae9 Author: spoole Date: 2012-07-11 07:27 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/cb8c02a0bae9 Extended BSD remapping of special 64 bit directory function names to generic versions to now apply to AIX. ! src/solaris/native/java/io/UnixFileSystem_md.c From spoole at linux.vnet.ibm.com Tue Jul 10 23:36:17 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Wed, 11 Jul 2012 06:36:17 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Implemented a no-op version of getPlatformTimeZoneID() for AIX Message-ID: <20120711063628.219FD47F57@hg.openjdk.java.net> Changeset: e5384090b9da Author: spoole Date: 2012-07-11 07:35 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/e5384090b9da Implemented a no-op version of getPlatformTimeZoneID() for AIX ! src/solaris/native/java/util/TimeZone_md.c From spoole at linux.vnet.ibm.com Wed Jul 11 00:39:26 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Wed, 11 Jul 2012 07:39:26 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Extend existing Solaris behaviour to cover AIX and treat empty TZ envvar same as no TZ envvar Message-ID: <20120711073939.0AD8347F5A@hg.openjdk.java.net> Changeset: 4e0d3452bac6 Author: spoole Date: 2012-07-11 08:39 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/4e0d3452bac6 Extend existing Solaris behaviour to cover AIX and treat empty TZ envvar same as no TZ envvar ! src/solaris/native/java/util/TimeZone_md.c From spoole at linux.vnet.ibm.com Wed Jul 11 01:02:27 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Wed, 11 Jul 2012 08:02:27 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Extended find zone info functionaility to compile on AIX Message-ID: <20120711080237.87A6447F5C@hg.openjdk.java.net> Changeset: 33bbb7b0ecfb Author: spoole Date: 2012-07-11 09:01 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/33bbb7b0ecfb Extended find zone info functionaility to compile on AIX ! src/solaris/native/java/util/TimeZone_md.c From spoole at linux.vnet.ibm.com Thu Jul 12 04:19:58 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Thu, 12 Jul 2012 11:19:58 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Explicitly defined ARCH_DATA_MODEL for AIX to be 64 Message-ID: <20120712112025.4933447FB6@hg.openjdk.java.net> Changeset: b8d7c3495a2f Author: spoole Date: 2012-07-12 12:19 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/b8d7c3495a2f Explicitly defined ARCH_DATA_MODEL for AIX to be 64 ! make/common/shared/Platform.gmk From spoole at linux.vnet.ibm.com Thu Jul 12 05:20:09 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Thu, 12 Jul 2012 12:20:09 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Removed unused DL_info declaration in java_md_solinux.c that caused AIX compiler failure Message-ID: <20120712122020.3012947FB7@hg.openjdk.java.net> Changeset: 8749c00441f6 Author: spoole Date: 2012-07-12 13:19 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/8749c00441f6 Removed unused DL_info declaration in java_md_solinux.c that caused AIX compiler failure ! src/solaris/bin/java_md_solinux.c From spoole at linux.vnet.ibm.com Thu Jul 12 05:44:07 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Thu, 12 Jul 2012 12:44:07 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: 2 new changesets Message-ID: <20120712124428.73BAD47FB8@hg.openjdk.java.net> Changeset: 53d3902bd370 Author: spoole Date: 2012-07-12 13:34 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/53d3902bd370 Added AIX to list of operating systems to include in static jli build ! make/common/Program.gmk Changeset: e93b6183eb5e Author: spoole Date: 2012-07-12 13:43 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/e93b6183eb5e Extended decision to use pthreads in java_md_solinux to include specific use of USE_PTHREADS define ! src/solaris/bin/java_md_solinux.c From spoole at linux.vnet.ibm.com Thu Jul 12 05:50:45 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Thu, 12 Jul 2012 12:50:45 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Updated using pthreads in java_md_solinux.c to just rely on USE_PTHREADS. Removed the superflous __linux__ as USE_PTHREADS is already explictly turned on for linux builds Message-ID: <20120712125056.4E5EC47FB9@hg.openjdk.java.net> Changeset: 5c3a27b86fd1 Author: spoole Date: 2012-07-12 13:50 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/5c3a27b86fd1 Updated using pthreads in java_md_solinux.c to just rely on USE_PTHREADS. Removed the superflous __linux__ as USE_PTHREADS is already explictly turned on for linux builds ! src/solaris/bin/java_md_solinux.c From spoole at linux.vnet.ibm.com Thu Jul 12 07:11:32 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Thu, 12 Jul 2012 14:11:32 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Disable use of sys/swap.h when building UnixOperatingSystem_md.c on AIX Message-ID: <20120712141154.CFF6247FBE@hg.openjdk.java.net> Changeset: 8f0ee3a1c347 Author: spoole Date: 2012-07-12 15:07 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/8f0ee3a1c347 Disable use of sys/swap.h when building UnixOperatingSystem_md.c on AIX ! src/solaris/native/com/sun/management/UnixOperatingSystem_md.c From spoole at linux.vnet.ibm.com Thu Jul 12 07:23:05 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Thu, 12 Jul 2012 14:23:05 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Expanded platform choice logic to include AIX when deciding to create the MB macro. Message-ID: <20120712142316.F0DB347FC0@hg.openjdk.java.net> Changeset: b9989b28cde0 Author: spoole Date: 2012-07-12 15:22 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/b9989b28cde0 Expanded platform choice logic to include AIX when deciding to create the MB macro. ! src/solaris/native/com/sun/management/UnixOperatingSystem_md.c From spoole at linux.vnet.ibm.com Thu Jul 12 07:29:55 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Thu, 12 Jul 2012 14:29:55 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Extended existing ifdef to cover AIX so that npt does not include link.h Message-ID: <20120712143005.D2DCB47FC3@hg.openjdk.java.net> Changeset: 07155f8a4bfa Author: spoole Date: 2012-07-12 15:29 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/07155f8a4bfa Extended existing ifdef to cover AIX so that npt does not include link.h ! src/solaris/npt/npt_md.h From spoole at linux.vnet.ibm.com Thu Jul 12 23:37:27 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Fri, 13 Jul 2012 06:37:27 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Updated hprof demo to build on AIX. Added SAP changes to fake out DLinfo etc Message-ID: <20120713063757.540F447013@hg.openjdk.java.net> Changeset: 27019b5b51d5 Author: spoole Date: 2012-07-13 07:37 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/27019b5b51d5 Updated hprof demo to build on AIX. Added SAP changes to fake out DLinfo etc ! src/solaris/demo/jvmti/hprof/hprof_md.c From spoole at linux.vnet.ibm.com Thu Jul 12 23:54:11 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Fri, 13 Jul 2012 06:54:11 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Updated hprof_md.c to include AIX as platform without hires timer Message-ID: <20120713065432.1E02847015@hg.openjdk.java.net> Changeset: 804ffc458c3c Author: spoole Date: 2012-07-13 07:54 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/804ffc458c3c Updated hprof_md.c to include AIX as platform without hires timer ! src/solaris/demo/jvmti/hprof/hprof_md.c From spoole at linux.vnet.ibm.com Fri Jul 13 00:12:59 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Fri, 13 Jul 2012 07:12:59 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Added missing Dlinfo structure for SAP version of hprof_md.c Message-ID: <20120713071318.54D3E47016@hg.openjdk.java.net> Changeset: ba7fdaa97b0c Author: spoole Date: 2012-07-13 08:12 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/ba7fdaa97b0c Added missing Dlinfo structure for SAP version of hprof_md.c ! src/solaris/demo/jvmti/hprof/hprof_md.c From spoole at linux.vnet.ibm.com Fri Jul 13 00:24:40 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Fri, 13 Jul 2012 07:24:40 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Enabled SoundDefs to build on AIX Message-ID: <20120713072459.1AC2747017@hg.openjdk.java.net> Changeset: 5d9bd32c4653 Author: spoole Date: 2012-07-13 08:24 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/5d9bd32c4653 Enabled SoundDefs to build on AIX ! make/javax/sound/SoundDefs.gmk From spoole at linux.vnet.ibm.com Fri Jul 13 00:49:58 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Fri, 13 Jul 2012 07:49:58 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Added missing B_FALSE and B_TRUE definitions for AIX when building ec component. Message-ID: <20120713075017.E92FB4701A@hg.openjdk.java.net> Changeset: 6804386e0129 Author: spoole Date: 2012-07-13 08:49 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/6804386e0129 Added missing B_FALSE and B_TRUE definitions for AIX when building ec component. ! src/share/native/sun/security/ec/impl/ecc_impl.h From spoole at linux.vnet.ibm.com Fri Jul 13 01:06:44 2012 From: spoole at linux.vnet.ibm.com (spoole at linux.vnet.ibm.com) Date: Fri, 13 Jul 2012 08:06:44 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: link.h not required (and does not exist) on AIX. Expanded conditional include to cover AIX Message-ID: <20120713080654.6C7F24701B@hg.openjdk.java.net> Changeset: 197aef0b114c Author: spoole Date: 2012-07-13 09:01 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/197aef0b114c link.h not required (and does not exist) on AIX. Expanded conditional include to cover AIX ! src/solaris/native/sun/security/pkcs11/j2secmod_md.c From volker.simonis at gmail.com Mon Jul 16 01:15:39 2012 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 16 Jul 2012 10:15:39 +0200 Subject: hg: ppc-aix-port/jdk7u/jdk: Updated using pthreads in java_md_solinux.c to just rely on USE_PTHREADS. Removed the superflous __linux__ as USE_PTHREADS is already explictly turned on for linux builds In-Reply-To: <20120712125056.4E5EC47FB9@hg.openjdk.java.net> References: <20120712125056.4E5EC47FB9@hg.openjdk.java.net> Message-ID: Hi Steve, this change breaks the Linux build, because USE_PTHREADS is defined in /usr/work/openjdk/nb/fdbg/linuxx86_64/jdk7u/jdk/make/common/Defs-linux.gmk, but it is not really exported in the CFLAGS/CPPFLAGS as this is done for AIX. So there are two possibilities here: we could either reintroduce the "superflous" __linux__ or we could export USE_PTHREADS in the CFLAGS/CPPFLAGS in the same way as this is done for AIX. Although we wanted to do as few changes as possible in shared code, I'd vote for the second option, because this is really a feature we want to use (PTHREADS) and it should be defined once in the makefile for the corresponding platform. Going that way would simplify further ports like for example HPUX. What do you think? Do you want me to do the change or do you have a Linux build yourself? Regards, Volker On Thu, Jul 12, 2012 at 2:50 PM, wrote: > > Changeset: 5c3a27b86fd1 > Author: spoole > Date: 2012-07-12 13:50 +0100 > URL: > http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/5c3a27b86fd1 > > Updated using pthreads in java_md_solinux.c to just rely on USE_PTHREADS. > Removed the superflous __linux__ as USE_PTHREADS is already explictly > turned on for linux builds > > ! src/solaris/bin/java_md_solinux.c > From goetz.lindenmaier at sap.com Mon Jul 16 02:07:45 2012 From: goetz.lindenmaier at sap.com (goetz.lindenmaier at sap.com) Date: Mon, 16 Jul 2012 09:07:45 +0000 Subject: hg: ppc-aix-port/jdk7u/hotspot: 2 new changesets Message-ID: <20120716090755.497A547080@hg.openjdk.java.net> Changeset: d65d0876ab43 Author: Goetz Lindenmaier Date: 2012-07-16 10:12 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/d65d0876ab43 Implement printing CodeComments in stubs. The interpreter contains various long assembly code parts which are stored as stubs. The output of +PrintInterpreter is unstructured und thus not easy to read. This can be improved with CodeComments of the MacroAssembler. So far they were lost when the code is turned into a Stub, while they were kept if the code is copied to a CodeBlob. Implemented storing the CodeComments in stubs and added support to pass them to the disasembler. ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/icBuffer.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/stubs.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreter.hpp Changeset: 32adc35fce30 Author: Goetz Lindenmaier Date: 2012-07-16 10:21 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/32adc35fce30 Trampoline relocations. A trampoline allows to encode a small branch in the code, even if there is the chance that this branch can not reach all possible code locations. If the relocation finds that a branch is too far for the instruction in the code, it can patch it to jump to the trampoline where is sufficient space for a far branch. Needed on PPC. ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp From neil.richards at ngmr.net Mon Jul 16 07:28:42 2012 From: neil.richards at ngmr.net (Neil Richards) Date: Mon, 16 Jul 2012 15:28:42 +0100 Subject: hg: ppc-aix-port/jdk7u/jdk: Updated using pthreads in java_md_solinux.c to just rely on USE_PTHREADS. Removed the superflous __linux__ as USE_PTHREADS is already explictly turned on for linux builds In-Reply-To: References: <20120712125056.4E5EC47FB9@hg.openjdk.java.net> Message-ID: <1342448922.12198.16.camel@chalkhill> Hi Volker, I also prefer the second option. I think in the Linux case, one would need only to export USE_PTHREADS in CPPFLAGS because, confusingly, it looks like CPPFLAGS is used for different things on Linux compared to AIX. On AIX, CPPFLAGS is used for invocations of the C++ compiler (the 'PP' standing for 'Plus-Plus'). On Linux, CPPFLAGS is for the C Pre-Processor, and so is used for invocations of both the C and C++ compilers. (Linux has CXXFLAGS for C++-specific options). So, on Linux, adding to CPPFLAGS_COMMON should cater for both scenarios, I believe, whilst on AIX, one needs to add to both CPPFLAGS_COMMON and CFLAGS_COMMON. I'm still grappling with Steve's instructions on building this stuff (whilst he suns himself in the glorious British summer weather [1] for a bit), so if you're able to quickly verify (or refute) what I'm saying above, feel free to push a suitable change up to the project. Regards, Neil [1] http://goo.gl/qQIJq On Mon, 2012-07-16 at 10:15 +0200, Volker Simonis wrote: > Hi Steve, > > this change breaks the Linux build, because USE_PTHREADS is defined in > /usr/work/openjdk/nb/fdbg/linuxx86_64/jdk7u/jdk/make/common/Defs-linux.gmk, > but it is not really exported in the CFLAGS/CPPFLAGS as this is done > for AIX. > > So there are two possibilities here: we could either reintroduce the > "superflous" __linux__ or we could export USE_PTHREADS in the > CFLAGS/CPPFLAGS in the same way as this is done for AIX. Although we > wanted to do as few changes as possible in shared code, I'd vote for > the second option, because this is really a feature we want to use > (PTHREADS) and it should be defined once in the makefile for the > corresponding platform. Going that way would simplify further ports > like for example HPUX. > > What do you think? Do you want me to do the change or do you have a > Linux build yourself? > > Regards, > Volker > > On Thu, Jul 12, 2012 at 2:50 PM, wrote: > > > > Changeset: 5c3a27b86fd1 > > Author: spoole > > Date: 2012-07-12 13:50 +0100 > > URL: > > http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/5c3a27b86fd1 > > > > Updated using pthreads in java_md_solinux.c to just rely on USE_PTHREADS. > > Removed the superflous __linux__ as USE_PTHREADS is already explictly > > turned on for linux builds > > > > ! src/solaris/bin/java_md_solinux.c > > -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From volker.simonis at gmail.com Mon Jul 16 10:57:09 2012 From: volker.simonis at gmail.com (volker.simonis at gmail.com) Date: Mon, 16 Jul 2012 17:57:09 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Export 'USE_PTHREADS' on Linux trough CPPFLAGS to fix the build because java_md_solinux.c now only relies on 'USE_PTHREADS' beeing defined. Message-ID: <20120716175727.AC1CF47097@hg.openjdk.java.net> Changeset: 35172a51cc76 Author: simonis Date: 2012-07-16 19:54 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/35172a51cc76 Export 'USE_PTHREADS' on Linux trough CPPFLAGS to fix the build because java_md_solinux.c now only relies on 'USE_PTHREADS' beeing defined. ! make/common/Defs-linux.gmk ! src/solaris/bin/java_md_solinux.c From volker.simonis at gmail.com Mon Jul 16 11:01:57 2012 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 16 Jul 2012 20:01:57 +0200 Subject: hg: ppc-aix-port/jdk7u/jdk: Updated using pthreads in java_md_solinux.c to just rely on USE_PTHREADS. Removed the superflous __linux__ as USE_PTHREADS is already explictly turned on for linux builds In-Reply-To: <1342448922.12198.16.camel@chalkhill> References: <20120712125056.4E5EC47FB9@hg.openjdk.java.net> <1342448922.12198.16.camel@chalkhill> Message-ID: Hi Neil, yes you're right - just had to export USE_PTHREADS through CPPFLAGS on Linux. I've just pushed the fix: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/35172a51cc76 Regards, Volker PS: weather is similar in Germany:) On Mon, Jul 16, 2012 at 4:28 PM, Neil Richards wrote: > Hi Volker, > I also prefer the second option. > > I think in the Linux case, one would need only to export USE_PTHREADS in > CPPFLAGS because, confusingly, it looks like CPPFLAGS is used for > different things on Linux compared to AIX. > > On AIX, CPPFLAGS is used for invocations of the C++ compiler (the 'PP' > standing for 'Plus-Plus'). > > On Linux, CPPFLAGS is for the C Pre-Processor, and so is used for > invocations of both the C and C++ compilers. > (Linux has CXXFLAGS for C++-specific options). > > So, on Linux, adding to CPPFLAGS_COMMON should cater for both scenarios, > I believe, whilst on AIX, one needs to add to both CPPFLAGS_COMMON and > CFLAGS_COMMON. > > I'm still grappling with Steve's instructions on building this stuff > (whilst he suns himself in the glorious British summer weather [1] for a > bit), so if you're able to quickly verify (or refute) what I'm saying > above, feel free to push a suitable change up to the project. > > Regards, > Neil > > [1] http://goo.gl/qQIJq > > On Mon, 2012-07-16 at 10:15 +0200, Volker Simonis wrote: >> Hi Steve, >> >> this change breaks the Linux build, because USE_PTHREADS is defined in >> /usr/work/openjdk/nb/fdbg/linuxx86_64/jdk7u/jdk/make/common/Defs-linux.gmk, >> but it is not really exported in the CFLAGS/CPPFLAGS as this is done >> for AIX. >> >> So there are two possibilities here: we could either reintroduce the >> "superflous" __linux__ or we could export USE_PTHREADS in the >> CFLAGS/CPPFLAGS in the same way as this is done for AIX. Although we >> wanted to do as few changes as possible in shared code, I'd vote for >> the second option, because this is really a feature we want to use >> (PTHREADS) and it should be defined once in the makefile for the >> corresponding platform. Going that way would simplify further ports >> like for example HPUX. >> >> What do you think? Do you want me to do the change or do you have a >> Linux build yourself? >> >> Regards, >> Volker >> >> On Thu, Jul 12, 2012 at 2:50 PM, wrote: >> > >> > Changeset: 5c3a27b86fd1 >> > Author: spoole >> > Date: 2012-07-12 13:50 +0100 >> > URL: >> > http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/5c3a27b86fd1 >> > >> > Updated using pthreads in java_md_solinux.c to just rely on USE_PTHREADS. >> > Removed the superflous __linux__ as USE_PTHREADS is already explictly >> > turned on for linux builds >> > >> > ! src/solaris/bin/java_md_solinux.c >> > > > > -- > Unless stated above: > IBM email: neil_richards at uk.ibm.com > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From thomas.stuefe at gmail.com Mon Jul 16 23:21:47 2012 From: thomas.stuefe at gmail.com (=?ISO-8859-1?Q?Thomas_St=FCfe?=) Date: Tue, 17 Jul 2012 08:21:47 +0200 Subject: hg: ppc-aix-port/jdk7u/jdk: Updated using pthreads in java_md_solinux.c to just rely on USE_PTHREADS. Removed the superflous __linux__ as USE_PTHREADS is already explictly turned on for linux builds In-Reply-To: <1342448922.12198.16.camel@chalkhill> References: <20120712125056.4E5EC47FB9@hg.openjdk.java.net> <1342448922.12198.16.camel@chalkhill> Message-ID: Hi Neil, > > On AIX, CPPFLAGS is used for invocations of the C++ compiler (the 'PP' > standing for 'Plus-Plus'). > > On Linux, CPPFLAGS is for the C Pre-Processor, and so is used for > invocations of both the C and C++ compilers. > (Linux has CXXFLAGS for C++-specific options). > > So, on Linux, adding to CPPFLAGS_COMMON should cater for both scenarios, > I believe, whilst on AIX, one needs to add to both CPPFLAGS_COMMON and > CFLAGS_COMMON. Are you sure this is right? I could not find any documentation for that, e.g. on the xlC manuals. Reason I ask is I always thought both CXXFLAGS and CPPFLAGS originally came from the GNU automake toolchain, and that what you describe as "the Linux way" is just the correct way to use those variables - but that many people use CPPFLAGS as "C++-Flags" because that is the first thing which comes to mind. I may be wrong. I think it's mostly all convention anyway, the only tools I think do something with those variables are autoconf/automake. When working on the AIX port of the SAP JVM, we tried to keep the GNU meaning of CPPFLAGS intact: CPPFLAGS for -D../-I.., CXXFLAGS/CFLAGS for languange specific settings. However, this has the tendency to detoriate, so you probably will find both meanings in the makefiles. Kind Regards, Thomas Stuefe SAP Germany > > I'm still grappling with Steve's instructions on building this stuff > (whilst he suns himself in the glorious British summer weather [1] for a > bit), so if you're able to quickly verify (or refute) what I'm saying > above, feel free to push a suitable change up to the project. > > Regards, > Neil > > [1] http://goo.gl/qQIJq > > On Mon, 2012-07-16 at 10:15 +0200, Volker Simonis wrote: >> Hi Steve, >> >> this change breaks the Linux build, because USE_PTHREADS is defined in >> /usr/work/openjdk/nb/fdbg/linuxx86_64/jdk7u/jdk/make/common/Defs-linux.gmk, >> but it is not really exported in the CFLAGS/CPPFLAGS as this is done >> for AIX. >> >> So there are two possibilities here: we could either reintroduce the >> "superflous" __linux__ or we could export USE_PTHREADS in the >> CFLAGS/CPPFLAGS in the same way as this is done for AIX. Although we >> wanted to do as few changes as possible in shared code, I'd vote for >> the second option, because this is really a feature we want to use >> (PTHREADS) and it should be defined once in the makefile for the >> corresponding platform. Going that way would simplify further ports >> like for example HPUX. >> >> What do you think? Do you want me to do the change or do you have a >> Linux build yourself? >> >> Regards, >> Volker >> >> On Thu, Jul 12, 2012 at 2:50 PM, wrote: >> > >> > Changeset: 5c3a27b86fd1 >> > Author: spoole >> > Date: 2012-07-12 13:50 +0100 >> > URL: >> > http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/5c3a27b86fd1 >> > >> > Updated using pthreads in java_md_solinux.c to just rely on USE_PTHREADS. >> > Removed the superflous __linux__ as USE_PTHREADS is already explictly >> > turned on for linux builds >> > >> > ! src/solaris/bin/java_md_solinux.c >> > > > > -- > Unless stated above: > IBM email: neil_richards at uk.ibm.com > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From volker.simonis at gmail.com Tue Jul 17 10:12:13 2012 From: volker.simonis at gmail.com (volker.simonis at gmail.com) Date: Tue, 17 Jul 2012 17:12:13 +0000 Subject: hg: ppc-aix-port/jdk7u: Enable the build of HotSpot 'CORE' targets from the top-level makefile by setting CORE_BUILD=true. Message-ID: <20120717171213.17CB8470D7@hg.openjdk.java.net> Changeset: 82498bce2953 Author: simonis Date: 2012-07-17 19:10 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/82498bce2953 Enable the build of HotSpot 'CORE' targets from the top-level makefile by setting CORE_BUILD=true. ! make/hotspot-rules.gmk From neil.richards at ngmr.net Wed Jul 18 04:58:58 2012 From: neil.richards at ngmr.net (Neil Richards) Date: Wed, 18 Jul 2012 12:58:58 +0100 Subject: hg: ppc-aix-port/jdk7u/jdk: Updated using pthreads in java_md_solinux.c to just rely on USE_PTHREADS. Removed the superflous __linux__ as USE_PTHREADS is already explictly turned on for linux builds In-Reply-To: References: <20120712125056.4E5EC47FB9@hg.openjdk.java.net> <1342448922.12198.16.camel@chalkhill> Message-ID: <1342612738.28179.31.camel@chalkhill> On Tue, 2012-07-17 at 08:21 +0200, Thomas St?fe wrote: > Hi Neil, > > > > > On AIX, CPPFLAGS is used for invocations of the C++ compiler (the 'PP' > > standing for 'Plus-Plus'). > > > > On Linux, CPPFLAGS is for the C Pre-Processor, and so is used for > > invocations of both the C and C++ compilers. > > (Linux has CXXFLAGS for C++-specific options). > > > > So, on Linux, adding to CPPFLAGS_COMMON should cater for both scenarios, > > I believe, whilst on AIX, one needs to add to both CPPFLAGS_COMMON and > > CFLAGS_COMMON. > > Are you sure this is right? I could not find any documentation for > that, e.g. on the xlC manuals. > > Reason I ask is I always thought both CXXFLAGS and CPPFLAGS originally > came from the GNU automake toolchain, and that what you describe as > "the Linux way" is just the correct way to use those variables - but > that many people use CPPFLAGS as "C++-Flags" because that is the first > thing which comes to mind. > > I may be wrong. I think it's mostly all convention anyway, the only > tools I think do something with those variables are autoconf/automake. > > When working on the AIX port of the SAP JVM, we tried to keep the GNU > meaning of CPPFLAGS intact: CPPFLAGS for -D../-I.., CXXFLAGS/CFLAGS > for languange specific settings. However, this has the tendency to > detoriate, so you probably will find both meanings in the makefiles. > > Kind Regards, > Thomas Stuefe > SAP Germany > Hi Thomas, To be honest, I'm more certain on the Linux side of this story than I am on the AIX side. :-) When writing the reply, I did find some references via Google that seemed to confirm the AIX story I was spinning. Naturally, as I didn't take a note of them at that point, trying to track those references down again has proven elusive, thus casting doubt on their validity. Obviously, the use of these variables is controlled by the make environment, rather than the compiler, as it is the (potentially implicit) rules in the make system that use the variables (in whatever combination) to give command line options to the compiler. So, if/as it's GNU make being used on both systems, I suppose it makes sense its behaviour re. these variables should also be (made to be) similar. If this is the case, I'm hoping I'll see duplication of (-DUSE_PTHREADS) options when compiling C++ code (with Steve's change) on AIX. If I see that, I'll have confirmation as to what correction to Steve's change is necessary to bring the use of these variables into line (with the GNU make / autoconf / automake) norm. If that option isn't duplicated in the invocation of the C++ compiler on AIX, it may suggest there are other factors in play (eg. the implicit rule for C++ compilation is being overridden somewhere). In that case, I'll have to dig deeper to figure out what's going on. Regards, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From volker.simonis at gmail.com Wed Jul 18 07:19:42 2012 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 18 Jul 2012 16:19:42 +0200 Subject: hg: ppc-aix-port/jdk7u/jdk: Updated using pthreads in java_md_solinux.c to just rely on USE_PTHREADS. Removed the superflous __linux__ as USE_PTHREADS is already explictly turned on for linux builds In-Reply-To: <1342612738.28179.31.camel@chalkhill> References: <20120712125056.4E5EC47FB9@hg.openjdk.java.net> <1342448922.12198.16.camel@chalkhill> <1342612738.28179.31.camel@chalkhill> Message-ID: I think the build (at least the HotSpot build) doesn't use implicit rules at all. I have no reference for this, but we recently found out that we can considerably speed up the Windows build if we disable implicit make rules, so this implicates that they are not really used. Regards, Volker On Wed, Jul 18, 2012 at 1:58 PM, Neil Richards wrote: > On Tue, 2012-07-17 at 08:21 +0200, Thomas St?fe wrote: >> Hi Neil, >> >> > >> > On AIX, CPPFLAGS is used for invocations of the C++ compiler (the 'PP' >> > standing for 'Plus-Plus'). >> > >> > On Linux, CPPFLAGS is for the C Pre-Processor, and so is used for >> > invocations of both the C and C++ compilers. >> > (Linux has CXXFLAGS for C++-specific options). >> > >> > So, on Linux, adding to CPPFLAGS_COMMON should cater for both scenarios, >> > I believe, whilst on AIX, one needs to add to both CPPFLAGS_COMMON and >> > CFLAGS_COMMON. >> >> Are you sure this is right? I could not find any documentation for >> that, e.g. on the xlC manuals. >> >> Reason I ask is I always thought both CXXFLAGS and CPPFLAGS originally >> came from the GNU automake toolchain, and that what you describe as >> "the Linux way" is just the correct way to use those variables - but >> that many people use CPPFLAGS as "C++-Flags" because that is the first >> thing which comes to mind. >> >> I may be wrong. I think it's mostly all convention anyway, the only >> tools I think do something with those variables are autoconf/automake. >> >> When working on the AIX port of the SAP JVM, we tried to keep the GNU >> meaning of CPPFLAGS intact: CPPFLAGS for -D../-I.., CXXFLAGS/CFLAGS >> for languange specific settings. However, this has the tendency to >> detoriate, so you probably will find both meanings in the makefiles. >> >> Kind Regards, >> Thomas Stuefe >> SAP Germany >> > > Hi Thomas, > To be honest, I'm more certain on the Linux side of this story than I am > on the AIX side. :-) > > When writing the reply, I did find some references via Google that > seemed to confirm the AIX story I was spinning. Naturally, as I didn't > take a note of them at that point, trying to track those references down > again has proven elusive, thus casting doubt on their validity. > > Obviously, the use of these variables is controlled by the make > environment, rather than the compiler, as it is the (potentially > implicit) rules in the make system that use the variables (in whatever > combination) to give command line options to the compiler. > > So, if/as it's GNU make being used on both systems, I suppose it makes > sense its behaviour re. these variables should also be (made to be) > similar. > > If this is the case, I'm hoping I'll see duplication of > (-DUSE_PTHREADS) options when compiling C++ code (with Steve's change) > on AIX. If I see that, I'll have confirmation as to what correction to > Steve's change is necessary to bring the use of these variables into > line (with the GNU make / autoconf / automake) norm. > > If that option isn't duplicated in the invocation of the C++ compiler on > AIX, it may suggest there are other factors in play (eg. the implicit > rule for C++ compilation is being overridden somewhere). In that case, > I'll have to dig deeper to figure out what's going on. > > Regards, > Neil > > -- > Unless stated above: > IBM email: neil_richards at uk.ibm.com > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From goetz.lindenmaier at sap.com Wed Jul 18 08:49:21 2012 From: goetz.lindenmaier at sap.com (goetz.lindenmaier at sap.com) Date: Wed, 18 Jul 2012 15:49:21 +0000 Subject: hg: ppc-aix-port/jdk7u/hotspot: 2 new changesets Message-ID: <20120718154928.3F69D47104@hg.openjdk.java.net> Changeset: a6b2edd06e9d Author: Goetz Lindenmaier Date: 2012-07-17 14:41 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/a6b2edd06e9d Implement printing CodeComments in stubs: fix product build. ! src/share/vm/interpreter/interpreter.cpp Changeset: b0c671204c2c Author: Goetz Lindenmaier Date: 2012-07-17 22:15 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/b0c671204c2c PPC assembly needed to start up the interpreter. This includes some extensions to the cppInterpreter for methodHandles, a larger change to BiasedLocking in bytecodeInterpreter.cpp (which needs to be reworked), and some minor shared changes. The interpreter now succesfully executes the queens testprogram. ! src/cpu/ppc/vm/assembler_ppc.cpp ! src/cpu/ppc/vm/assembler_ppc.hpp ! src/cpu/ppc/vm/assembler_ppc.inline.hpp ! src/cpu/ppc/vm/cppInterpreterGenerator_ppc.hpp ! src/cpu/ppc/vm/cppInterpreter_ppc.cpp ! src/cpu/ppc/vm/frame_ppc.cpp ! src/cpu/ppc/vm/frame_ppc.hpp ! src/cpu/ppc/vm/frame_ppc.inline.hpp ! src/cpu/ppc/vm/globals_ppc.hpp ! src/cpu/ppc/vm/icBuffer_ppc.cpp ! src/cpu/ppc/vm/icache_ppc.cpp + src/cpu/ppc/vm/interp_masm_ppc_64.cpp ! src/cpu/ppc/vm/interp_masm_ppc_64.hpp ! src/cpu/ppc/vm/interpreterGenerator_ppc.hpp ! src/cpu/ppc/vm/interpreterRT_ppc.cpp ! src/cpu/ppc/vm/interpreterRT_ppc.hpp ! src/cpu/ppc/vm/interpreter_ppc.cpp ! src/cpu/ppc/vm/interpreter_ppc.hpp ! src/cpu/ppc/vm/methodHandles_ppc.cpp ! src/cpu/ppc/vm/nativeInst_ppc.cpp ! src/cpu/ppc/vm/nativeInst_ppc.hpp + src/cpu/ppc/vm/register_ppc.cpp ! src/cpu/ppc/vm/register_ppc.hpp ! src/cpu/ppc/vm/relocInfo_ppc.cpp ! src/cpu/ppc/vm/sharedRuntime_ppc.cpp ! src/cpu/ppc/vm/stubGenerator_ppc.cpp ! src/cpu/ppc/vm/vm_version_ppc.cpp ! src/cpu/ppc/vm/vmreg_ppc.cpp ! src/cpu/ppc/vm/vmreg_ppc.hpp ! src/cpu/ppc/vm/vmreg_ppc.inline.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/thread.hpp From goetz.lindenmaier at sap.com Thu Jul 19 05:48:41 2012 From: goetz.lindenmaier at sap.com (goetz.lindenmaier at sap.com) Date: Thu, 19 Jul 2012 12:48:41 +0000 Subject: hg: ppc-aix-port/jdk7u/hotspot: Use stubs to implement safefetch. Message-ID: <20120719124848.5A0964713F@hg.openjdk.java.net> Changeset: 60d97665b9e5 Author: Goetz Lindenmaier Date: 2012-07-19 14:07 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/60d97665b9e5 Use stubs to implement safefetch. On platforms where the compiler does not properly support inline assembly safefetch can be implemented as stub routines. This also allows to use a single implementation if an architecture is supported on several os platforms. ! make/aix/makefiles/ppc64.make ! make/linux/makefiles/ppc64.make ! src/cpu/ppc/vm/stubGenerator_ppc.cpp ! src/cpu/ppc/vm/stubRoutines_ppc_64.cpp ! src/cpu/ppc/vm/stubRoutines_ppc_64.hpp ! src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp ! src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp From goetz.lindenmaier at sap.com Thu Jul 19 06:51:53 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 19 Jul 2012 15:51:53 +0200 Subject: Interpreter comes to life! Message-ID: <140FA3E3585AD840A3316D2853F974DC0970A382F4@DEWDFECCR03.wdf.sap.corp> Hi, With my last change to the hotspot repo executing simple java programs as jvm98 works on linuxppc! Don't expect too much speed, though, it's just interpreted. Cheers, Goetz. From t.p.ellison at gmail.com Fri Jul 20 00:55:26 2012 From: t.p.ellison at gmail.com (Tim Ellison) Date: Fri, 20 Jul 2012 08:55:26 +0100 Subject: Interpreter comes to life! In-Reply-To: <140FA3E3585AD840A3316D2853F974DC0970A382F4@DEWDFECCR03.wdf.sap.corp> References: <140FA3E3585AD840A3316D2853F974DC0970A382F4@DEWDFECCR03.wdf.sap.corp> Message-ID: <50090EEE.1030205@gmail.com> That's very cool -- good work Goetz! Tim On 19/07/2012 14:51, Lindenmaier, Goetz wrote: > Hi, > > With my last change to the hotspot repo executing simple java programs > as jvm98 works on linuxppc! Don't expect too much speed, though, it's just > interpreted. > > Cheers, > Goetz. > > > From thomas.stuefe at gmail.com Sun Jul 22 13:11:29 2012 From: thomas.stuefe at gmail.com (=?ISO-8859-1?Q?Thomas_St=FCfe?=) Date: Sun, 22 Jul 2012 22:11:29 +0200 Subject: hg: ppc-aix-port/jdk7u/jdk: Updated using pthreads in java_md_solinux.c to just rely on USE_PTHREADS. Removed the superflous __linux__ as USE_PTHREADS is already explictly turned on for linux builds In-Reply-To: References: <20120712125056.4E5EC47FB9@hg.openjdk.java.net> <1342448922.12198.16.camel@chalkhill> <1342612738.28179.31.camel@chalkhill> Message-ID: Hi, Neil, Volker, I also looked and did not find any proof that CPPFLAGS would *not* be synonymous for C++ on AIX. So, Neil may be right with his AIX claim. The "hardest" definition I could find (beside wikipedia) is the GNU make manual: http://www.gnu.org/software/make/manual/make.html#Implicit-Variables I think in the end it is just our decision - as Volker said, the make does not seem to use implicit rules but always spells them out. It would be my preference to stick to the GNU standard, but I am pretty sure it is already used both ways in the OpenJDK make files. Regards, Thomas On Wed, Jul 18, 2012 at 4:19 PM, Volker Simonis wrote: > I think the build (at least the HotSpot build) doesn't use implicit > rules at all. > I have no reference for this, but we recently found out that we can > considerably speed up the Windows build if we disable implicit make > rules, so this implicates that they are not really used. > > Regards, > Volker > > On Wed, Jul 18, 2012 at 1:58 PM, Neil Richards wrote: >> On Tue, 2012-07-17 at 08:21 +0200, Thomas St?fe wrote: >>> Hi Neil, >>> >>> > >>> > On AIX, CPPFLAGS is used for invocations of the C++ compiler (the 'PP' >>> > standing for 'Plus-Plus'). >>> > >>> > On Linux, CPPFLAGS is for the C Pre-Processor, and so is used for >>> > invocations of both the C and C++ compilers. >>> > (Linux has CXXFLAGS for C++-specific options). >>> > >>> > So, on Linux, adding to CPPFLAGS_COMMON should cater for both scenarios, >>> > I believe, whilst on AIX, one needs to add to both CPPFLAGS_COMMON and >>> > CFLAGS_COMMON. >>> >>> Are you sure this is right? I could not find any documentation for >>> that, e.g. on the xlC manuals. >>> >>> Reason I ask is I always thought both CXXFLAGS and CPPFLAGS originally >>> came from the GNU automake toolchain, and that what you describe as >>> "the Linux way" is just the correct way to use those variables - but >>> that many people use CPPFLAGS as "C++-Flags" because that is the first >>> thing which comes to mind. >>> >>> I may be wrong. I think it's mostly all convention anyway, the only >>> tools I think do something with those variables are autoconf/automake. >>> >>> When working on the AIX port of the SAP JVM, we tried to keep the GNU >>> meaning of CPPFLAGS intact: CPPFLAGS for -D../-I.., CXXFLAGS/CFLAGS >>> for languange specific settings. However, this has the tendency to >>> detoriate, so you probably will find both meanings in the makefiles. >>> >>> Kind Regards, >>> Thomas Stuefe >>> SAP Germany >>> >> >> Hi Thomas, >> To be honest, I'm more certain on the Linux side of this story than I am >> on the AIX side. :-) >> >> When writing the reply, I did find some references via Google that >> seemed to confirm the AIX story I was spinning. Naturally, as I didn't >> take a note of them at that point, trying to track those references down >> again has proven elusive, thus casting doubt on their validity. >> >> Obviously, the use of these variables is controlled by the make >> environment, rather than the compiler, as it is the (potentially >> implicit) rules in the make system that use the variables (in whatever >> combination) to give command line options to the compiler. >> >> So, if/as it's GNU make being used on both systems, I suppose it makes >> sense its behaviour re. these variables should also be (made to be) >> similar. >> >> If this is the case, I'm hoping I'll see duplication of >> (-DUSE_PTHREADS) options when compiling C++ code (with Steve's change) >> on AIX. If I see that, I'll have confirmation as to what correction to >> Steve's change is necessary to bring the use of these variables into >> line (with the GNU make / autoconf / automake) norm. >> >> If that option isn't duplicated in the invocation of the C++ compiler on >> AIX, it may suggest there are other factors in play (eg. the implicit >> rule for C++ compilation is being overridden somewhere). In that case, >> I'll have to dig deeper to figure out what's going on. >> >> Regards, >> Neil >> >> -- >> Unless stated above: >> IBM email: neil_richards at uk.ibm.com >> IBM United Kingdom Limited - Registered in England and Wales with number 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> From luchsh at linux.vnet.ibm.com Mon Jul 23 01:17:58 2012 From: luchsh at linux.vnet.ibm.com (luchsh at linux.vnet.ibm.com) Date: Mon, 23 Jul 2012 08:17:58 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Expand conditional include in several more source files to not include Message-ID: <20120723081830.5A0A74719D@hg.openjdk.java.net> Changeset: 2b08753d69a8 Author: luchsh Date: 2012-07-23 16:12 +0800 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/2b08753d69a8 Expand conditional include in several more source files to not include link.h for AIX platform. ! src/solaris/native/sun/awt/fontpath.c ! src/solaris/native/sun/java2d/opengl/OGLFuncs_md.h ! src/solaris/native/sun/security/jgss/wrapper/NativeFunc.c ! src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c ! src/solaris/native/sun/security/smartcardio/pcsc_md.c From volker.simonis at gmail.com Mon Jul 23 05:36:37 2012 From: volker.simonis at gmail.com (volker.simonis at gmail.com) Date: Mon, 23 Jul 2012 12:36:37 +0000 Subject: hg: ppc-aix-port/jdk7u/hotspot: Re-enable the 'gamma' test at the end of the HotSpot build, but only for HotSpot based bootstrap JDKs. Message-ID: <20120723123643.F061C4719E@hg.openjdk.java.net> Changeset: d72dd66fdc3d Author: simonis Date: 2012-07-23 14:32 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/d72dd66fdc3d Re-enable the 'gamma' test at the end of the HotSpot build, but only for HotSpot based bootstrap JDKs. The 'gamma' launcher only works with HotSpot based bootstrap JDKs because it uses the freshly build libjvm.so in the context and together with the class library of the boot JDK which was used to build it. This combination will not work for other JDKs. ! make/linux/Makefile ! make/linux/makefiles/buildtree.make From goetz.lindenmaier at sap.com Thu Jul 26 05:25:15 2012 From: goetz.lindenmaier at sap.com (goetz.lindenmaier at sap.com) Date: Thu, 26 Jul 2012 12:25:15 +0000 Subject: hg: ppc-aix-port/jdk7u/hotspot: Improve adlc usability. Message-ID: <20120726122517.DA57447218@hg.openjdk.java.net> Changeset: 0fac608b90e1 Author: Goetz Lindenmaier Date: 2012-07-26 14:23 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/0fac608b90e1 Improve adlc usability. - Make adlc more stable, especially if parsing faulty ad files. - In some cases raise syntax errors instead of asserting. - Write more comments into generated files. - Make calls to node->format() more stable. - ... ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/archDesc.hpp ! src/share/vm/adlc/dfa.cpp ! src/share/vm/adlc/dict2.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/forms.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/main.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp From volker.simonis at gmail.com Thu Jul 26 09:03:56 2012 From: volker.simonis at gmail.com (volker.simonis at gmail.com) Date: Thu, 26 Jul 2012 16:03:56 +0000 Subject: hg: ppc-aix-port/jdk7u: 2 new changesets Message-ID: <20120726160356.955BC4721D@hg.openjdk.java.net> Changeset: cdab3bfb573b Author: simonis Date: 2012-07-26 17:58 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/cdab3bfb573b Updated README-ppc.html to reflect the current project status ! README-ppc.html Changeset: e0dcb402d603 Author: simonis Date: 2012-07-26 18:01 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/rev/e0dcb402d603 Added tag ppc-aix-port-b01 for changeset cdab3bfb573b ! .hgtags From volker.simonis at gmail.com Thu Jul 26 09:12:17 2012 From: volker.simonis at gmail.com (volker.simonis at gmail.com) Date: Thu, 26 Jul 2012 16:12:17 +0000 Subject: hg: ppc-aix-port/jdk7u/corba: Added tag ppc-aix-port-b01 for changeset 325250aef90a Message-ID: <20120726161220.6768C4721E@hg.openjdk.java.net> Changeset: eb74b48ce634 Author: simonis Date: 2012-07-26 18:04 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/eb74b48ce634 Added tag ppc-aix-port-b01 for changeset 325250aef90a ! .hgtags From volker.simonis at gmail.com Thu Jul 26 09:12:45 2012 From: volker.simonis at gmail.com (volker.simonis at gmail.com) Date: Thu, 26 Jul 2012 16:12:45 +0000 Subject: hg: ppc-aix-port/jdk7u/hotspot: Added tag ppc-aix-port-b01 for changeset d72dd66fdc3d Message-ID: <20120726161250.1CA6F4721F@hg.openjdk.java.net> Changeset: 9533d437f589 Author: simonis Date: 2012-07-26 18:09 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/9533d437f589 Added tag ppc-aix-port-b01 for changeset d72dd66fdc3d ! .hgtags From volker.simonis at gmail.com Thu Jul 26 09:13:43 2012 From: volker.simonis at gmail.com (volker.simonis at gmail.com) Date: Thu, 26 Jul 2012 16:13:43 +0000 Subject: hg: ppc-aix-port/jdk7u/jaxp: Added tag ppc-aix-port-b01 for changeset 15b71daf5e69 Message-ID: <20120726161347.1665C47220@hg.openjdk.java.net> Changeset: 8ecf5400bf7f Author: simonis Date: 2012-07-26 18:04 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxp/rev/8ecf5400bf7f Added tag ppc-aix-port-b01 for changeset 15b71daf5e69 ! .hgtags From volker.simonis at gmail.com Thu Jul 26 09:14:08 2012 From: volker.simonis at gmail.com (volker.simonis at gmail.com) Date: Thu, 26 Jul 2012 16:14:08 +0000 Subject: hg: ppc-aix-port/jdk7u/jaxws: Added tag ppc-aix-port-b01 for changeset 4325d1311d55 Message-ID: <20120726161413.AD26A47222@hg.openjdk.java.net> Changeset: dd26e20e0df8 Author: simonis Date: 2012-07-26 18:04 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jaxws/rev/dd26e20e0df8 Added tag ppc-aix-port-b01 for changeset 4325d1311d55 ! .hgtags From volker.simonis at gmail.com Thu Jul 26 09:14:49 2012 From: volker.simonis at gmail.com (volker.simonis at gmail.com) Date: Thu, 26 Jul 2012 16:14:49 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: Added tag ppc-aix-port-b01 for changeset 35172a51cc76 Message-ID: <20120726161521.5D3D047223@hg.openjdk.java.net> Changeset: 12dc35221407 Author: simonis Date: 2012-07-26 18:07 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/12dc35221407 Added tag ppc-aix-port-b01 for changeset 35172a51cc76 ! .hgtags From volker.simonis at gmail.com Thu Jul 26 09:16:37 2012 From: volker.simonis at gmail.com (volker.simonis at gmail.com) Date: Thu, 26 Jul 2012 16:16:37 +0000 Subject: hg: ppc-aix-port/jdk7u/langtools: Added tag ppc-aix-port-b01 for changeset e3eeee75b861 Message-ID: <20120726161643.3FDFF47224@hg.openjdk.java.net> Changeset: ed96856ec2d2 Author: simonis Date: 2012-07-26 18:08 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/ed96856ec2d2 Added tag ppc-aix-port-b01 for changeset e3eeee75b861 ! .hgtags