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:
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>states:
"*Version scripts are only meaningful when creating shared libraries.*"
Morover unpack200 was the only executable which used a version script file.
Unpackexe has some weirdness and this isn't surprising me. Would be good
if someone with more historic knowledge could fill in on the reason for
this. Someone apparently went through the trouble of creating a special
mapfile for this executable. Also, if not using it, should it be removed?
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
Otherwise looks good.
/Erik
