Gentoo Archives: gentoo-java

From: Andrew Cowie <andrew@×××××××××××××××××××.com>
To: Karl Trygve Kalleberg <karltk@g.o>
Cc: gentoo-java <gentoo-java@l.g.o>
Subject: Re: [gentoo-java] Re: Gentoo GCJ package
Date: Fri, 22 Jul 2005 02:35:01
In Reply to: Re: [gentoo-java] Re: Gentoo GCJ package by Karl Trygve Kalleberg

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.
> 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, 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 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]: -- Andrew Frederick Cowie Technology strategy, managing change, establishing procedures, and executing successful upgrades to mission critical business infrastructure. Sydney New York Toronto London -- gentoo-java@g.o mailing list