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 <[email protected]> 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:[email protected]] >> Sent: Thursday, June 27, 2013 9:23 AM >> To: Erik Joelsson >> Cc: Kumar Srinivasan; build-dev; [email protected]; 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 <[email protected]> >> wrote: >>> >>> >>> >>> On 2013-06-27 13:00, Volker Simonis wrote: >>> >>> >>> >>> >>> On Thu, Jun 27, 2013 at 12:16 PM, Erik Joelsson >>> <[email protected]> >>> 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 >>>> <[email protected]> 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 >>>>>>> <[email protected] <mailto:[email protected]>> 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 >>>>>>> >>>>>>> >>>> >>> >
