Using A Sun based Javac to compile rt-closed.jar different from using gcj
mvfranz at gmail.com
Thu Aug 20 15:37:44 PDT 2009
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
> > 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
> > compile into the output directory. This explains why lib/rt has class
> > that are not in rt. Since Apple's JDK or OpenJDK itself do not do this
> > rt-closed.jar is missing classes that are assumed to be there later
> > 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
> 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...
More information about the distro-pkg-dev