RFR (XS): Enable new build on Linux/PPC64 (jdk part)
Volker Simonis
volker.simonis at gmail.com
Thu Jun 27 04:00:31 PDT 2013
On Thu, Jun 27, 2013 at 12:16 PM, Erik Joelsson <erik.joelsson at oracle.com>wrote:
> **
> Hello Volker,
>
> I wasn't aware of this project until now. From what I (now) understand,
> generic patches can go into jdk8 repos, but port specific things need to go
> to staging and go in with the rest later. These changes contain a couple of
> port specific things so as it looks now they would need to go through
> staging.
>
>
Yes, that's the general approach. But I'd argue that for the most part this
changes are generic (enable CPP-interpreter, enable CORE build, fix for
broken ld on SuSE, replacing OPENWIN_LIB by X_LIB, fix typos) with only
very few PPC64 specific parts (map-files and a few defines). The problem we
want to avoid is that some of our fixes go into the main repositories in
parallel which would result in merging pain when integrating the staging
into the main repository.
So if you think you don't need any of the general fixes any time soon, I'll
push the changes into the staging repository. Otherwise I think it would be
better to push them right into the main repositories.
Thanks,
Volker
> /Erik
>
>
> On 2013-06-27 12:03, Volker Simonis wrote:
>
> Hi Erik,
>
> as Vladimir explained, we have a special staging repository for our
> PPC64/AIX port:
>
> I would be happy if you could push the changes right into the
> build-infra repositories and we will then get them into our staging
> repository via jdk8/jdk8.
>
> Otherwise I'll have to push them to our staging repository and later
> when the whole port is completed in the staging repo they will be
> bulk-integrated into jdk8.
>
> What do you think?
>
> Regards,
> Volker
>
>
> On Wed, Jun 26, 2013 at 6:53 PM, Vladimir Kozlov <
> vladimir.kozlov at oracle.com> wrote:
>
>> Erik,
>>
>> We have special staging forest for PPC64/AIX port:
>>
>> http://hg.openjdk.java.net/ppc-aix-port/stage
>>
>> We collect Hotspot and JDK changes there for testing before pushing into
>> main sources in a future. But some general fixes we push directly into our
>> main sources.
>> If you think these build changes are acceptable for main, please, ask
>> someone sponsor these changes.
>>
>> Alan is our official contact for PPC64/AIX project. I CC him.
>>
>> Thanks,
>> Vladimir
>>
>>
>> On 6/26/13 8:56 AM, Erik Joelsson wrote:
>>
>>> Hello,
>>>
>>> If you by staging area mean the build-infra forest, that's more or less
>>> dead now.
>>>
>>> I think these changes look good now (both top level and jdk). It should
>>> be fine to push this to jdk8/build.
>>>
>>> /Erik
>>>
>>> On 2013-06-26 17:28, Volker Simonis wrote:
>>>
>>>> Hi Erik,
>>>>
>>>> thank you for looking at this. I've prepared a new webrev at:
>>>>
>>>> http://cr.openjdk.java.net/~simonis/webrevs/8017568_jdk/
>>>> <http://cr.openjdk.java.net/%7Esimonis/webrevs/8017568_jdk/>
>>>>
>>>>
>>>> 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 my further comments inline.
>>>>
>>>> Thank you and best regards,
>>>> Volker
>>>>
>>>> On Tue, Jun 25, 2013 at 12:41 PM, Erik Joelsson
>>>> <erik.joelsson at oracle.com <mailto:erik.joelsson at oracle.com>> wrote:
>>>>
>>>>
>>>> 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/
>>>> <
>>>> http://cr.openjdk.java.net/%7Esimonis/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
>>>> <
>>>> http://cr.openjdk.java.net/%7Esimonis/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.
>>>>
>>>>
>>>> I still do not fully understand why we need map-files for executables,
>>>> but I also understand that you don't want to change the current setup.
>>>> So I went the hard (and hopefully right:) way and implemented a
>>>> detection of the buggy linkers on older SuSE distros (e.g. on SLES 10)
>>>> which complain with: "Invalid version tag `SUNWprivate_1.1' during
>>>> the configure step (see top-level change). Unfortunately we still have
>>>> quite a lot of these systems so we really need the build with that
>>>> buggy ld.
>>>>
>>>> I've therefore added map files with anonymous version tags for these
>>>> buggy linkers which are only used if the buggy linker was detected
>>>> during the configure step (i.e. if USING_BROKEN_SUSE_LD=yes). Notice
>>>> that this is no PPC64 specific problem but a occurs on all SuSE 10
>>>> platforms.
>>>>
>>>> And you've been right. I also had to add the arch specific map files
>>>> for ppc64 in order to use them for the other launchers.
>>>>
>>>> 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
>>>>
>>>>
>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20130627/2d7170a2/attachment-0001.html
More information about the ppc-aix-port-dev
mailing list