On Sun, Jan 04, 2004 at 01:57:52AM -0600, Matthew Kennedy wrote: > > On any given Gentoo system, GCJ is broken by default if the user has > installed a JDK. > > Case #1: GCJ needs to work as the user expects and the GCJ > documentation describes. CLASSPATH needs to be unset for this to > happen.
It's okay to drop the system-wide CLASSPATH, actually, with a few notabenes. > 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. At least the JDK-style invocation should work. It's a major misfortune that the gcc team decided not to be JDK-compliant. Of course, it's nice that 'native' gcj/gij works as well, but imho that's of lesser priority. > 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). java-config can already answer all of these questions, and that would be the preferrable way of asking for these env vars. We're hoping to eventually come to a common switch-interface to java-config as the debian guys, and hope that other projects (jpackage, freebsd, commerical linuxes) will follow. > 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. Some packages, such as eclipse, won't build correctly unless the CLASSPATH is exported in full and passed as a parameter to the build system. In the absence of a proper CLASSPATH, they set the runtime library to a fixed .jar-file, which is not present on all JDKs, and thus breaks. However, this is a per-ebuild issue, and I'd prefer we use java-config to build package-specific CLASSPATHs that are used only during compilation. One current problem is that users may set an odd CLASSPATH for root, which gets inherited by emerge, and weirdness ensues upon merging java packages. > 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. Some packages actually need an explicit CLASSPATH, lest they try to make up a default on their own, which breaks on anything that's not blackdown-jdk. > And lastly, I'd like to make the point, that CLASSPATH should be > really left to the user to control. Amen! Kind regards, Karl T -- [EMAIL PROTECTED] mailing list
