Hi Erik, thanks for the BugID!
Here's the new webrev: http://cr.openjdk.java.net/~simonis/webrevs/8017568_toplevel I've added a detection for buggy linkers on older SuSE distros (e.g. on SLES 10) which complains with: "Invalid version tag `SUNWprivate_1.1'. Only anonymous version tag is allowed in executable." if feeded with a version script which contains named tags. If detected this will be exported as USING_BROKEN_SUSE_LD=yes for the jdk build. 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 further comments inline. Thank you and best regards, Volker On Tue, Jun 25, 2013 at 12:21 PM, Erik Joelsson <erik.joels...@oracle.com>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: >> >> Created 8017568: Enable new build on Linux/PPC64 > You can use it for both root and jdk changes. > >> http://cr.openjdk.java.net/~**simonis/webrevs/linux_ppc_**build_top/<http://cr.openjdk.java.net/~simonis/webrevs/linux_ppc_build_top/> >> >> The change will enable to build the PowerPC/AIX port on Linux/PPC64 with >> the new build system using an interpreter only VM using the C++ >> interpreter. Therefore it introduces a new JVM variant called "core" which >> enables an interpreter only build and a new configure option called >> "--with-jvm-interpreter" which can be used to choose either the default >> "template" interpreter or the "C++" interpreter. >> >> Notice that this 'core' build currently only works on Linux/PPC64 and it >> is >> used for the PowerPC/AIX porting project to bootstrap its build. (See >> 8016476: >> PPC64 (part 1): reenable CORE >> build<http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=8016476<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016476> >> >for >> >> the corresponding HotSpot change). >> >> Once we have all the required patches in the HotSpot repository (and the >> small JDK changes from >> http://cr.openjdk.java.net/~**simonis/webrevs/linux_ppc_**build_jdk<http://cr.openjdk.java.net/~simonis/webrevs/linux_ppc_build_jdk>), >> building >> on newer Linux distros like Fedora 17 will be as easy as: >> >> sh /priv/openjdk/OpenJDK/ppc-aix-**port/jdk8/configure >> --with-boot-jdk=/priv/openjdk/**OpenJDK/openjdk1.7.0-ppc-aix-**port-b03 >> --with-jvm-variants=core --with-jvm-interpreter=cpp >> --with-debug-level=slowdebug >> >> make images LOG=debug >> >> On older releases like SLES 10 you'll have to use something like: >> >> sh /priv/openjdk/OpenJDK/ppc-aix-**port/jdk8/configure --with-boot-jdk= >> /priv/openjdk/OpenJDK/**openjdk1.7.0-ppc-aix-port-b03-** >> -with-jvm-variants=core >> --with-jvm-interpreter=cpp--**with-debug-level=release >> --with-extra-cflags=-m64 >> --with-extra-cxxflags=-m64 --with-extra-ldflags='-m64 -L/lib64' >> --x-libraries=/usr/X11R6/lib64 --x-includes=/usr/X11R6/**include >> CFLAGS=-m64 >> CXXFLAGS=-m64 >> >> make images LOG=debug >> >> The extra options and flags are mainly necessary because the GCC on the >> latter platform produces 32-bit binaries by default. Notice that the >> environment variables "CFLAGS=-m64 CXXFLAGS=-m64" are necessary for the >> configure script itself to detect the correct 64-bit platform while the >> configure options like "--with-extra-cflags" are needed in order to select >> the right flags for the build. >> > This should be addressed I think. I'm not happy with the current handling > of CFLAGS*, CXXFLAGS* and LDFLAGS*. But not in this patch. > Yes, I didn't change anything here, I just wanted to explain the command line and why both, "--with-extra-cflags" and CFLAGS are necessary. Following some more detailed descriptions of the change: >> common/autoconf/boot-jdk.m4 >> >> Linux/PPC64 needs a slightly bigger heap for the huge JDK batch. Treat it >> like MacOS which uses '-Xmx1600M'. >> common/autoconf/configure.ac >> common/autoconf/hotspot-spec.**gmk.in <http://hotspot-spec.gmk.in> >> common/autoconf/jdk-options.m4 >> >> Add --with-interpreter option to configure which can be used th choose one >> of the 'template' or the 'C++' interpreter. Default is the 'template' >> interpreter. >> common/autoconf/jdk-options.m4 >> common/autoconf/spec.gmk.in >> make/hotspot-rules.gmk >> >> Add JVM variant 'core' to configure which can be used th choose the >> HotSpot >> 'core' (i.e. 'interpreter only') build. Notice that this 'core' build >> currently only works on Linux/PPC64 and it is used for the PowerPC/AIX >> porting project to bootstrap its build. (See 8016476: PPC64 (part 1): >> reenable CORE build<http://bugs.sun.com/**bugdatabase/view_bug.do?bug_** >> id=8016476 <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016476> >> >for >> >> the corresponding HotSpot change). >> >> We currently also don't build the serviceability agent on PPC64. >> common/autoconf/libraries.m4 >> >> Older Linuxes (e.g. SLES 10) may still have the X11R6 directory but also a >> symlink from /usr/include/X11 to ../X11R6/include/X11 so we need to check >> for the X11R6 directory AFTER we checked for /usr/include/X11 >> Thank you and best regards, >> > Note that this last part won't apply cleanly after some recent changes. > > The good news here is that the recent change which broke my patch also fixed my problem, so this part isn't necessary any more! > Why change make/hotspot-rules.gmk? It's only used in the old build. > Otherwise this all looks good to me from a build perspective. > You're right, that was an leftover in the patch from the old build system. I've removed it. > /Erik >
