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

[David Walluck]

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

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.

>>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? 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? In that case, I don't think it would hurt to
remove jessie as a requirement for gcj-compat (for my purposes at
least). After all, any package which needs what it provides will pull it
in separately anyway. What package required this that it was necessary
to put it into the core? It is only a provider for jce, when jce is
provided by gnu-crypto. Perhaps gnu-crypto should require a provider
(virtual) and jessie should provide this. The point is that no core
package needs a crypto provider as far as I can tell, so there's not
much of a point tying it to the core system.

- --
Sincerely,

David Walluck
<david at zarb.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iD8DBQFCeY9/arJDwJ6gwowRApXSAJ0Srs8qYnfYaPqbEaGLRJ4E0Z0xgwCfUhW8
SVqN1qwB6R1YnLIzo7eYQBc=
=lAbU
-----END PGP SIGNATURE-----