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

[David Holmes]

Hi Volker,

This seems okay to me.

The CFLAGS -m64 bit seems unfortunately messy for you, but I don't think 
we've encountered a 64-bit platform where the compiler builds 32-bit by 
default. :( Hopefully this can be cleaned up.

Just in case it hasn't been noticed, please note that INCLUDE_SA only 
controls whether or not sa-jdi.jar gets copied into the final image. It 
doesn't get passed through to the hotspot build to control whether the 
SA is indeed built or not. (In fact hotspot doesn't have a single 
variable to control this as the sa-jdi.jar can be built even if there is 
no native support built via saproc :( ).

David

On 27/06/2013 1:28 AM, Volker Simonis wrote:
> 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
>>