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

[Alexander Smundak]

I have uploaded a new revision which handler ppc64le in the
config.guess wrapper:
http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.02/

On Thu, Mar 27, 2014 at 4:40 AM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> On Thu, Mar 27, 2014 at 11:30 AM, Erik Joelsson
> <erik.joelsson at oracle.com> wrote:
>>
>>
>>
>>
>> For the approval. Is this for JDK9 only?
>>
>
> No, we want to bring this to jdk8 eventually.
>
>> /Erik
>>
>>
>> On 2014-03-27 09:36, Volker Simonis wrote:
>>>
>>> On Thu, Mar 27, 2014 at 9:05 AM, Erik Joelsson <erik.joelsson at oracle.com>
>>> wrote:
>>>>
>>>> There are unfortunately legal complications surrounding updating these
>>>> files. We can initiate the approval dance, but it will take time to go
>>>> through (weeks at least). This is the reason Magnus added the wrapper
>>>> around
>>>> config.guess, so that we could get functional updates to it faster.
>>>>
>>> OK, but as I wrote, config.guess currently only maps some recognized
>>> systems to different names. This case is different because for ppc64le
>>> the output of 'autoconf-config.guess' would be an emtpy string and a
>>> quite big error message on stderr. Do you really want that we make
>>> Linux/ppc64le the default fallback in config.guess if
>>> 'autoconf-config.guess' can not detect a system?
>>
>> Why does it need to be the only fallback? Couldn't you do some sanity uname
>> check as well?
>
> Sorry, you're right of course.
>
> @Sasha: could you please add something like:
>
>
> if [ "$OUT"x = ""x ]; then
>   if [ `uname -m` = "ppc64le" ]; then
>     OUT=ppc64le-unknown-linux-gnu
>   fi
> fi
>
> to the end of config.guess. That should do the job and it is probably
> the fastest solution for our problem.
>
> It may be also easier to downport this simple change to 8 compared to
> a completely new  version of 'autoconf-config.guess' (although I don't
> see a problem with that either).
>
>>
>>> Or should we exceptionally just patch 'autoconf-config.guess' if we
>>> know that we will update it anyway with a new version within a few
>>> weeks? I think I'd prefer this solution, because this is just one
>>> change which will be automatically removed once we integrate the new
>>> 'autoconf-config.guess' version. If we just hack 'config.guess' we
>>> would have to manually take that change back once we get the new
>>> 'autoconf-config.guess' version.
>>
>> It's unclear to us if we are allowed to make edits in these files.
>>
>> I also suspect that the current wrapper file would need to be changed after
>> an update anyway.
>
> I don't think so because as far as I can see, the new versions are
> backward compatible in the sense that they don't change existing
> platform strings. So the old mappings will have to be done with the
> new script in the same way.
>
>>
>>> In any case I'd kindly ask you to start the 'legal approval dance' :)
>>
>> Working on it. Is this for JDK9 only or are you planning backports?
>>
>> /Erik
>>
>>> Regards,
>>> Volker
>>>
>>>> I agree that long term, updating these files from the source is the
>>>> correct
>>>> action.
>>>>
>>>> /Erik
>>>>
>>>>
>>>> On 2014-03-26 23:47, Alexander Smundak wrote:
>>>>>
>>>>> On Wed, Mar 26, 2014 at 2:21 AM, Volker Simonis
>>>>> <volker.simonis at gmail.com> wrote:
>>>>>>
>>>>>> So I'd suggest we just check in this new version for the current
>>>>>> common/autoconf/build-aux/config.guess.
>>>>>
>>>>> I agree.
>>>>>
>>>>> Magnus, would you like me to do this?
>>>>
>>>>
>>