Ah, now I got it! The problem is with your closed sources which also have their own closed, autoconf-generated config file which has to be recreated after the OpenJDK autoconf-generated configure files changes.
The warning "Warning: The generated configure file contains changes not present in the custom generated file." from 'common/autoconf/configure:' actually checks exactly that: if test -e $conf_custom_script_dir/generated-configure.sh; then # Test if open configure is newer than custom configure, if so, custom needs to # be regenerated. This test is required to ensure consistency with custom source. conf_open_configure_timestamp=`grep DATE_WHEN_GENERATED= $conf_script_dir/generated-configure.sh | cut -d"=" -f 2` conf_custom_configure_timestamp=`grep DATE_WHEN_GENERATED= $conf_custom_script_dir/generated-configure.sh | cut -d"=" -f 2` if test $conf_open_configure_timestamp -gt $conf_custom_configure_timestamp; then echo "Warning: The generated configure file contains changes not present in the custom generated file." run_autogen_or_fail fi fi I obviously can not fix that:) But if you've already done a successful build on any other platform, you can just copy the generated '$conf_custom_script_dir/generated-configure.sh' from that build into you workspace and that should do the job! Very nasty Closedsource/JPRT problems:( When will we finally overcome this mess... Regards, Volker On Tue, Jul 2, 2013 at 10:42 AM, Volker Simonis <volker.simo...@gmail.com> wrote: > On Tue, Jul 2, 2013 at 9:56 AM, Vladimir Kozlov > <vladimir.koz...@oracle.com> wrote: >> JPRT uses own target to build forest: >> >> jprt_build_product: sanity all_product_build >> >> http://hg.openjdk.java.net/ppc-aix-port/stage/file/c156084add48/make/jprt.gmk >> >> That is why 'make sanity' is called I think. >> >> Note the next warning was present in JPRT logs on all platforms: >> >> Warning: The generated configure file contains changes not present in the >> custom generated file. >> >> I verified that submitted source common/autoconf/generated-configure.sh is >> matching file in stage repo plus changes from patch. >> >> Hmm, may be the problem is next change in generated-configure.sh: >> >> -DATE_WHEN_GENERATED=1371547824 >> +DATE_WHEN_GENERATED=1372238067 >> >> It is date when Volker generated generated-configure.sh but the date of >> changed .m4 files is when I applied patch which is later. It looks like I >> need to regenerate generated-configure.sh file myself as Erik said. I will >> give it a try tomorrow. >> > > I doubt that that's the only reason, because I did exactly the same > yesterday on MacOS without these problems: > - clone jdk8/jdk8 > - import the patches into the base and jdk repositroy > - configure > - make > > Is there a way I can simulate a JPRT build? > If I just call 'make jprt_build_product' in the build directory where > I have previously called 'configure' it fails because it wants to call > configure again and doesn't find it. > So from which directory am I supposed to start a JPRT build and which > parameters should I pass to it? > >> Vladimir >> >> >> On 7/2/13 12:31 AM, Volker Simonis wrote: >>> >>> Hi Erik, >>> >>> thank you for looking into this. >>> >>> On Tue, Jul 2, 2013 at 9:16 AM, Erik Joelsson <erik.joels...@oracle.com> >>> wrote: >>>> >>>> This looks like you have applied a change to configure input files (*.m4) >>>> and haven't regenerated configure locally afterwards. The JPRT machines >>>> don't have autoconf setup so they can't do it. In this case it looks like >>>> one of them, probably the mac, has a faulty version of autoconf that gets >>>> picked up. I have seen this happen before on mac. >>>> >>> >>> Actually, that was my guess as well. On the other hand that's still >>> strange, because my patch also contains an updated >>> 'common/autoconf/generated- >>> configure.sh' and it works on the other platforms (and also locally >>> for me on MacOS X) without regenerating it. I just saw that the mail I >>> wrote yesterday wasn't send to the lists so I quote my assumptions >>> here: >>> >>> ... >>> From your logs I only see that the make process does not find any >>> configuration, but the configuration should have been created by >>> running configure. Then it tries to call configure but doesn't succeed >>> because it says "The generated configure file contains changes not >>> present in the custom generated file." That's also strange because my >>> changesets also patch 'common/autoconf/generated- >>> configure.sh' so it should not be re-generated. And finally the build >>> fails because there's not autoconf on Windows and probably because the >>> autoconf on Mac is too old (the checked-in file is generated by >>> autoconf 2.8). >>> >>> I've just synced jdk8/jdk8 and applied the two patches. I could build >>> without any problems on MacOS X 10.8 with the following command line. >>> >>> sh /usr/work/d046063/OpenJDK/ppc-aix-port/stage/configure >>> --with-boot-jdk=<path_to>/darwinintel64/output/sapjvm_7 >>> --with-target-bits=64 --with-debug-level=release >>> >>> make images LOG=debug >>> >>> Attached you can find the output I get from running configure. >>> >>> Could you please retry one more time? If you still have problems, can >>> you please run configure by hand and post the output. >>> >>> PS: I also saw from your logs that '/usr/bin/make sanity' is called. >>> This also seems strange to me because I think there aren't any sanity >>> targets any more in the new build system. Maybe you have a mismatch >>> between old and new build system? >>> ... >>> >>> Erik, could you please try this locally on Mac or Windows and post you >>> findings. Alternatively, could you please explain post the complete >>> JPRT output and explain what JPRT is trying to do. From Vladimir's log >>> snippets it's hard for me t understand the whole picture. >>> >>> Thank you and best regards, >>> Volker >>> >>>> The fix is to execute "bash common/autoconf/autogen.sh" locally and then >>>> resubmit to jprt. You need to have autoconf version 2.67 or newer >>>> installed >>>> for it to work. >>>> >>>> /Erik >>>> >>>> >>>> On 2013-07-02 05:48, Vladimir Kozlov wrote: >>>>> >>>>> >>>>> Need help from JDK build experts. >>>>> >>>>> I applied next 2 changesets: >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/8017568_toplevel/ >>>>> http://cr.openjdk.java.net/~simonis/webrevs/8017568_jdk/ >>>>> >>>>> and got JPRT build problems (-control build) only on MacOS and Win64: >>>>> >>>>> >>>>> >>>>> http://bus2001067.us.oracle.com/archives/2013/06/2013-06-28-213927.vkozlov.ppc64_jdk_build_test/ >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> macosx_x64_10.7-product (details from log file) >>>>> >>>>> ... >>>>> >>>>> Warning: The generated configure file contains changes not present in >>>>> the >>>>> custom generated file. >>>>> Running autogen.sh to correct the situation >>>>> Autoconf found: /usr/bin/autoconf >>>>> Autoconf-2.67 found: >>>>> Generating generated-configure.sh with /usr/bin/autoconf >>>>> /usr/bin/gm4:stdin:187: bad expression in eval: 32 > <dynamic> >>>>> autom4te: /usr/bin/gm4 failed with exit status: 1 >>>>> Generating custom generated-configure.sh >>>>> /usr/bin/gm4:stdin:187: bad expression in eval: 32 > <dynamic> >>>>> autom4te: /usr/bin/gm4 failed with exit status: 1 >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> windows_x64_5.2-fastdebug (details from log file) >>>>> >>>>> ... >>>>> >>>>> Warning: The generated configure file contains changes not present in >>>>> the >>>>> custom generated file. >>>>> Error: Cannot continue >>>>> Cannot locate autoconf, unable to correct situation. >>>>> Please install autoconf and run 'bash autogen.sh' to update the >>>>> generated >>>>> files. >>>>> make: *** [bridge2configure] Error 1 >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> Without these changes the output is: >>>>> >>>>> Running custom generated-configure.sh >>>>> configure: Configuration created at Thu Jun 27 16:32:25 EDT 2013. >>>>> configure: configure script generated at timestamp 1371547939. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 6/28/13 12:04 AM, Volker Simonis wrote: >>>>>> >>>>>> >>>>>> 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.koz...@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.simo...@gmail.com] >>>>>>>> Sent: Thursday, June 27, 2013 9:23 AM >>>>>>>> To: Erik Joelsson >>>>>>>> Cc: Kumar Srinivasan; build-dev; ppc-aix-port-...@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.joels...@oracle.com> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2013-06-27 13:00, Volker Simonis wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Jun 27, 2013 at 12:16 PM, Erik Joelsson >>>>>>>>> <erik.joels...@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.koz...@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.joels...@oracle.com <mailto:erik.joels...@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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>> >>> >>