Gentoo Logo
Gentoo Spaceship

Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-java
Lists: gentoo-java: < Prev By Thread Next > < Prev By Date Next >
To: Karl Trygve Kalleberg <karltk@g.o>
From: Andrew Cowie <andrew@...>
Subject: Re: Gentoo GCJ package
Date: Thu, 07 Jul 2005 22:06:16 +1000
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.

> 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

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,, which is
incompatible with 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


Andrew Frederick Cowie

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

Sydney   New York   Toronto   London

gentoo-java@g.o mailing list

Re: Re: Gentoo GCJ package
-- Karl Trygve Kalleberg
Lists: gentoo-java: < Prev By Thread Next > < Prev By Date Next >
Next by thread:
Re: Re: Gentoo GCJ package
Next by date:
Cli viewer of javadoc

Updated Jun 17, 2009

Summary: Archive of the gentoo-java mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.