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

[Volker Simonis]

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