RFR (M): 8036767 PPC64: Support for little endian execution model

Volker Simonis volker.simonis at gmail.com
Wed Mar 26 09:21:08 UTC 2014

On Wed, Mar 26, 2014 at 8:07 AM, Magnus Ihse Bursie
<magnus.ihse.bursie at 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


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-patches at 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_RELEASE = 3.2.0-60-generic
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
does indeed recognize ppc64le.

So I'd suggest we just check in this new version for the current

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


> /Magnus
>> On 26 mar 2014, at 01:00, Vladimir Kozlov <vladimir.kozlov at 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.holmes at 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.lindenmaier at 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

More information about the hotspot-dev mailing list