From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1PhkQ8-000269-4r for garchives@archives.gentoo.org; Tue, 25 Jan 2011 15:03:00 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 92343E0C6E for ; Tue, 25 Jan 2011 15:02:59 +0000 (UTC) Received: from mail-ew0-f53.google.com (mail-ew0-f53.google.com [209.85.215.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 9D0D6E0C0F for ; Tue, 25 Jan 2011 14:24:53 +0000 (UTC) Received: by ewy6 with SMTP id 6so3017611ewy.40 for ; Tue, 25 Jan 2011 06:24:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=hobUsWMa6I7gy3kt6H09wpE/eWq9M43zIT9rfvMln94=; b=D/mz0xjxjOp4FPIz3Is/+/xfOZF+OwgfHKQSm0aw0E/wq2sNAZrjn1T4xySBwN7jUH e0XzR/lg8wqoyMmx1Ajh63qQIys1h6kHYb6sulXqjmX9AItdzSmanUnc0cvyuh30NOqk VTuPMFpgJ0mZ1FSfdDQKZ0BOq7BzRjre6ZoqQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=GcOmgOz0f57kwt4xuYNb/HbN3e4ueGnkIHNey8buqJIsFQo61iR995dq/Cvh9wnirA tDnl5Hj6CTi+0cN70EUAusG1ihkEJ6nNCNHEAeAFxZbQWGHofRY+AA0dt43U0J0Hei/r bTBYxsYZOaCnSILEaSZuHSyxgAeNMFDJqHdDA= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org MIME-Version: 1.0 Received: by 10.216.186.196 with SMTP id w46mr4738521wem.105.1295965492744; Tue, 25 Jan 2011 06:24:52 -0800 (PST) Received: by 10.216.25.1 with HTTP; Tue, 25 Jan 2011 06:24:52 -0800 (PST) Received: by 10.216.25.1 with HTTP; Tue, 25 Jan 2011 06:24:52 -0800 (PST) In-Reply-To: References: <78klsgyekk5bua0e73p3n7la.1295615457472@email.android.com> Date: Wed, 26 Jan 2011 01:24:52 +1100 Message-ID: Subject: Re: [gentoo-amd64] Re: bug report help From: Lie Ryan To: gentoo-amd64@lists.gentoo.org Content-Type: multipart/alternative; boundary=0016e649daead618e4049aac7a81 X-Archives-Salt: X-Archives-Hash: eaa60f85a3e4de3eef9126610992b2e0 --0016e649daead618e4049aac7a81 Content-Type: text/plain; charset=ISO-8859-1 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.duncan@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 --0016e649daead618e4049aac7a81 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

It was actually quite easy now to emerge icedtea from source, you just n= eed to add the java overlay and then emerge as usual. After emerge and if y= ou are keeping the binary icedtea or sun's, you'd then need to poin= t your preferred java vm using eselect.

(Apology for the top post, the Gmail client in Android 2.1 doesn't a= llow 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.duncan@cox.net> wrote:=

Fernando Boaglio posted on Mon, 24 Jan 2011 13:41:59 -0200 as excer= pted:


> 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. =A0As 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 buil= d-
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 wha= t
originally triggered the bug, that /might/ be your issue. =A0However, I
don't know that it does.

2) What version of glibc do you have? =A0Unless 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.ne= t/Articles/414467/

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
handled when found to break things, etc.

http://lwn.ne= t/Articles/416821/

FWIW, I'm with the glibc folks here. =A0The behavior is specifically sa= id 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 --<= br> unless you overlap the copies, but then that's not a simple copy so
shouldn't be using the copy function! =A0Duh!

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. =A0If i= t had
instead been specifically documented as changeable, much like the kernel= 9;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. =A0 No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." =A0Richard Stallman

--0016e649daead618e4049aac7a81--