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