[7u60] RFR 8024648 : 8016131 breaks Zero port
Andrew Hughes
gnu.andrew at redhat.com
Fri Feb 7 08:11:12 PST 2014
----- Original Message -----
> I have a concern here.
>
> First this general situation is a mess. We started adding the new-build
> support in hs24 but JDK 8 is using hs25, so all this SPEC and
> JVM_VARIANT stuff is completely unwanted in JDK 7u. My preference here
> would be to get this stuff backed out of 7u and return to a completely
> configure-ignorant build system. That said I'm not sure that is really
> the issue with ZERO/SHARK builds.
>
Backing out:
7141246: build-infra merge: Introduce new JVM_VARIANT* to control which kind of jvm gets built
Reviewed-by: dholmes, ohair
would also work, or at least the Zero/Shark changes there. I note you
reviewed this, but it clearly wasn't tested with Zero. With this change
introduced, a Zero build can't even find its makefiles any more.
> My concern with the proposed patch is that defs.make is not intended to
> be included by every other Makefile and/or .make file. We all know by
> now that the hotspot build system is complex, convoluted and fragile.
> When you do a hotspot build there are multiple nested sub-makes
> involved, as well as build file generation and use. The "big picture"
> intent is that defs.make contains all the high-level stuff needed by the
> "top" level makefile targets. buildtree.make will then generate other
> .make files using that information. It is very difficult to see exactly
> which .make file will get used by which phase of the overall build.
> Unfortunately this leads to a tendency where if a "low-level" file needs
> access to X, which is defined in defs.make, then the "solution" is just
> to include defs.make in that file. We did the same thing for
> buildtree.make in JDK 8. But I have reservations about also doing it for
> gcc.make and vm.make. I think it is the wrong solution - we should be
> passing the needed variables/values through the files generated by
> buildtree.make.
>
Each change was introduced separately in IcedTea, as they were caught at
different times.
changeset: 4224:a57f19258524
user: andrew
date: Fri Jan 04 22:21:54 2013 +0000
summary: Include defs.make in buildtree.make so ZERO_BUILD is recognised and JVM_VARIANT_ZERO set.
changeset: 4894:56f4e181b8d4
user: andrew
date: Wed Sep 11 16:55:12 2013 +0100
summary: Set ZERO_BUILD in flags.make so it is set on rebuilds
changeset: 4971:02f0bce4ac32
user: andrew
date: Tue Nov 12 17:58:35 2013 +0000
summary: Include defs.make in vm.make so VM_LITTLE_ENDIAN is defined on Zero builds
I agree it may not be the best solution for all, which
is why I only fixed buildtree.make at first, where it's most obviously
wrong. However, I don't know the makefiles well enough to suggest another
solution and just adding defs.make does work for us. We did have another
solution for gcc.make, at least for the Zero part:
changeset: 4279:4fd8e7ebca9a
parent: 4260:7e12b7098f20
user: andrew
date: Thu Jan 17 12:07:28 2013 +0000
summary: Make sure libffi cflags and libs are used.
diff -r 7e12b7098f20 -r 4fd8e7ebca9a make/linux/makefiles/gcc.make
--- a/make/linux/makefiles/gcc.make Mon Jan 14 16:38:37 2013 +0000
+++ b/make/linux/makefiles/gcc.make Thu Jan 17 12:07:28 2013 +0000
@@ -75,9 +75,6 @@
VM_PICFLAG/AOUT =
VM_PICFLAG = $(VM_PICFLAG/$(LINK_INTO))
-ifeq ($(JVM_VARIANT_ZERO), true)
-CFLAGS += $(LIBFFI_CFLAGS)
-endif
ifeq ($(JVM_VARIANT_ZEROSHARK), true)
CFLAGS += $(LIBFFI_CFLAGS)
CFLAGS += $(LLVM_CFLAGS)
diff -r 7e12b7098f20 -r 4fd8e7ebca9a make/linux/makefiles/vm.make
--- a/make/linux/makefiles/vm.make Mon Jan 14 16:38:37 2013 +0000
+++ b/make/linux/makefiles/vm.make Thu Jan 17 12:07:28 2013 +0000
@@ -284,9 +284,6 @@
LIBS_VM += $(LIBS)
endif
-ifeq ($(JVM_VARIANT_ZERO), true)
- LIBS_VM += $(LIBFFI_LIBS)
-endif
ifeq ($(JVM_VARIANT_ZEROSHARK), true)
LIBS_VM += $(LIBFFI_LIBS) $(LLVM_LIBS)
LFLAGS_VM += $(LLVM_LDFLAGS)
diff -r 7e12b7098f20 -r 4fd8e7ebca9a make/linux/makefiles/zero.make
--- a/make/linux/makefiles/zero.make Mon Jan 14 16:38:37 2013 +0000
+++ b/make/linux/makefiles/zero.make Thu Jan 17 12:07:28 2013 +0000
@@ -30,3 +30,7 @@
# Install libjvm.so, etc in in server directory.
VM_SUBDIR = server
+
+# Make sure libffi is included
+CFLAGS += $(LIBFFI_CFLAGS)
+LIBS_VM += $(LIBFFI_LIBS)
That leaves Shark still broken but maybe something similar could be done
with the LLVM flags instead. I haven't tested Shark with this patch and
that's much more involved. I've also never had a working build of it
anyway.
> If this was to go ahead as-is I would want to know that there has been a
> comparison of all the build commands before and after to ensure no
> unintended changes have been introduced. A set of successful builds is
> not in itself sufficient.
Assuming you run jdk_generic_profile.sh first, setting ZERO_BUILD=true
is sufficient to build Zero.
>
> David
>
> On 7/02/2014 8:10 AM, Alejandro E Murillo wrote:
> > I forgot to change the "subject".
> > The change is and has been approved for 7u60 (hs24.60)
> > Thanks
> >
> > Alejandro
> >
> > On 2/6/2014 3:03 PM, Alejandro E Murillo wrote:
> >>
> >> can we get 2 hotspot reviewers quickly check this change ?
> >> thanks
> >> Alejandro
> >>
> >> -------- Original Message --------
> >> Subject: Re: Question on 8024648 : 8016131 breaks Zero port
> >> Date: Thu, 6 Feb 2014 16:21:29 -0500 (EST)
> >> From: Andrew Hughes <gnu.andrew at redhat.com>
> >> To: Alejandro E Murillo <alejandro.murillo at oracle.com>
> >> CC: Seán Coffey <sean.coffey at oracle.com>, Omair Majid
> >> <omajid at redhat.com>, jdk7u-dev at openjdk.java.net
> >>
> >>
> >>
> >> ----- Original Message -----
> >>
> >>
> >> Here's the webrev:
> >>
> >> http://cr.openjdk.java.net/~andrew/jdk7u/8024648/
> >>
> >> My OpenJDK username is andrew (should already be included in the commit)
> >>
> >> The changes are as follows:
> >>
> >> * Bring in defs.make to a number of makefiles which expect
> >> JVM_VARIANT_ZERO
> >> or JVM_VARIANT_ZEROSHARK to be set, but don't parse the makefile that
> >> sets
> >> it. This is a regression caused by the new build which instead sets these
> >> via configure and $(SPEC). There is code for handling the old build
> >> (ZERO_BUILD=true) in defs.make but it isn't brought in. (see 7141246)
> >> * Update the call_wrapper function following 8024648.
> >>
> >> I've updated the bug summary to reflect that it fixes changes from both
> >> bugs, but we can split them into two separate bugs if you prefer. Without
> >> the 7141246 fix, the build fails in seconds.
> >>
> >> With the webrev applied:
> >>
> >> $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java -version
> >> openjdk version "1.7.0-internal"
> >> OpenJDK Runtime Environment (build
> >> 1.7.0-internal-andrew_2014_02_06_19_43-b00)
> >> OpenJDK 64-Bit Zero VM (build 24.80-b01, interpreted mode)
> >>
> >> $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java HelloWorld
> >> Hello World
> >>
> >>
> >
>
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
More information about the hotspot-dev
mailing list