Bootstrapping (Was: Non-ASCII characters and OpenJDK)
Andrew John Hughes
gnu_andrew at member.fsf.org
Mon Aug 17 12:16:02 PDT 2009
2009/8/17 Mark Wielaard <mark at klomp.org>:
> Hi Andrew,
> On Mon, 2009-08-17 at 17:20 +0100, Andrew John Hughes wrote:
>> 2009/8/12 Mark Wielaard <mark at klomp.org>:
>> It's been possible to bootstrap OpenJDK with the GNU toolchain since
>> June 2007 (with a few workarounds) and that setup has certainly been
>> capable of compiling 1.6 source files. Given, AFAIK, the only changes
>> between 1.5 and 1.6 were verifier changes, I don't see why it would be
>> a problem. Without being able to do this, there wouldn't be an
>> IcedTea and it seems unlikely OpenJDK would be in current GNU/Linux
> Precisely. Which brings us to...
>> > Although IcedTea can indeed also try to bootstrap things with 1.5
>> > capable tools (most of this is now disabled in IcedTea7 I see)
>> What has been disabled? I still run every new IcedTea7 build with
>> gcj. Nothing has changed AFAIK.
> IcedTea (specifically patches/ecj/icedtea.patch) used to set explicit
> -source/target 1.5 options. Mostly at the same points that now also have
> such settings in openjdk7. So those have been removed to not conflict.
> But they are now explicitly 1.6, no longer 1.5.
> This isn't a problem with newer/patches gcj/gij, since those do accept
> class major version 51 (even though it don't use the stack maps), but
> older gcj/gij doesn't accept such major class versions. (As you point
> out above, there is no real advantage using 1.6 over 1.5 in the VM. As
> long as the class library supports the needed 1.6 classes - as gnu
> classpath does.)
>> The problem is there is not one but three 'JDKs' in the mix here.
>> It's even more complicated if you consider each of them can be a mix
>> of different VMs and compilers. Things would be easier to debug if
>> Ant wasn't being used.
> Yes, ant makes things just that much more interesting... :}
> I have slowly gone through the build to try to have the "tool
> classes" (that need to be run during the build) and the "final rt
> classes" (that don't need to be run during the build) have explicitly
> compiled with the -source/target specifically set. Not fully there yet.
> The biggest problem is the jdk build. There are a couple of tools that
> are run during the build but that depend on com.sun.* classes that are
> (also) compiled as part of the runtime rt classes.
> This currently only work by accident. There are two slightly different
> ways this can happen:
> a) because you are using a bootstrap vm that already has those com.sun.*
> classes on the bootclasspath (the wrong old version is used then, not
> the just compiled one, but the one in the bootstrap vm core class
> b) because you use a bootstrap vm (like newer gcj/gij) that accepts a
> mix of major class versions (1.6/50 for the tool classes and 1.7/51 for
> the rt classes) when running the java build generation tools (this will
> work until one of the accidentally included new rt classes will actually
> start using invokedynamic, it already fails with gcj/gij that don't
> accept such newer 1.7/41 classes - such as the gcj/gij on Debian
After some experimentation:
* OpenJDK7 (from the IcedTea forest) builds fine on its own (i.e.
without IcedTea) using IcedTea6. So we haven't picked the bug Martin
and I had on OpenJDK6.
* javac.in has always passed -1.5 to ecj as it defaults to 1.4.
Leaving this in causes langtools to fail in build-bootstrap-javac:
[javac] Compliance level '1.5' is incompatible with source level
'1.6'. A compliance level '1.6' or better is required
* changing this to 1.6 causes a later failure in build.classes.javac
[javac] Compliance level '1.6' is incompatible with source level
'1.7'. A compliance level '1.7' or better is required
* getting rid of it altogether allows langtools to build and breaks
corba which isn't setting source/target:
-J-XX:ThreadStackSize=1536 -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m
-J-XX:MaxPermSize=160m -encoding ascii -d
This only works on IcedTea because it defaults to a higher
* using 1.7 in javac.in works for me, but clearly not for mjw.
So I think we need to remove the option and specify it explicitly when
needed. Which means some more OpenJDK fixes are required.
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
More information about the discuss