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