I've been investigating how/why my recent change broke the build for
OpenJDK 6,
for which I apologize.
The changeset in question is
changeset: 49:608910eef036
user: jjg
date: Tue Aug 11 16:40:03 2009 -0700
files: make/Makefile make/build.properties make/build.xml
description: 6870641: [langtools] update make/build.* for jdk6
Reviewed-by: darcy
This was intended to be a transparent internal change within langtools,
so that as
much as possible, the langtools infrastructure should be the same
between jdk6 and jdk7.
Ideally, the only differences between the two should be the version
numbers in the
various places they occur: I was even thinking of setting up a cron-job
to monitor
the differences between the versions of selected files, and a way of
making sure
that changes in one version were considered for the other.
The issue arose from lines 63,64 in build.properties, which set the
default values
for javac.source and javac.target used by the bootstrap javac to compile
the rest
of the tools. Previously, javac.source was unset, and in the changeset,
it got set
to 6, which conflicted with the value for javac.target (5) being passed
in through
the Makefile from the top level Makefile.
Arguably, javac should not be so strict and should allow -source 6
-target 5,
but setting that aside, the quick and correct fix for the recent breakage is
to change the values of javac.source and javac.target from 6 down to 5 in
lines 63,64 of build.properties. I will post a changeset for that shortly.
-- Jon
Jonathan Gibbons wrote:
Martin,
Thanks for the update. Since the previous langtools change was just
intended to be an internal cleanup, I'll fix the langtools build so
that this change is not necessary.
-- Jon
On Aug 13, 2009, at 11:53 PM, Martin Buchholz wrote:
As an experiment, I tried the obvious
diff --git a/make/Defs-internal.gmk b/make/Defs-internal.gmk
--- a/make/Defs-internal.gmk
+++ b/make/Defs-internal.gmk
@@ -205,6 +205,7 @@
JDK_MAKE_SHARED_DIR=$(ABS_JDK_TOPDIR)/make/common/shared \
EXTERNALSANITYCONTROL=true \
TARGET_CLASS_VERSION=$(TARGET_CLASS_VERSION) \
+ SOURCE_LANGUAGE_VERSION=$(TARGET_CLASS_VERSION) \
MILESTONE=$(MILESTONE) \
BUILD_NUMBER=$(BUILD_NUMBER) \
JDK_BUILD_NUMBER=$(JDK_BUILD_NUMBER) \
and to my surprise, that caused the build to succeed.
Note: This message still in bug-reporting, not bug-fixing, mode!
Martin
On Thu, Aug 13, 2009 at 21:27, Joseph D. Darcy<[email protected]> wrote:
I'll do some test builds myself on Friday.
-Joe
Jonathan Gibbons wrote:
Martin,
Comment noted. I'm now on vacation, so I'll look at this next week.
-- Jon
On Aug 13, 2009, at 6:10 PM, Martin Buchholz wrote:
It appears that ant is being invoked with "-Djavac.target=5", but not
with -Djavac.source
execve("/usr/bin/ant", ["ant", "-Djdk.version=1.6.0",
"-Dfull.version=1.6.0-internal-ma"..., "-Dmilestone=internal",
"-Dbuild.number=b00", "-Djavac.target=5", "-Dboot.java.home=/ .....
In turn, this may be due to COMMON_BUILD_ARGUMENTS
including TARGET_CLASS_VERSION but not SOURCE_LANGUAGE_VERSION
# Common make arguments (supplied to all component builds)
COMMON_BUILD_ARGUMENTS = \
JDK_TOPDIR=$(ABS_JDK_TOPDIR) \
JDK_MAKE_SHARED_DIR=$(ABS_JDK_TOPDIR)/make/common/shared \
EXTERNALSANITYCONTROL=true \
TARGET_CLASS_VERSION=$(TARGET_CLASS_VERSION) \
MILESTONE=$(MILESTONE) \
BUILD_NUMBER=$(BUILD_NUMBER) \
JDK_BUILD_NUMBER=$(JDK_BUILD_NUMBER) \
FULL_VERSION=$(FULL_VERSION) \
PREVIOUS_JDK_VERSION=$(PREVIOUS_JDK_VERSION) \
JDK_VERSION=$(JDK_VERSION) \
JDK_MKTG_VERSION=$(JDK_MKTG_VERSION) \
JDK_MAJOR_VERSION=$(JDK_MAJOR_VERSION) \
JDK_MINOR_VERSION=$(JDK_MINOR_VERSION) \
JDK_MICRO_VERSION=$(JDK_MICRO_VERSION)
which would explain why invoking ant directly in the langtools
directory
without -Djavac.target=5 would work fine (I haven't tried it).
langtools build.xml could try to check javac.target and ensure that
javac.source <= javac.target
but I don't know how to do that (I hack make, not ant).
Martin
On Thu, Aug 13, 2009 at 17:35, Jonathan
Gibbons<[email protected]>
wrote:
The primary goal of changeset: 49:608910eef036 is to bring the
langtools
build into line between jdk6 and jdk7, so that we can rely on
eseentially
the same behavior (subject to version differences) across the two
repositoiries.
The override mechanism is unused and harmless since javac.source is
correctly defaulted in build.properties. It is included in 6 to
minimize
the differences between 6 and 7.
Generally, the langtools build tries to isolate the user as much as
possible
from the version of Java used to run Ant.
To build langtools, you should just need to set boot.java.home;
to run
the
regression tests, you will also need to
set target.java.home.
-- Jon
On Aug 13, 2009, at 5:00 PM, Mark Wielaard wrote:
Hi Martin,
On Thu, 2009-08-13 at 15:25 -0700, Martin Buchholz wrote:
/home/martinrb/ws/openjdk6/build/linux-amd64/langtools/build/classes
[javac] javac: source release 6 requires target release 1.6
BUILD FAILED
/usr/local/google/home/martin/ws/openjdk6/langtools/make/build.xml:196:
The following error occurred while executing this line:
/usr/local/google/home/martin/ws/openjdk6/langtools/make/build.xml:525:
Compile failed; see the compiler error output for details.
whether or not I use a vanilla jdk6 (or even jdk7) as bootstrap
jdk
Can anyone else successfully build openjdk6?
If so, what is the secret?
Did I miss something in my inbox?
I haven't tried upgrading oj6 yet. And one of the reasons for not
upgrading icedtea6 atm is to make sure the recent changes (which
as far
as I could tell were not discussed on the list) to the source and
target
defaults don't break the bootstrap. The commit you probably want to
inspect is:
changeset: 49:608910eef036
user: jjg
date: Tue Aug 11 16:40:03 2009 -0700
files: make/Makefile make/build.properties make/build.xml
description:
6870641: [langtools] update make/build.* for jdk6
Reviewed-by: darcy
Unfortunately the bug associated with that commit is also not
public.
The idea behind the commit seems to be to make the -source and
-target
explicit in more places (which is a good thing). There is now
also an
override mechanism, that I admit to not fully understand because it
seems to be never used, through setting SOURCE_LANGUAGE_VERSION
and/or
JAVAC_SOURCE_ARG.
Also note that with ant the default source and target depends on
the VM
that runs the ant process (which might be different from the
bootstrap
VM you are using, it probably depends on your ant installation).
Cheers,
Mark