Need help from JDK build experts.
I applied next 2 changesets:
http://cr.openjdk.java.net/~simonis/webrevs/8017568_toplevel/
http://cr.openjdk.java.net/~simonis/webrevs/8017568_jdk/
and got JPRT build problems (-control build) only on MacOS and Win64:
http://bus2001067.us.oracle.com/archives/2013/06/2013-06-28-213927.vkozlov.ppc64_jdk_build_test/
------------------------------------------------------------------------------
macosx_x64_10.7-product (details from log file)
...
Warning: The generated configure file contains changes not present in
the custom generated file.
Running autogen.sh to correct the situation
Autoconf found: /usr/bin/autoconf
Autoconf-2.67 found:
Generating generated-configure.sh with /usr/bin/autoconf
/usr/bin/gm4:stdin:187: bad expression in eval: 32 > <dynamic>
autom4te: /usr/bin/gm4 failed with exit status: 1
Generating custom generated-configure.sh
/usr/bin/gm4:stdin:187: bad expression in eval: 32 > <dynamic>
autom4te: /usr/bin/gm4 failed with exit status: 1
------------------------------------------------------------------------------
windows_x64_5.2-fastdebug (details from log file)
...
Warning: The generated configure file contains changes not present in
the custom generated file.
Error: Cannot continue
Cannot locate autoconf, unable to correct situation.
Please install autoconf and run 'bash autogen.sh' to update the
generated files.
make: *** [bridge2configure] Error 1
------------------------------------------------------------------------------
Without these changes the output is:
Running custom generated-configure.sh
configure: Configuration created at Thu Jun 27 16:32:25 EDT 2013.
configure: configure script generated at timestamp 1371547939.
Thanks,
Vladimir
On 6/28/13 12:04 AM, Volker Simonis wrote:
Ok, that's fine.
Could you please let me know when you've verified these changes. I
will then push them to the staging repository.
Regards,
Volker
On Thu, Jun 27, 2013 at 7:35 PM, Vladimir Kozlov
<[email protected]> wrote:
On 6/27/13 10:16 AM, Iris Clark wrote:
Hi, Volker.
I think that the right thing for this change [1] is for you to push into
ppc-aix-port/stage once you get the necessary reviews (presumably Erik and
possibly Alan). While your changeset contains some general purpose updates,
it also contains PPC/AIX-specific files which can't be added to a JDK
release repository until stage is pushed into the a JDK release.
The recommendation to push to stage of course assumes that Vladimir
doesn't think that this will adversely affect the Hotspot work already being
pushed to stage.
This should not affect Hotspot in stage repo. Me or Albert will do JPRT
bootstrap control build of jdk with this changes to make sure it works.
After that Volker can push it into stage.
When I talked about pushing *general* changes into main sources I meant
changes with no ppc64 specific code. The example of such changes was recent
Goetz's fix for '8017531: 8010460 changes broke bytecodeInterpreter.cpp'.
Thanks,
Vladimir
Thanks,
iris
[1]: http://cr.openjdk.java.net/~simonis/webrevs/8017568_jdk/
-----Original Message-----
From: Volker Simonis [mailto:[email protected]]
Sent: Thursday, June 27, 2013 9:23 AM
To: Erik Joelsson
Cc: Kumar Srinivasan; build-dev; [email protected]; Alan
Bateman
Subject: Re: RFR (XS): Enable new build on Linux/PPC64 (jdk part)
Hi Erik,
we have no polices which are carved in stone:) It's all done informally
and by common sense.
The main reason for the ppc-aix-port/stage repository is to have a sandbox
for in-depth review and testing of changes we had to make in shared code
before pushing them to the main repository (and this especially applies to
hotspot changes). If you feel comfortable with the current changes and don't
think that they will break anything (e.g. by running tests build on your
supported platforms including the closed source ones) I'd really appreciate
if you could push them to the build repository.
Otherwise I'll push them to the staging repository and you'll get them
once we're finished with the integration of the port.
Thank you and best regards,
Volker
On Thu, Jun 27, 2013 at 1:51 PM, Erik Joelsson <[email protected]>
wrote:
On 2013-06-27 13:00, Volker Simonis wrote:
On Thu, Jun 27, 2013 at 12:16 PM, Erik Joelsson
<[email protected]>
wrote:
Hello Volker,
I wasn't aware of this project until now. From what I (now)
understand, generic patches can go into jdk8 repos, but port specific
things need to go to staging and go in with the rest later. These
changes contain a couple of port specific things so as it looks now
they would need to go through staging.
Yes, that's the general approach. But I'd argue that for the most part
this changes are generic (enable CPP-interpreter, enable CORE build,
fix for broken ld on SuSE, replacing OPENWIN_LIB by X_LIB, fix typos)
with only very few PPC64 specific parts (map-files and a few defines).
The problem we want to avoid is that some of our fixes go into the
main repositories in parallel which would result in merging pain when
integrating the staging into the main repository.
So if you think you don't need any of the general fixes any time soon,
I'll push the changes into the staging repository. Otherwise I think
it would be better to push them right into the main repositories.
Several of the general fixes in there are good and I don't want to
hinder those getting in. I also don't want to break policies I'm not
familiar with.
/Erik
Thanks,
Volker
/Erik
On 2013-06-27 12:03, Volker Simonis wrote:
Hi Erik,
as Vladimir explained, we have a special staging repository for our
PPC64/AIX port:
I would be happy if you could push the changes right into the
build-infra repositories and we will then get them into our staging
repository via jdk8/jdk8.
Otherwise I'll have to push them to our staging repository and later
when the whole port is completed in the staging repo they will be
bulk-integrated into jdk8.
What do you think?
Regards,
Volker
On Wed, Jun 26, 2013 at 6:53 PM, Vladimir Kozlov
<[email protected]> wrote:
Erik,
We have special staging forest for PPC64/AIX port:
http://hg.openjdk.java.net/ppc-aix-port/stage
We collect Hotspot and JDK changes there for testing before pushing
into main sources in a future. But some general fixes we push
directly into our main sources.
If you think these build changes are acceptable for main, please,
ask someone sponsor these changes.
Alan is our official contact for PPC64/AIX project. I CC him.
Thanks,
Vladimir
On 6/26/13 8:56 AM, Erik Joelsson wrote:
Hello,
If you by staging area mean the build-infra forest, that's more or
less dead now.
I think these changes look good now (both top level and jdk). It
should be fine to push this to jdk8/build.
/Erik
On 2013-06-26 17:28, Volker Simonis wrote:
Hi Erik,
thank you for looking at this. I've prepared a new webrev at:
http://cr.openjdk.java.net/~simonis/webrevs/8017568_jdk/
<http://cr.openjdk.java.net/%7Esimonis/webrevs/8017568_jdk/>
What do you think, do you want to push this directly into the
build repositories or should I push it into the staging repository
first?
Please see my further comments inline.
Thank you and best regards,
Volker
On Tue, Jun 25, 2013 at 12:41 PM, Erik Joelsson
<[email protected] <mailto:[email protected]>> wrote:
On 2013-06-25 12:27, Erik Joelsson wrote:
Hello Volker,
On 2013-06-24 19:23, Volker Simonis wrote:
Hi,
could somebody please review the following change and
create an appropriate
Bug ID for it:
http://cr.openjdk.java.net/~simonis/webrevs/linux_ppc_build_jdk/
<http://cr.openjdk.java.net/%7Esimonis/webrevs/linux_ppc_build_jdk
/>
The patch contains two little changes which are required
to build the class
library part of the OpenJDK on Linux/PPC64. Most of the
build magic is
contained in the top-level part of this change which is
separately reviewed
at
http://cr.openjdk.java.net/~simonis/webrevs/linux_ppc_build_top
<http://cr.openjdk.java.net/%7Esimonis/webrevs/linux_ppc_build_top
CompileLaunchers.gmk
Remove mapfile from build instructions of
BUILD_UNPACKEXE:
CFLAGS_macosx:=-fPIC, \
-
MAPFILE:=$(JDK_TOPDIR)/makefiles/mapfiles/libunpack/mapfile-vers-unpack200,\
LDFLAGS:=$(UNPACKEXE_ZIPOBJS),\
I think it makes no sense to use a version script file
for an executable
and older linkers (e.g. on SLES 10) complain with:
"*Invalid version tag
`SUNWprivate_1.1'. Only anonymous version tag is allowed
in executable.*"
The GNU ld
manual<http://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_25.html>states:
"*Version scripts are only meaningful when creating
shared
libraries.*"
Morover unpack200 was the only executable which used a
version script file.
Unpackexe has some weirdness and this isn't surprising me.
Would be good if someone with more historic knowledge could
fill in on the reason for this. Someone apparently went
through the trouble of creating a special mapfile for this
executable. Also, if not using it, should it be removed?
I looked closer at this. These mapfiles were explicitly added in
http://bugs.sun.com/view_bug.do?bug_id=7033954, but it was noted
that it broke builds for architectures that didn't have mapfiles
defined. If you look at the launchers, the mapfile is only set
if
the arch specific one exists. I think a safer change here would
be
to make the mapfile conditional on platform or arch for
unpackexe.
I still do not fully understand why we need map-files for
executables, but I also understand that you don't want to change the
current setup.
So I went the hard (and hopefully right:) way and implemented a
detection of the buggy linkers on older SuSE distros (e.g. on SLES
10) which complain with: "Invalid version tag `SUNWprivate_1.1'
during the configure step (see top-level change). Unfortunately we
still have quite a lot of these systems so we really need the
build with that buggy ld.
I've therefore added map files with anonymous version tags for
these buggy linkers which are only used if the buggy linker was
detected during the configure step (i.e. if
USING_BROKEN_SUSE_LD=yes). Notice that this is no PPC64 specific
problem but a occurs on all SuSE 10 platforms.
And you've been right. I also had to add the arch specific map
files for ppc64 in order to use them for the other launchers.
Kumar, you made the change referred to here, do you have
anything
to add?
/Erik
Fix typo (replace 'defalt: all' by 'default')
default: all
CompileNativeLibraries.gmk
Only use $(OPENWIN_LIB) for linking LIBSPLASHSCREEN on
Solaris! The old
code worked only accidentally when the X-libraries are
in
the default
linker path anyway. The right solution is to use
$(X_LIBS)
if not on
Windows or Solaris.
Append -DX_ARCH=X_PPC64 to LIBJSOUND_CFLAGS on PPC64.
The value of
X_ARCHisn't actually used on the PPC architectures, but
there's a
check to verify
that it is set.
Fix typo (replace 'defalt: all' by 'default')
default: all
Otherwise looks good.
/Erik
