List Archive: gentoo-java
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
Andrew Cowie wrote:
> 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.
We had a brief talk about this yesterday, but this time difference is a
problem, so we should probably revert to mail;)
The fact that gcj will keep duplicates of many of the gcc headers,
libraries and programs, is indeed an ugly technical 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? 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?
-- Karl T
email@example.com mailing list