| 1 |
It was actually quite easy now to emerge icedtea from source, you just need |
| 2 |
to add the java overlay and then emerge as usual. After emerge and if you |
| 3 |
are keeping the binary icedtea or sun's, you'd then need to point your |
| 4 |
preferred java vm using eselect. |
| 5 |
|
| 6 |
(Apology for the top post, the Gmail client in Android 2.1 doesn't allow you |
| 7 |
to even delete the quoted text, this was fixed in 2.2 but you and I had to |
| 8 |
bear with this for the moment) |
| 9 |
|
| 10 |
On 25/01/2011 1:03 PM, "Duncan" <1i5t5.duncan@×××.net> wrote: |
| 11 |
|
| 12 |
Fernando Boaglio posted on Mon, 24 Jan 2011 13:41:59 -0200 as excerpted: |
| 13 |
|
| 14 |
|
| 15 |
> I did, same thing: |
| 16 |
> |
| 17 |
> |
| 18 |
> fb@de09 ~/eclipse $ ./eclipse -vm /opt/icedtea6-bin-1.9.4/bin/java |
| 19 |
> ... |
| 20 |
Two notes, here: |
| 21 |
|
| 22 |
1) I don't know about sunjdk as there's license issues such that I won't |
| 23 |
install it, but the iced-tea6-bin package, while free, is a pre-compiled |
| 24 |
binary install. As such, revdep-rebuild won't be able to do anything for |
| 25 |
it as it'll just reinstall the same binary, so the package installs a |
| 26 |
revdep-rebuild control file so revdep-rebuild skips checking it, to |
| 27 |
prevent reinstalls that wouldn't fix anything. |
| 28 |
|
| 29 |
FWIW there's the icedtea package for from-source building, but the build- |
| 30 |
process is said to be quite convoluted, many dependencies, etc., thus the |
| 31 |
binary package option. |
| 32 |
|
| 33 |
If the sunjdk package similarly has binary components, since that's what |
| 34 |
originally triggered the bug, that /might/ be your issue. However, I |
| 35 |
don't know that it does. |
| 36 |
|
| 37 |
2) What version of glibc do you have? Unless you're running ~arch or even |
| 38 |
masked/live, this probably doesn't apply, but... LWN article posted Nov |
| 39 |
10, 2010 about a glibc change to memcpy behavior when used in a context |
| 40 |
with specifically undefined behavior: |
| 41 |
|
| 42 |
http://lwn.net/Articles/414467/ |
| 43 |
|
| 44 |
Also see the Nov 24, 2010 longer LWN commentary article, which covers both |
| 45 |
the glibc change and a kernel behavior change, examining how they were |
| 46 |
handled when found to break things, etc. |
| 47 |
|
| 48 |
http://lwn.net/Articles/416821/ |
| 49 |
|
| 50 |
FWIW, I'm with the glibc folks here. The behavior is specifically said to |
| 51 |
be undefined when the memory regions overlap, and think about it, if your |
| 52 |
memory source and destination regions overlap, by definition it's not a |
| 53 |
simple copy anyway, as the data in the source region has changed at the |
| 54 |
end and with a simple copy, it should intuitively be the same as it was -- |
| 55 |
unless you overlap the copies, but then that's not a simple copy so |
| 56 |
shouldn't be using the copy function! Duh! |
| 57 |
|
| 58 |
The kernel thing is specifically different, in part because Linus has |
| 59 |
established clear rules about breaking the kernel/userspace interface (in |
| 60 |
a word, don't!) -- part of the reason that change was reverted. If it had |
| 61 |
instead been specifically documented as changeable, much like the kernel's |
| 62 |
internal interfaces are (much to the dismay of many closed-source kernel |
| 63 |
module devs)... the outcome there would likely have been similar to the |
| 64 |
glibc outcome. |
| 65 |
|
| 66 |
-- |
| 67 |
Duncan - List replies preferred. No HTML msgs. |
| 68 |
"Every nonfree program has a lord, a master -- |
| 69 |
and if you use the program, he is your master." Richard Stallman |
Archives