[fedora-java] Problems bootstrapping java-1.4.2-gcj4.0-compat build

[Thomas Fitzsimmons]

Hi,

On Wed, 2005-05-04 at 23:14 -0400, David Walluck wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Thomas Fitzsimmons wrote:
> > In the meantime it would be very useful to create a pure bytecode
> > eclipse-ecj package, buildable by gcj -C, for distribution by
> > jpackage.org.  I wanted to do this when I first submitted java-gcj-
> > compat to JPackage but I never got around to it.  All the logic will be
> > in the Rawhide Eclipse spec file, since we bootstrap ecj using gcj -C.
> 
> It shouldn't be too hard to do this. The question then becomes: what is
> necessary for gcj to pick up ecj as the compiler? As I recall from
> eclipse.spec, it just set a .so in its LD_LIBRARY_PATH. This won't work
> for the bytecode-only version. I should look myself, but because of the
> issues stated, I don't have gcj-compat installed on my system at this time.
> 

I'd recommend looking at eclipse.spec from Rawhide to see how this is
done.

> Also, I guess katana has been dumped for fc4 and beyond? So what is the
> plan for nativifying jars from now on? Ideally, I wish that it was
> transparent to other non-native javac's. For example, it would be
> handled by gcj's javac script and then a macro (or whatever) could be
> added to pick up any extra files produced.
> 

See /usr/bin/find-and-aot-compile, /usr/bin/aot-compile
and /usr/bin/rebuild-gcj-db in Rawhide java-1.4.2-gcj-compat.

> >>A minor issue seems to be that classpathx-mail requires
> >>classpath-inetlib-javadoc, only I can't find a separate
> >>classpath-inetlib package. Instead, it seems to be in the
> >>classpathx-mail rpm, in which case no package can provide the
> >>classpath-inetlib-javadoc dependency that is needed.
> 
> Is this classpath-inetlib-javadoc dependency erroneous?

Yes, likely.  I'm going to work on classpathx-mail this week; I'll keep
this in mind.

>  Remember that
> inetlib got merged in with classpathx-mail. I seem to remember that
> there was a separate classpath-inetlib package that used to be in fedora
> development. In any case, it's no longer there, nor did it find its way
> into JPackage.
> 
> > I'm working on a patch that will merge Jessie into GNU Classpath/libgcj
> > which will eliminate this dependency.
> 
> You mentioned that the ecj stuff was targeted for fc5. Is this also
> targeted for much later?

This will land after FC4 but likely only shortly after, in Rawhide.

>  In that case, I don't think it would hurt to
> remove jessie as a requirement for gcj-compat (for my purposes at
> least).

No, we want java-gcj-compat to depend on jessie because jessie provides
an SSLv3 implementation.  Sun's SDK has an SSLv3 implementation, so we
need one in java-gcj-compat by default.

We put this in the core so that https would work.  Eclipse's bugzilla
plugin and gcjappletviewer both require https.

So this dependency will be present when FC4 ships, but will be
eliminated shortly after.

Tom