1 |
Henrique Ferreiro wrote: |
2 |
> O Mér, 12-04-2006 ás 12:21 +0000, Wiktor Wandachowicz escribiu: |
3 |
> |
4 |
>> Henrique Ferreiro <henrique.ferreiro@...> writes: |
5 |
>> |
6 |
>> |
7 |
>>>> # java-config-1 -L |
8 |
>>>> |
9 |
>>> [sun-jdk-1.4.2.10] "Sun JDK |
10 |
>>> 1.4.2.10" (/etc/env.d/java/20sun-jdk-1.4.2.10) * |
11 |
>>> |
12 |
>> While the above is correct, the latter... |
13 |
>> |
14 |
>> |
15 |
>>>> # java-config-2 -L |
16 |
>>>> |
17 |
>>> 1) Sun JDK 1.4.2.10 [sun-jdk-1.4] |
18 |
>>> (/usr/share/java-config-2/vm/sun-jdk-1.4) |
19 |
>>> *) Sun JDK 1.5.0.06 [sun-jdk-1.5] |
20 |
>>> (/usr/share/java-config-2/vm/sun-jdk-1.5) |
21 |
>>> |
22 |
>> ... explains a bit - you probably shouldn't have a SYSTEM JVM |
23 |
>> set to Java 1.5 as of today. You can do so freely on your regular |
24 |
>> user account. |
25 |
>> |
26 |
> |
27 |
> The the migration document shoud warm about this. Anyway, I did |
28 |
> |
29 |
> java-config-2 -S sun-jdk-1.4 |
30 |
> |
31 |
> |
32 |
The document doesn't explicitly state it, but java-check-environment |
33 |
should be upset with you using a 1.5 system vm. In the event that it |
34 |
doesn't mind... then it's a bug. |
35 |
|
36 |
> Now: |
37 |
> |
38 |
> $ java -version |
39 |
> java version "1.4.2_10" |
40 |
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_10-b03) |
41 |
> Java HotSpot(TM) Client VM (build 1.4.2_10-b03, mixed mode) |
42 |
> |
43 |
> But ant-core continues to build with java-1.5. |
44 |
> |
45 |
The new system has a separation between the system vm, and the vm used |
46 |
to compile package (fuller details here [1]) The vm used at build time |
47 |
is determined by the virtual/jdk dependency of the ebuild and settings |
48 |
in /etc/java-config-2/build/jdk.conf . In this jdk.conf, you could go like: |
49 |
|
50 |
*=sun-jdk-1.5 |
51 |
|
52 |
And it would try to build packages that it can with 1.5. If a package |
53 |
can only be built with 1.4, then the vm would be switched to a 1.4 vm. |
54 |
|
55 |
So.... this suggests to me that you have a line like the one above in |
56 |
jdk.conf. Is this the case? |
57 |
>>>> # which java |
58 |
>>>> |
59 |
>>> /usr/bin/java |
60 |
>>> localhost ~ # ls -l /usr/bin/java |
61 |
>>> lrwxrwxrwx 1 root root 22 Abr 6 17:00 /usr/bin/java |
62 |
>>> -> /usr/bin/run-java-tool |
63 |
>>> |
64 |
>>>> # java -version |
65 |
>>>> |
66 |
>>> java version "1.5.0_06" |
67 |
>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) |
68 |
>>> Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode) |
69 |
>>> |
70 |
>> The above confirms that fact. |
71 |
>> |
72 |
>> |
73 |
>>>> # echo ${PATH} |
74 |
>>>> |
75 |
>>> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin: |
76 |
>>> /usr/i686-pc-linux-gnu/gcc-bin/3.4.6:/opt/sun-jdk-1.4.2.10/bin: |
77 |
>>> /opt/sun-jdk-1.4.2.10/jre/bin:/opt/sun-jdk-1.4.2.10/jre/javaws |
78 |
>>> |
79 |
>> Here the /usr/bin/java symliked to run-java-tool takes precedence |
80 |
>> over the /opt/sun-jdk-1.4.2.10/bin (this is expected). |
81 |
>> |
82 |
>> |
83 |
>>>> # emerge -pv =sun-jdk-1.4* |
84 |
>>>> |
85 |
>>> [ebuild NSF ] dev-java/java-sdk-docs-1.4.2 33,591 kB |
86 |
>>> [ebuild Rf ] dev-java/sun-jdk-1.4.2.10-r13 USE="X alsa doc* |
87 |
>>> nsplugin* -jce" 0 kB [5] |
88 |
>>> |
89 |
>>> Total size of downloads: 33,591 kB |
90 |
>>> Portage overlays: |
91 |
>>> [1] /usr/portage/local/layman/portage |
92 |
>>> [2] /usr/portage/local/layman/bmg-main |
93 |
>>> [3] /usr/portage/local/layman/gentopia |
94 |
>>> [4] /usr/portage/local/layman/java-experimental |
95 |
>>> [5] /usr/portage/local/layman/migration |
96 |
>>> |
97 |
>> A nice set of overlays ;) |
98 |
>> Most probably you've stepped onto a problem similar to the one already |
99 |
>> discussed (mixing java-experimental and migration overlays is not always |
100 |
>> healthy), see here: |
101 |
>> http://thread.gmane.org/gmane.linux.gentoo.java/825/focus=825 |
102 |
>> |
103 |
>> However, setting your preferred gen-2 system VM and rebuilding the offensive |
104 |
>> packages should help. You can try to find them by using: |
105 |
>> |
106 |
>> # emerge -pvet junit | less |
107 |
>> |
108 |
>> But spotting said packages requires a bit of patience and a good eye :) |
109 |
>> However, the situation is fixable, either manually or maybe through |
110 |
>> the java-1.5-fixer (http://article.gmane.org/gmane.linux.gentoo.java/839) |
111 |
>> |
112 |
>> BTW, if you choose to try the java-1.5-fixer script, could you please |
113 |
>> describe your experiences? I never used this (never needed it, though) |
114 |
>> but I'm curious how this could help in such situation. |
115 |
>> |
116 |
>> Wiktor |
117 |
>> |
118 |
>> |
119 |
> |
120 |
> |
121 |
[1] |
122 |
https://projects.gentooexperimental.org/expj/wiki/Old_system_new_system_and_why |
123 |
-- |
124 |
gentoo-java@g.o mailing list |