PPC64: Generic build preparations needed to enable new build on Linux/PPC64

Hi,

could somebody please review the following change and create an appropriate
Bug ID for it:

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&gt;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), 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.

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
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&gt;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,
Volker


could somebody please review the following change and create an appropriate
Bug ID for it:

http://cr.openjdk.java.net/~simonis/webrevs/linux_ppc_build_jdk/

The patch contains two little changes which are required to build the class
library part of the OpenJDK on Linux/PPC64. Most of the build magic is
contained in the top-level part of this change which is separately reviewed
at http://cr.openjdk.java.net/~simonis/webrevs/linux_ppc_build_top
CompileLaunchers.gmk

Remove mapfile from build instructions of BUILD_UNPACKEXE:

  CFLAGS_macosx:=-fPIC, \
- MAPFILE:=$(JDK_TOPDIR)/makefiles/mapfiles/libunpack/mapfile-vers-unpack200,\
  LDFLAGS:=$(UNPACKEXE_ZIPOBJS),\

 I think it makes no sense to use a version script file for an executable
and older linkers (e.g. on SLES 10) complain with: "*Invalid version tag
`SUNWprivate_1.1'. Only anonymous version tag is allowed in executable.*"
The GNU ld manual<http://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_25.html&gt;states:
"*Version scripts are only meaningful when creating shared libraries.*"
Morover unpack200 was the only executable which used a version script file.

Fix typo (replace 'defalt: all' by 'default')

default: all

CompileNativeLibraries.gmk

Only use $(OPENWIN_LIB) for linking LIBSPLASHSCREEN on Solaris! The old
code worked only accidentally when the X-libraries are in the default
linker path anyway. The right solution is to use $(X_LIBS) if not on
Windows or Solaris.

 Append -DX_ARCH=X_PPC64 to LIBJSOUND_CFLAGS on PPC64. The value of
X_ARCHisn't actually used on the PPC architectures, but there's a
check to verify
that it is set.

Fix typo (replace 'defalt: all' by 'default')

default: all

Thank you and best regards,
Volker