On Wed, Mar 26, 2014 at 8:07 AM, Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com> wrote: > I have not seen it before, but that webrev contains a modification of > autoconf-config.guess, which is not okay. That file is copied directly from > the autoconf project and should not be modified. > > If that script is not working properly, a correction can be made in the > config.guess wrapper. See existing code there for how it can be done. >
We could do that, but I think that would be an ugly hack. I'm not sure what the current autoconf-config.guess actually returns for ppc64le-linux, but from a quick hack (i.e. changing uname to return 'ppc64le' if given the '-m' option) I can see that it returns an emtpy string and writes an error text to stderr: ========================================================== common/autoconf/build-aux/config.guess: unable to guess system type This script, last modified 2012-02-10, has failed to recognize the operating system you are using. It is advised that you download the most up to date version of the config scripts from http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD and http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD If the version you run (common/autoconf/build-aux/config.guess) is already up to date, please send the following data and any information you think might be pertinent to <config-patc...@gnu.org> in order to provide the needed information to handle your system. config.guess timestamp = 2012-02-10 uname -m = ppc64le uname -r = 3.2.0-60-generic uname -s = Linux uname -v = #91-Ubuntu SMP Wed Feb 19 03:54:44 UTC 2014 /usr/bin/uname -p = /bin/uname -X = hostinfo = /bin/universe = /usr/bin/arch -k = /bin/arch = /usr/bin/oslevel = /usr/convex/getsysinfo = UNAME_MACHINE = ppc64le UNAME_RELEASE = 3.2.0-60-generic UNAME_SYSTEM = Linux UNAME_VERSION = #91-Ubuntu SMP Wed Feb 19 03:54:44 UTC 2014 ================================================================== We could of course handle that, but I think it would be a bad idea to treat every unrecognized system as 'ppc64le'. I've checked that the latest config.guess (from http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD) does indeed recognize ppc64le. So I'd suggest we just check in this new version for the current common/autoconf/build-aux/config.guess. It is by far the cleanest solution and it shouldn't do any harm for the few platforms we support (and it additionally can detect mingw-64 which may be interesting for our MinGW experiments). What do you think? Regards, Volker > /Magnus > >> On 26 mar 2014, at 01:00, Vladimir Kozlov <vladimir.koz...@oracle.com> wrote: >> >> I mean build changes in top directory: >> >> http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.01/ >> >> Thanks, >> Vladimir >> >>> On 3/25/14 4:18 PM, Vladimir Kozlov wrote: >>> I assume jdk changes are reviewed by Magnus. Please, confirm. >>> >>> Changes require a regeneration of generated-configure.sh files. >>> >>> I am going to push jdk(top) changes into jdk9/hs-comp and will ask >>> gatekeepers to push it up later. >>> >>> JDK control build testing is running in JPRT now. >>> >>> Thanks, >>> Vladimir >>> >>>> On 3/25/14 12:41 PM, Vladimir Kozlov wrote: >>>> I will push changes from webrev.05 into hs-comp/hotspot >>>> >>>> Where I should push jdk changes (jdk9/dev/ or hs-comp)?: >>>> >>>> http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.01/ >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> On 3/25/14 3:32 AM, David Holmes wrote: >>>>> Thanks. Build side looks fine to me. >>>>> >>>>> David >>>>> >>>>>> On 25/03/2014 6:09 AM, Alexander Smundak wrote: >>>>>> Done. Uploaded >>>>>> http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.05 >>>>>> >>>>>> On Sun, Mar 23, 2014 at 8:37 PM, David Holmes >>>>>> <david.hol...@oracle.com> wrote: >>>>>>> On 22/03/2014 10:47 AM, Alexander Smundak wrote: >>>>>>>> >>>>>>>> On Fri, Mar 21, 2014 at 2:55 PM, Lindenmaier, Goetz >>>>>>>> <goetz.lindenma...@sap.com> wrote: >>>>>>>>> >>>>>>>>> My build ran into the 'little' case below, as I understand because >>>>>>>>> ' big' >>>>>>>>> was compared >>>>>>>>> with 'big'. Make is strange ... >>>>>>>> >>>>>>>> >>>>>>>> Removed the spaces, please take a look at >>>>>>>> http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.04 >>>>>>> >>>>>>> >>>>>>> Stylistically the hotspot makefiles test a variable/expression >>>>>>> against a >>>>>>> value/constant not the other way around. So: >>>>>>> >>>>>>> ifeq (undefined,$(origin OPENJDK_TARGET_CPU_ENDIAN)) >>>>>>> >>>>>>> becomes >>>>>>> >>>>>>> ifeq ($(origin OPENJDK_TARGET_CPU_ENDIAN),undefined) >>>>>>> >>>>>>> and the same for all the other comparisons you have added. >>>>>>> >>>>>>> >>>>>>> Sorry. >>>>>>> >>>>>>> David >>>>>>>
