RFR (M): 8024265: Enable new build on AIX (top level part)

[David Holmes]

On 13/09/2013 10:33 AM, Vladimir Kozlov wrote:
> Done.
>
> I have to regenerate generated-configure.sh to sync times with closed
> version.
> I ran jdk control build in JPRTwith bootstap to verify that it is not
> broken. And I got jdk product build failure on linux-x64:
>
> /bin/sh:
> /opt/jprt/T/P1/193135.vkozlov/s/build/linux-x86_64-normal-server-release/bootcycle-build/images/j2sdk-image/db/README-JDK.html:
> No such file or directory
> /bin/sh:
> /opt/jprt/T/P1/193135.vkozlov/s/build/linux-x86_64-normal-server-release/bootcycle-build/images/j2sdk-image/db/3RDPARTY:
> No such file or directory

This seems to be an intermittent failure caused by some race condition. 
It's been reported about 3 times that I recall.

David

> But I assume it is not related to these changes because fastdebug build
> passed.
>
> Thanks,
> Vladimir
>
> On 9/12/13 6:46 AM, Volker Simonis wrote:
>> Thank you Erik!
>>
>> Vladimir, could you please push
>> http://cr.openjdk.java.net/~simonis/webrevs/8024265.v4 (before we get
>> the next merge conflicts:)
>>
>> Thanks,
>> Volker
>>
>>
>> On Thu, Sep 12, 2013 at 2:39 PM, Erik Joelsson
>> <erik.joelsson at oracle.com> wrote:
>>> Magnus left for the day, but I'm ok with you pushing this to the
>>> stage area.
>>>
>>> /Erik
>>>
>>>
>>> On 2013-09-12 14:29, Volker Simonis wrote:
>>>>
>>>> Hi Magnus,
>>>>
>>>> thanks for doing "JDK-8024665 Move open changes for JDK-8020411 to
>>>> closed source"!
>>>>
>>>> Can you now please give Vladimir the GO signal (from a
>>>> build-perspective) to integrate my changes (from
>>>> http://cr.openjdk.java.net/~simonis/webrevs/8024265.v4/) into the
>>>> ppc-aix-port/stage repository?
>>>>
>>>> Actually my changes revert 8020411 as well. This means that when
>>>> 8024665 will flow into our staging repository, we would have to
>>>> manually resolve platform.m4 to our version which we checked in, but
>>>> that should be OK.
>>>>
>>>> I'd really appreciate if we could push my change now, otherwise we
>>>> would have to wait another couple of weeks until 8024665 goes from
>>>> build -> main -> stage.
>>>>
>>>> Thank you and best regards,
>>>> Volker
>>>>
>>>>
>>>> On Thu, Sep 12, 2013 at 10:11 AM, Magnus Ihse Bursie
>>>> <magnus.ihse.bursie at oracle.com> wrote:
>>>>>
>>>>> On 2013-09-11 18:45, Volker Simonis wrote:
>>>>>>
>>>>>> Argh! It conflicts with 8020411
>>>>>> (http://cr.openjdk.java.net/~erikj/8020411/webrev.root.01/) from your
>>>>>> last jdk8->stage synchronisation.
>>>>>>
>>>>>> @Magnus, Erik : it seems that '8020411' needed a similar 'feature' to
>>>>>> my actual change but did it without abstracting over the name of the
>>>>>> "compilers target bits" flag name vs. its actual value. Unfortunately
>>>>>> all the users of the change 8020411 are in the closed sources. I'd
>>>>>> really like to stay with my solution (because I think that's the most
>>>>>> general one) and resolve the merge conflicts with 8020411 by
>>>>>> eliminating TARGET_BITS_FLAG which can now be replaced by
>>>>>> "${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}.
>>>>>
>>>>>
>>>>> I see. When looking more closely in the fix for JDK-8020411, it turned
>>>>> out
>>>>> that it could do with some improvements:
>>>>> a) since it really only applies to the closed sources, it could (and
>>>>> should)
>>>>> be done only in the closed sources.
>>>>> b) it was actually incorrect, since it removed the ADDED_*FLAGS
>>>>> variables,
>>>>> which are needed for later use to check for incorrect additions to
>>>>> *FLAGS.
>>>>>
>>>>> I am sorry your patch has become caught in this messiness. :(
>>>>> Nevertheless,
>>>>> I think the best way forward is that I create a new patch, that
>>>>> reverts
>>>>> the
>>>>> JDK-8020411 in the open sources and re-implements them in the closed
>>>>> sources. I agree that your solution is better, and what we should
>>>>> have in
>>>>> the open sources. You shouldn't have to care about the
>>>>> TARGET_BITS_FLAG,
>>>>> it
>>>>> is an internal hack.
>>>>>
>>>>> I'll start working on it immediately.
>>>>>
>>>>> /Magnus
>>>
>>>