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.joels...@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.bur...@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
