RFR (XS): Enable new build on Linux/PPC64 (jdk part)

Erik Joelsson erik.joelsson at oracle.com
Tue Jun 25 10:41:48 UTC 2013


On 2013-06-25 12:27, Erik Joelsson 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:
>>
>> 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?
I looked closer at this. These mapfiles were explicitly added in 
http://bugs.sun.com/view_bug.do?bug_id=7033954, but it was noted that it 
broke builds for architectures that didn't have mapfiles defined. If you 
look at the launchers, the mapfile is only set if the arch specific one 
exists. I think a safer change here would be to make the mapfile 
conditional on platform or arch for unpackexe.

Kumar, you made the change referred to here, do you have anything to add?

/Erik
>> 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
>



More information about the build-dev mailing list