Hi Erik, as Vladimir explained, we have a special staging repository for our PPC64/AIX port:
I would be happy if you could push the changes right into the build-infra repositories and we will then get them into our staging repository via jdk8/jdk8. Otherwise I'll have to push them to our staging repository and later when the whole port is completed in the staging repo they will be bulk-integrated into jdk8. What do you think? Regards, Volker On Wed, Jun 26, 2013 at 6:53 PM, Vladimir Kozlov <[email protected] > wrote: > Erik, > > We have special staging forest for PPC64/AIX port: > > http://hg.openjdk.java.net/**ppc-aix-port/stage<http://hg.openjdk.java.net/ppc-aix-port/stage> > > We collect Hotspot and JDK changes there for testing before pushing into > main sources in a future. But some general fixes we push directly into our > main sources. > If you think these build changes are acceptable for main, please, ask > someone sponsor these changes. > > Alan is our official contact for PPC64/AIX project. I CC him. > > Thanks, > Vladimir > > > On 6/26/13 8:56 AM, Erik Joelsson wrote: > >> Hello, >> >> If you by staging area mean the build-infra forest, that's more or less >> dead now. >> >> I think these changes look good now (both top level and jdk). It should >> be fine to push this to jdk8/build. >> >> /Erik >> >> On 2013-06-26 17:28, Volker Simonis wrote: >> >>> Hi Erik, >>> >>> thank you for looking at this. I've prepared a new webrev at: >>> >>> http://cr.openjdk.java.net/~**simonis/webrevs/8017568_jdk/<http://cr.openjdk.java.net/~simonis/webrevs/8017568_jdk/> >>> <http://cr.openjdk.java.net/%**7Esimonis/webrevs/8017568_jdk/<http://cr.openjdk.java.net/%7Esimonis/webrevs/8017568_jdk/> >>> **> >>> >>> >>> What do you think, do you want to push this directly into the build >>> repositories or should I push it into the staging repository first? >>> >>> Please see my further comments inline. >>> >>> Thank you and best regards, >>> Volker >>> >>> On Tue, Jun 25, 2013 at 12:41 PM, Erik Joelsson >>> <[email protected] >>> <mailto:erik.joelsson@oracle.**com<[email protected]>>> >>> wrote: >>> >>> >>> On 2013-06-25 12:27, Erik Joelsson wrote: >>> >>> Hello Volker, >>> >>> On 2013-06-24 19:23, Volker Simonis wrote: >>> >>> Hi, >>> >>> could somebody please review the following change and >>> create an appropriate >>> Bug ID for it: >>> >>> http://cr.openjdk.java.net/~**simonis/webrevs/linux_ppc_** >>> build_jdk/<http://cr.openjdk.java.net/~simonis/webrevs/linux_ppc_build_jdk/> >>> <http://cr.openjdk.java.net/%**7Esimonis/webrevs/linux_ppc_* >>> *build_jdk/<http://cr.openjdk.java.net/%7Esimonis/webrevs/linux_ppc_build_jdk/> >>> > >>> >>> >>> The patch contains two little changes which are required >>> to build the class >>> library part of the OpenJDK on Linux/PPC64. Most of the >>> build magic is >>> contained in the top-level part of this change which is >>> separately reviewed >>> at >>> http://cr.openjdk.java.net/~**simonis/webrevs/linux_ppc_** >>> build_top<http://cr.openjdk.java.net/~simonis/webrevs/linux_ppc_build_top> >>> <http://cr.openjdk.java.net/%**7Esimonis/webrevs/linux_ppc_* >>> *build_top<http://cr.openjdk.java.net/%7Esimonis/webrevs/linux_ppc_build_top> >>> > >>> >>> CompileLaunchers.gmk >>> >>> Remove mapfile from build instructions of BUILD_UNPACKEXE: >>> >>> CFLAGS_macosx:=-fPIC, \ >>> - >>> MAPFILE:=$(JDK_TOPDIR)/**makefiles/mapfiles/libunpack/** >>> mapfile-vers-unpack200,\ >>> LDFLAGS:=$(UNPACKEXE_ZIPOBJS),**\ >>> >>> I think it makes no sense to use a version script file >>> for an executable >>> and older linkers (e.g. on SLES 10) complain with: >>> "*Invalid version tag >>> `SUNWprivate_1.1'. Only anonymous version tag is allowed >>> in executable.*" >>> The GNU ld >>> manual<http://ftp.gnu.org/old-**gnu/Manuals/ld-2.9.1/html_** >>> node/ld_25.html<http://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_25.html> >>> >states: >>> "*Version scripts are only meaningful when creating shared >>> libraries.*" >>> Morover unpack200 was the only executable which used a >>> version script file. >>> >>> Unpackexe has some weirdness and this isn't surprising me. >>> Would be good if someone with more historic knowledge could >>> fill in on the reason for this. Someone apparently went >>> through the trouble of creating a special mapfile for this >>> executable. Also, if not using it, should it be removed? >>> >>> I looked closer at this. These mapfiles were explicitly added in >>> >>> http://bugs.sun.com/view_bug.**do?bug_id=7033954<http://bugs.sun.com/view_bug.do?bug_id=7033954>, >>> but it was noted >>> that it broke builds for architectures that didn't have mapfiles >>> defined. If you look at the launchers, the mapfile is only set if >>> the arch specific one exists. I think a safer change here would be >>> to make the mapfile conditional on platform or arch for unpackexe. >>> >>> >>> I still do not fully understand why we need map-files for executables, >>> but I also understand that you don't want to change the current setup. >>> So I went the hard (and hopefully right:) way and implemented a >>> detection of the buggy linkers on older SuSE distros (e.g. on SLES 10) >>> which complain with: "Invalid version tag `SUNWprivate_1.1' during >>> the configure step (see top-level change). Unfortunately we still have >>> quite a lot of these systems so we really need the build with that >>> buggy ld. >>> >>> I've therefore added map files with anonymous version tags for these >>> buggy linkers which are only used if the buggy linker was detected >>> during the configure step (i.e. if USING_BROKEN_SUSE_LD=yes). Notice >>> that this is no PPC64 specific problem but a occurs on all SuSE 10 >>> platforms. >>> >>> And you've been right. I also had to add the arch specific map files >>> for ppc64 in order to use them for the other launchers. >>> >>> Kumar, you made the change referred to here, do you have anything >>> to add? >>> >>> /Erik >>> >>> Fix typo (replace 'defalt: all' by 'default') >>> >>> default: all >>> >>> CompileNativeLibraries.gmk >>> >>> Only use $(OPENWIN_LIB) for linking LIBSPLASHSCREEN on >>> Solaris! The old >>> code worked only accidentally when the X-libraries are in >>> the default >>> linker path anyway. The right solution is to use $(X_LIBS) >>> if not on >>> Windows or Solaris. >>> >>> Append -DX_ARCH=X_PPC64 to LIBJSOUND_CFLAGS on PPC64. >>> The value of >>> X_ARCHisn't actually used on the PPC architectures, but >>> there's a >>> check to verify >>> that it is set. >>> >>> Fix typo (replace 'defalt: all' by 'default') >>> >>> default: all >>> >>> >>> Otherwise looks good. >>> >>> /Erik >>> >>> >>>
