1 |
Andrew Cowie wrote: |
2 |
|
3 |
> 4) the BIG problem. |
4 |
> |
5 |
> So far so good. Until you run into 2 big problems. The first is the fact |
6 |
> that your new GCJ has a new version of classpath, libgcj.so.6, which is |
7 |
> incompatible with libgcj.so.5 of gcj-3.4. So, anything you've built |
8 |
> previously with gcj-3.4 will need to be rebuilt. Ok, no huge deal. |
9 |
> |
10 |
> But there's a bigger issue. In Gentoo, the principal way that everything |
11 |
> works so nicely together is that java-config sticks |
12 |
> the /opt/whatever-jdk-1.4.2/bin directory onto PATH. Great! Except that |
13 |
> the above install also copied a little file named gcc to /opt/gcj-4/bin. |
14 |
> How about that, huh! Guess what that would do to your system if on PATH? |
15 |
> |
16 |
> I did some preliminary experiments and it seems that you don't actually |
17 |
> need that gcc executable there. (or rather, gcc is pretty good about |
18 |
> understanding where it was installed and where to look for its own |
19 |
> pieces). But that would definitely need some cleansing. |
20 |
|
21 |
We had a brief talk about this yesterday, but this time difference is a |
22 |
problem, so we should probably revert to mail;) |
23 |
|
24 |
|
25 |
The fact that gcj will keep duplicates of many of the gcc headers, |
26 |
libraries and programs, is indeed an ugly technical problem. One thing |
27 |
is that it eats disk space. |
28 |
|
29 |
Another is the libraries now required by gcj-compiled packages. Will |
30 |
they have rpaths pointing to /opt in them? If not, how do we know they |
31 |
work with whatever version of gcc is in /usr? If they do indeed point to |
32 |
/opt, and somebody uninstalls (or upgrades gcj to an ABI-incompatible |
33 |
version), all gcj-compiled apps could break, right? |
34 |
|
35 |
|
36 |
Cheers, |
37 |
|
38 |
-- Karl T |
39 |
-- |
40 |
gentoo-java@g.o mailing list |