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

[Michael Franz]

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.

>
>
> 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.

>
>
> 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).  I have not tried the Soylatte version.
So, I am actually interested in the bootstrapping process of IcedTea.

>
> 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.

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.


> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090820/7d2f6f48/attachment.html