Re: [gentoo-java] Re: Gentoo GCJ package

[Andrew Cowie]

[1]

On Thu, 2005-21-07 at 17:48 +0200, Karl Trygve Kalleberg wrote:

> The fact that gcj will keep duplicates of many of the gcc headers,
> libraries and programs, is indeed an ugly technical problem.

Well, it's only a technical problem if you try and install to /usr
alongside another [system] GCC. And even less so, because GCC *is*
capable of being parallel installed (c.f. `gcc-config`). So it's not so
much a technical problem as it is a "you'd better know what you're
doing" problem.

> One thing
> is that it eats disk space.

<shrug>

> Another is the libraries now required by gcj-compiled packages. Will
> they have rpaths pointing to /opt in them?

For semantics, if nothing else, I'd like to  be careful to distinguish
between:

        a) using `gcj -C` as a (more or less) javac replacement, and gij
        + libgcj[.jar] as a GNU Classpath based java replacement JRE,
        and

        b) and using gcj to compile to native executables.

In the former case, just using GCJ as a JDK/JRE, there's no reason not
to drop it out in /opt and carry on just we do with anything else that
`java-config` initializes.

I would note that Red Hat are shipping something called java-gcj-compat
which basically provides command line compatible wrappers `java` and
`javac` around `gij` and `gcj -C` respectively. Recent patches to `gcj`
have made it *almost* command line compatible, but the fact that it
doesn't compile recursively like javac does is something you need to be
aware of. Also see [2].

>  If not, how do we know they
> work with whatever version of gcc is in /usr? If they do indeed point to
> /opt, and somebody uninstalls (or upgrades gcj to an ABI-incompatible
> version), all gcj-compiled apps could break, right?

In the latter case, well, they will only have rpaths pointing
at /opt/gcj-whatever if the [upstream] package using GCJ to build a
native library or executable took the effort to know where it's libgcj
is, and to embed that path. Doing so may or may not be necessary (see
the blog post I mentioned). But definitely, libgcj.so is a
versioned .so, so as long as the linker can find the right one, you're
fine. Of course, if /opt/gcj-whatever *isn't* on the rpath, (and it
certainly isn't on the system (sic) LD_LIBRARY_PATH or ld.so.conf path)
then yes, if you upgrade that package then you could well be in linker
trouble.

Gentoo is tremendously smart by usually just whacking all libraries
into /usr/lib, where things will subsequently "just work", as opposed
to, say, Debian, putting JNI .sos into /usr/lib/jni and wreaking havoc
with things like Eclipse as a result.

But as Karl and I have been discussing in this thread, we would have to
be very cautious about putting anything from our bleeding edge /opt GCJ
install into /usr.

++

Incidentally, one solution might just well be to install a "bleeding
edge GCJ" to /usr (being careful NOT to install the /usr/bin/{gcc,g
++,gcj,etc} front ends) and then do the Fedora inspired compat thing out
in /opt/gcj-jdk-4.1.0/bin/{java,javac,jar}, configurable with
`java-config`.

For compiling to native, binary name `/usr/bin/gcj-4.1.0` would be ok,
though I think `/opt/gcj-jdk/bin/gcj` would be better. 

++
<opinion>

        For those who have actually bothered to read this far, I will
        close with an opinion: compiling to native with gcj is *not*
        trivial. It's not hard, but the commands you run need to be
        carefully crafted.
        
        That does NOT mean you should immediately run screaming to
        something else to do your crafting for you. As people who know
        me are familiar, I detest automake and libtool. I've also heard
        people mumble that ant may someday have tasks to get you to
        native. I don't think that (yet, anyway) such things are
        appropriate because they over-complicate and obscure the finesse
        necessary to "get it right".
        
        With the possible exception of certain branches of
        openoffice-2.0, I am aware of practically zero upstream packages
        that use it properly (if at all). So whenever you see an IRC or
        mailing list question that says like "GCJ is cool. I want to
        immediately compile all my pure Java class only applications to
        natives because that sounds l33t. It's not working. Why not?"
        The answer is that GCJ-to-*native* is NOT a drop in replacement
        for a JDK/JRE. It's *different*.
        
        If you want to see some implemented commands to use gcj to
        builds something to native along side building to traditional
        bytecode class files, see the Makefile in xseq [2].
        
        Finally, running GCJ is indeed cool, but god the stack traces
        are hideous. If you're actually developing or debugging, use
        jikes or ecj to compile and a traditional java VM. There's
        something to be said for readability in error text...
        
</opinion>

AfC
Sydney

[1]: If this message makes no sense, it's because I'm listening to
LugRadio as I'm writing this :) Oh well, having to deal with competition
for mindshare is the nature of voluntary contribution to community
causes.

[2]: http://research.operationaldynamics.com/projects/xseq/

-- 
Andrew Frederick Cowie

Technology strategy, managing change, establishing procedures,
and executing successful upgrades to mission critical business
infrastructure.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

-- 
gentoo-java@g.o mailing list