On Wed, 2005-05-04 at 23:14 -0400, David Walluck wrote:
-----BEGIN PGP SIGNED MESSAGE-----
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
. 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
Also, I guess katana has been dumped for fc4 and beyond? So what is
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.
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
> 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
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.