On Sun, 2005-03-07 at 21:08 +0200, Karl Trygve Kalleberg wrote:
> I was wondering if I you had any thoughts about how best to approach
> creating a separate dev-java/gcj package?
Don't know if you saw my blog posting around the time of GUADEC, but I
mentioned that I was working (obliquely) towards this.
http://research.operationaldynamics.com/blogs/andrew/software/java-gnome/gcj-4.0.0-linking-problem.html
> We've discussed this before: We want to be able to natively compile Java
> applications, but not be tied to the release cycle for gcc. Also, since
> we can't do USE-based deps, it's very difficult to depend on gcc in a
> way which results in it having gcj in the first place.
So I *have* looked into this. High time I reported.
1) Modules required:
You need core, g++, and java. Trying to build with gcc-core and gcc-java
only will result in an obscure error 21 minutes into your compile. I
recalled that GCC Java support is a subset of compiling C++, and so
tried grabbing that, and ta-da.
2) build location
Building GCC is a bit unusual (you MUST build from a tmpdir location,
not from the tree which you unpacked). So, whereas I unpacked my three
modules in ~/src/open/gcc-4.0-20050526, I changed director
to /tmp/gcj-build before issuing:
$ ~/src/open/gcc-4.0-20050526/configure --prefix=/opt/gcj-4
--with-language=java --enable-java-awt=gtk --enable-threads=posix
$ make
$ make install
I'm pretty sure those args are mandatory (ie, you'd better pick a thread
model)
3) x86 specificness
So obviously the above is Linux specific, and I did it on an x86 box.
Yes, I realize that there are gcc and toolchain eclasses. I looked at
them, and was totally mystified by them. So I said, "forget it" and just
did the above manually. Taken together, this would actually be a bloody
simple ebuild to write.
4) the BIG problem.
So far so good. Until you run into 2 big problems. The first is the fact
that your new GCJ has a new version of classpath, libgcj.so.6, which is
incompatible with libgcj.so.5 of gcj-3.4. So, anything you've built
previously with gcj-3.4 will need to be rebuilt. Ok, no huge deal.
But there's a bigger issue. In Gentoo, the principal way that everything
works so nicely together is that java-config sticks
the /opt/whatever-jdk-1.4.2/bin directory onto PATH. Great! Except that
the above install also copied a little file named gcc to /opt/gcj-4/bin.
How about that, huh! Guess what that would do to your system if on PATH?
I did some preliminary experiments and it seems that you don't actually
need that gcc executable there. (or rather, gcc is pretty good about
understanding where it was installed and where to look for its own
pieces). But that would definitely need some cleansing.
> I've not seen what the redhat guys do with this yet, as time has not
> permitted me:/
They've done something I don't thing we should - they've created a
package called java-gcj-compat which provides wrappers called java and
javac around gij and gcj. Cute, but I don't think it's a good idea - if
you're using GCJ, you *really* need to be aware of the fact you're
playing with fire. GCJ-4 is excellent, and working well, but it's not a
drop in replacement - see the configure and makefile for xseq.
++
Like I said, given all this, it shouldn't be a hard ebuild to write. I'm
tempted.
AfC
Sydney
--
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
|
