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

Volker Simonis volker.simonis at gmail.com
Fri Jun 28 00:04:50 PDT 2013 

Ok, that's fine.

Could you please let me know when you've verified these changes. I
will then push them to the staging repository.


Regards,
Volker


On Thu, Jun 27, 2013 at 7:35 PM, Vladimir Kozlov
<vladimir.kozlov at oracle.com> wrote:
> On 6/27/13 10:16 AM, Iris Clark wrote:
>>
>> Hi, Volker.
>>
>> I think that the right thing for this change [1] is for you to push into
>> ppc-aix-port/stage once you get the necessary reviews (presumably Erik and
>> possibly Alan).  While your changeset contains some general purpose updates,
>> it also contains PPC/AIX-specific files which can't be added to a JDK
>> release repository until stage is pushed into the a JDK release.
>>
>> The recommendation to push to stage of course assumes that Vladimir
>> doesn't think that this will adversely affect the Hotspot work already being
>> pushed to stage.
>
>
> This should not affect Hotspot in stage repo. Me or Albert will do JPRT
> bootstrap control build of jdk with this changes to make sure it works.
> After that Volker can push it into stage.
>
> When I talked about pushing *general* changes into main sources I meant
> changes with no ppc64 specific code. The example of such changes was recent
> Goetz's fix for '8017531: 8010460 changes broke bytecodeInterpreter.cpp'.
>
> Thanks,
> Vladimir
>
>
>>
>> Thanks,
>> iris
>>
>> [1]: http://cr.openjdk.java.net/~simonis/webrevs/8017568_jdk/
>>
>> -----Original Message-----
>> From: Volker Simonis [mailto:volker.simonis at gmail.com]
>> Sent: Thursday, June 27, 2013 9:23 AM
>> To: Erik Joelsson
>> Cc: Kumar Srinivasan; build-dev; ppc-aix-port-dev at openjdk.java.net; Alan
>> Bateman
>> Subject: Re: RFR (XS): Enable new build on Linux/PPC64 (jdk part)
>>
>> Hi Erik,
>>
>> we have no polices which are carved in stone:) It's all done informally
>> and by common sense.
>>
>> The main reason for the ppc-aix-port/stage repository is to have a sandbox
>> for in-depth review and testing of changes we had to make in shared code
>> before pushing them to the main repository (and this especially applies to
>> hotspot changes). If you feel comfortable with the current changes and don't
>> think that they will break anything (e.g. by running tests build on your
>> supported platforms including the closed source ones) I'd really appreciate
>> if you could push them to the build repository.
>>
>> Otherwise I'll push them to the staging repository and you'll get them
>> once we're finished with the integration of the port.
>>
>> Thank you and best regards,
>> Volker
>>
>> On Thu, Jun 27, 2013 at 1:51 PM, Erik Joelsson <erik.joelsson at oracle.com>
>> wrote:
>>>
>>>
>>>
>>> On 2013-06-27 13:00, Volker Simonis wrote:
>>>
>>>
>>>
>>>
>>> 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.
>>>
>>> Several of the general fixes in there are good and I don't want to
>>> hinder those getting in. I also don't want to break policies I'm not
>>> familiar with.
>>>
>>> /Erik
>>>
>>> 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
>>>>>>>
>>>>>>>
>>>>
>>>
>

More information about the ppc-aix-port-dev mailing list