RFR (M): 8036767 PPC64: Support for little endian execution model
volker.simonis at gmail.com
Thu Mar 27 11:40:07 UTC 2014
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.
> 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>
>>> 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
>>> 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
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?
>>> I agree that long term, updating these files from the source is the
>>> 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
>>>> I agree.
>>>> Magnus, would you like me to do this?
More information about the hotspot-dev