Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-amd64
Navigation:
Lists: gentoo-amd64: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-amd64@g.o
From: Lie Ryan <lie.1296@...>
Subject: Re: Re: bug report help
Date: Wed, 26 Jan 2011 01:24:52 +1100
<p>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&#39;s, you&#39;d then need to point your preferred java vm using eselect.</p>

<p>(Apology for the top post, the Gmail client in Android 2.1 doesn&#39;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)</p>
<p><blockquote type="cite">On 25/01/2011 1:03 PM, &quot;Duncan&quot; &lt;<a href="mailto:1i5t5.duncan@...">1i5t5.duncan@...</a>&gt; wrote:<br><br>Fernando Boaglio posted on Mon, 24 Jan 2011 13:41:59 -0200 as excerpted:<br>

<p><font color="#500050"><br>&gt; I did, same thing:<br>&gt; <br>&gt; <br>&gt; fb@de09 ~/eclipse $ ./eclipse -vm /opt/icedtea6-bin-1.9.4/bin/java <br>&gt; ...</font></p>Two notes, here:<br>
<br>
1) I don&#39;t know about sunjdk as there&#39;s license issues such that I won&#39;t<br>
install it, but the iced-tea6-bin package, while free, is a pre-compiled<br>
binary install.  As such, revdep-rebuild won&#39;t be able to do anything for<br>
it as it&#39;ll just reinstall the same binary, so the package installs a<br>
revdep-rebuild control file so revdep-rebuild skips checking it, to<br>
prevent reinstalls that wouldn&#39;t fix anything.<br>
<br>
FWIW there&#39;s the icedtea package for from-source building, but the build-<br>
process is said to be quite convoluted, many dependencies, etc., thus the<br>
binary package option.<br>
<br>
If the sunjdk package similarly has binary components, since that&#39;s what<br>
originally triggered the bug, that /might/ be your issue.  However, I<br>
don&#39;t know that it does.<br>
<br>
2) What version of glibc do you have?  Unless you&#39;re running ~arch or even<br>
masked/live, this probably doesn&#39;t apply, but... LWN article posted Nov<br>
10, 2010 about a glibc change to memcpy behavior when used in a context<br>
with specifically undefined behavior:<br>
<br>
<a href="http://lwn.net/Articles/414467/" target="_blank">http://lwn.net/Articles/414467/</a><br>
<br>
Also see the Nov 24, 2010 longer LWN commentary article, which covers both<br>
the glibc change and a kernel behavior change, examining how they were<br>
handled when found to break things, etc.<br>
<br>
<a href="http://lwn.net/Articles/416821/" target="_blank">http://lwn.net/Articles/416821/</a><br>
<br>
FWIW, I&#39;m with the glibc folks here.  The behavior is specifically said to<br>
be undefined when the memory regions overlap, and think about it, if your<br>
memory source and destination regions overlap, by definition it&#39;s not a<br>
simple copy anyway, as the data in the source region has changed at the<br>
end and with a simple copy, it should intuitively be the same as it was --<br>
unless you overlap the copies, but then that&#39;s not a simple copy so<br>
shouldn&#39;t be using the copy function!  Duh!<br>
<br>
The kernel thing is specifically different, in part because Linus has<br>
established clear rules about breaking the kernel/userspace interface (in<br>
a word, don&#39;t!) -- part of the reason that change was reverted.  If it had<br>
instead been specifically documented as changeable, much like the kernel&#39;s<br>
internal interfaces are (much to the dismay of many closed-source kernel<br>
module devs)... the outcome there would likely have been similar to the<br>
glibc outcome.<br>
<font color="#888888"><br>
--<br>
Duncan - List replies preferred.   No HTML msgs.<br>
&quot;Every nonfree program has a lord, a master --<br>
and if you use the program, he is your master.&quot;  Richard Stallman<br>
<br>
<br>
</font></blockquote></p>
Replies:
Re: bug report help
-- Jonathan Callen
References:
Re: bug report help
-- Randy Barlow
Re: bug report help
-- Fernando Boaglio
Re: bug report help
-- Claes Gyllenswärd
Re: bug report help
-- Fernando Boaglio
Re: bug report help
-- Duncan
Navigation:
Lists: gentoo-amd64: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Re: bug report help
Next by thread:
Re: bug report help
Previous by date:
Re: Re: bug report help
Next by date:
Re: bug report help


Updated Jun 28, 2012

Summary: Archive of the gentoo-amd64 mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.