RFR (XXS) [URGENT]: 8048232: Fix for 8046471 breaks PPC64 build

[Volker Simonis]

Hi Mikael,

thanks for reviewing at the change.

Can I please have one more reviewer/sponsor for this tiny change?

Thanks,
Volker


On Tue, Jul 1, 2014 at 2:11 AM, Mikael Vidstedt
<mikael.vidstedt at oracle.com> wrote:
>
> Looks good.
>
> Cheers,
> Mikael
>
>
> On 2014-06-30 07:28, Volker Simonis wrote:
>>
>> Can somebody please review and push this small build change to fix our
>> ppc64 build errors.
>>
>> Thanks,
>> Volker
>>
>> On Fri, Jun 27, 2014 at 5:48 PM, Volker Simonis
>> <volker.simonis at gmail.com> wrote:
>>>
>>> On Thu, Jun 26, 2014 at 10:59 PM, Volker Simonis
>>> <volker.simonis at gmail.com> wrote:
>>>>
>>>>
>>>> On Thursday, June 26, 2014, Mikael Vidstedt <mikael.vidstedt at oracle.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> This will work for top level builds. For Hotspot-only builds ARCH will
>>>>> (still) be the value of uname -m, so if you want to support
>>>>> Hotspot-only
>>>>> builds you'll probably want to do the "ifneq (,$(findstring $(ARCH),
>>>>> ppc))"
>>>>> trick to catch both "ppc" (which is what a top level build will use)
>>>>> and
>>>>> "ppc64" (for Hotspot-only).
>>>>>
>>>> Hi Mikael,
>>>>
>>>> yes you're right.
>>>
>>> I have to correct myself - you're nearly right:)
>>>
>>> In the term "$(findstring $(ARCH), ppc)" '$ARCH' is the needle and
>>> 'ppc is the stack, so it won't catch 'ppc64' either. I could write
>>> "$(findstring ppc, $(ARCH))" which would catch both, 'ppc' and 'ppc64'
>>> but I decided to use the slightly more verbose "$(findstring $(ARCH),
>>> ppc ppc64)" because it seemed clearer to me. I also added a comment to
>>> explain the problematic of the different ARCH values for top-level and
>>> HotSpot-only builds. Once we have the new HS build, this can hopefully
>>> all go away.
>>>
>>> By, the way, I also had to apply this change to your ppc-modifications
>>> in make/linux/makefiles/defs.make. And I think that the same reasoning
>>> may also apply to "$(findstring $(ARCH), sparc)" which won't catch
>>> 'sparc64' any more after your change but I have no Linux/SPARC box to
>>> test this. You may change it accordingly at your discretion.
>>>
>>> So here's the new webrev:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/8048232.v2/
>>>
>>> Please review and sponsor:)
>>>
>>> Thank you and best regards,
>>> Volker
>>>
>>>> I only tested a complete make but I indeed want to support
>>>> HotSpot only makes as well. I'll change it as requested although I won't
>>>> have chance to do that before tomorrow morning (European time).
>>>>
>>>> Thanks you and best regards,
>>>> Volker
>>>>
>>>>> Sorry for breaking it.
>>>>>
>>>>> Cheers,
>>>>> Mikael
>>>>>
>>>>> PS. We so need to clean up these makefiles...
>>>>>
>>>>> On 2014-06-26 07:25, Volker Simonis wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> could somebody please review and push the following tiny change:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8048232/
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8048232
>>>>>>
>>>>>> It fixes the build on Linux/PPC64 after "8046471 Use
>>>>>> OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH".
>>>>>>
>>>>>> Before 8046471, the top-level make passed ARCH=ppc64 to the HotSpot
>>>>>> make. After 8046471, it now passes ARCH=ppc. But there was one place
>>>>>> in  make/linux/Makefile which checked for ARCH=ppc64 in order to
>>>>>> disable the TIERED build. This place has to be adapted to handle the
>>>>>> new ARCH value.
>>>>>>
>>>>>> Please push this right to http://hg.openjdk.java.net/jdk9/hs/hotspot
>>>>>> in order to get it into http://hg.openjdk.java.net/jdk9/dev/hotspot
>>>>>> together with 8046471.
>>>>>>
>>>>>> Note: this change depends on 8046471 in the hotspot AND in the
>>>>>> top-level directory!
>>>>>>
>>>>>> Thank you and best regards,
>>>>>> Volker
>>>>>
>>>>>
>