RFR (S): Enable new build on Linux/PPC64 (top-level part)

Volker Simonis volker.simonis at gmail.com
Wed Jun 26 15:28:12 UTC 2013

Hi Erik,

thanks for the BugID!

Here's the new webrev:


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
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,

On Tue, Jun 25, 2013 at 12:21 PM, Erik Joelsson <erik.joelsson at 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

More information about the build-dev mailing list