On any given Gentoo system, GCJ is broken by default if the user has installed a JDK.
,----[ set |grep CLASSPATH ] | CLASSPATH=.:/opt/sun-jdk-1.4.2.03/jre/lib:/opt/sun-jdk-1.4.2.03/lib/tools.jar:/opt/sun-jdk-1.4.2.03/jre/lib/rt.jar `---- For example: [EMAIL PROTECTED]:~$ gcj --main=foo -o foo foo.java java/lang/Object.java:0: fatal error: the `java.lang.Object' that was found in `/opt/sun-jdk-1.4.2.03/jre/lib/rt.jar' didn't have the special zero-length `gnu.gcj.gcj-compiled' attribute. This generally means that your classpath is incorrectly set. Use `info gcj "Input Options"' to see the info page describing how to set the classpath compilation terminated. Of course the problem is CLASSPATH was set and gcj looks there unless the --bootclasspath or --classpath is set. Unset CLASSPATH and we have: [EMAIL PROTECTED]:~$ unset CLASSPATH; gcj --main=foo -o foo foo.java [EMAIL PROTECTED]:~$ Successful compilation. Yes, I could have given --bootclasspath=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/java/libgcj-3.3.2.jar, but why should I -- thats broken behavior. I am currently working on two GCJ integration issues for Gentoo. Case #1: GCJ needs to work as the user expects and the GCJ documentation describes. CLASSPATH needs to be unset for this to happen. Case #2: I want to provide a JDK adapter for GCJ. This is essentially a set of wrappers for gcj, gij and rmic which provide JDK-like commands: javac, and rmic (rmic is the same). Other distributions such as Mandrake, Redhat and (IIRC) Debian provide such wrappers. As you can see there's two modes of operation: gcj/gij native invocation and JDK-style invocation and I believe they should both work. So I'd like to get some input. I'd like us to NOT export the CLASSPATH environment variable. For that matter, I think we should NOT export JAVAC, JAVA_HOME and JDK_HOME. If scripts and other tools need these environment variables to work, then we should have these variables sourced from some place on disk (perhaps a java-config command to do this). On my machine, here's what the classpath is set as: .:/opt/sun-jdk-1.4.2.03/jre/lib:/opt/sun-jdk-1.4.2.03/lib/tools.jar:/opt/sun-jdk-1.4.2.03/jre/lib/rt.jar:. Is this really even necessary??? If I download the JDK and install it into (say) /usr/local, I never have to set CLASSPATH to include the Java API stuff and compiler interface (such as rt.jar and tools.jar) or even the extra jar dir /opt/sun-jdk-1.4.2.03/jre/lib explicitly like we do to get other java applications and libraries to build. Can anyone remember why we set this? AFAIK, JDK 1.3 and 1.4 is able to figure out this stuff automatically. 1.2 maybe also, but my memory doesn't go back that far. And lastly, I'd like to make the point, that CLASSPATH should be really left to the user to control. Matt -- Matthew Kennedy Gentoo Linux Developer -- [EMAIL PROTECTED] mailing list
