Using A Sun based Javac to compile rt-closed.jar different from using gcj

Thu Aug 20 16:09:56 PDT 2009

2009/8/20 Michael Franz <mvfranz at gmail.com>:
>
>
> On Thu, Aug 20, 2009 at 8:32 AM, Andrew John Hughes
> <gnu_andrew at member.fsf.org> wrote:
>>
>> 2009/8/20 Michael Franz <mvfranz at gmail.com>:
>> > Hi,
>> >
>> > It has taken a few days but I have figured out why my rt-closed.jar is
>> > missing a bunch of classes.
>> >
>> > I am building on OS X and using either Apple's JKD or an older version
>> > of
>> > OpenJDK.  It seems that on Fedora the creation of the rt-closed.jar
>> > using
>> > gcj to compile the sources in rt/ .  The class files are created in
>> > lib/rt,
>> > this is then jar'ed to create rt-closed.jar.  It seems that gcj (and
>> > ecj)
>> > will put classes that are reference (directly/indirectly) by the classes
>> > it
>> > compile into the output directory.  This explains why lib/rt has class
>> > files
>> > that are not in rt.  Since Apple's JDK or OpenJDK itself do not do this
>> > the
>> > rt-closed.jar is missing classes that are assumed to be there later
>> > causing
>> > the bootstrap process to fail.
>> >
>> > Is this functionality of gcj and ecj an undocumented switch in OpenJDK?
>> >
>> > Michael
>> >
>>
>> Well, I believe Apple's JDK is a Sun derivative too, so its behaviour
>> being similar to OpenJDK is not too much of a surprise.  When or how
>> it was derived is impossible to tell as it's a proprietary product.
>> Equally, gcj uses ecj so we're only talking about the difference in
>> two compilers here: ecj and javac.
>
> I didn't know gcj was using ecj.  I thought it had its own implementation.
>>

It did before.  It was dropped and ecj was used to support the 1.5
language features.  gcj now uses ecj to compile to bytecode then
natively compiles said bytecode.  Using 'gcj -C' (output class files)
is roughly equivalent to ecj but with different (GCC standard)
command-line syntax.

>>
>> I believe the purpose of rt-closed.jar is to precompile classes from
>> OpenJDK that would otherwise be present in a Sun-derived JDK to begin
>> with (this bit is so old it predates my involvement in IcedTea).  So,
>> although ecj spits out every class it touches, the loss shouldn't
>> matter on with Sun-derived boot JDKs -- in theory.
>
> It does matter in the case where the bootclasspath is replaced to use only
> rt-closed.jar and some directories.

I did say in theory :)
As I also said, IcedTea does this because it presumes you aren't using
a Sun-derived JDK; it thinks you have gcj/ecj and need a completely
new set of bootstrap classes, which will be built in full by ecj.  As
you aren't using ecj+gcj, you can't (at present) use the default
build.  Try --disable-bootstrap.  That does work with IcedTea as the
boot JDK at least. YMMV with other JDKs.

>>
>>
>> The whole build process is currently based on two presumptions:
>>
>>  * If you build with the defaults, you do a full bootstrap build: gcj
>> for stage 1 and the built JDK for stage 2.
>>  * If you build with --disable-bootstrap (renamed from
>> --with-icedtea/--with-openjdk et. al. in IcedTea7, but still under
>> those names in 6) then you are assumed to be doing a build closer to
>> the OpenJDK default, so less patches are applied, etc.
>>
>> I'm working on making the stages JDK-independent but this takes time.
>> The first stage will be getting a full build working with OpenJDK but
>> as you (and others) have seen, we aren't there yet.  This is
>> documented in the NEWS for 1.11.
>>
>> You could try building using --disable-bootstrap for now, or just do a
>> raw OpenJDK build without IcedTea by checking out the IcedTea forest:
>> hg fclone http://hg.openjdk.java.net/icedtea/jdk7
>
> I have been using the openjdk-bsdport, but I was not able to build since
> there you need Java 7 features and I don't have a working Java 7 JDK (one
> that can handle the new features).

Er... you *shouldn't* need JDK7, that would be self-defeating.  I
regularly build OpenJDK with IcedTea6 which is an implementation of
Java 6.
Note that Zero is now part of the IcedTea forest so in theory you can do:

$ hg fclone http://hg.openjdk.java.net/icedtea/jdk7
$ cd jdk7
$ hg fpull -u http://hg.openjdk.java.net/bsd-port/bsd-port

and create a hybrid of the two.  Never tried it though.

  I have not tried the Soylatte version.
> So, I am actually interested in the bootstrapping process of IcedTea.

At present you'll be disappointed then because it is only currently
tested with gcj/ecj.  As I say, try --disable-bootstrap and see how
that goes.

>>
>> Patches are of course welcome, but touching such a hairy build system
>> is not for the faint-hearted :)
>
> I have looked at this whole build process and get faint all the time.
>
> I was able to use --with-javac=ecj and get past this issue.  I was not able
> to figure out what the --with-ecj switch did.
>

IIRC, it allows you to pass a path to an ecj binary.  What
command-line options are you passing in full?

IcedTea7 does the following:

* If --with-javac is specified, it uses that.
* If not, it checks for javac in ${JDK_HOME}/bin/javac.  If
--with-jdk-home is not specified, then each of the following is tried:

/usr/lib/jvm/java-gcj
/usr/lib/jvm/gcj-jdk
/usr/lib/jvm/cacao
/usr/lib/jvm/java-openjdk
/usr/lib/jvm/icedtea6
/usr/lib/jvm/java-6-openjdk
/usr/lib/jvm/openjdk
/usr/lib/jvm/java-icedtea

The first three are omitted if --disable-bootstrap is used.  The first
one that exists is used.

* If JAVAC is still not set, then it looks for ecj either on the path
or as specified by --with-ecj.
* Should it not find that, it will use ecj.jar and ${JAVA} to run it.
If that can't even be found, configure exits with an error.

In short, it tries its level best to find you a compiler.  config.log
will tell you which one has been chosen for JAVAC.  By default (i.e.
./configure) it will set JAVAC, JAVA, etc. from the first JDK it
finds.

> I now have a test_gamma issue using the bootstrap JDK for the second build.
> I may be posting the details later, depends on how far I get.

Ugh, if that is failing, it suggests the JDK you built is bad.

>
>>
>> --
>> Andrew :-)
>>
>> Free Java Software Engineer
>> Red Hat, Inc. (http://www.redhat.com)
>>
>> Support Free Java!
>> Contribute to GNU Classpath and the OpenJDK
>> http://www.gnu.org/software/classpath
>> http://openjdk.java.net
>>
>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>> Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8
>
>

-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8