On Wed, May 04, 2011 at 02:30:35PM +0200, Aurelien Jarno wrote:
> Le 04/05/2011 07:42, Steve M. Robbins a écrit :
> > On Wed, May 04, 2011 at 12:10:48AM -0500, Jonathan Nieder wrote:
> > 
> >> Sounds like http://sourceware.org/bugzilla/show_bug.cgi?id=12518
> >> which is fixed (sort of) by commit 0354e355 (2011-04-01).
> > 
> > Oh my word.  So glibc 2.13 breaks random binaries that happened to
> > incorrectly use memcpy() instead of memmove()?  What's wrong with the
> > glibc developers (and Ulrich Drepper in particular)?
> > 
> > I'm with Linus on this: let's just revert to the old behaviour.  A
> > tiny amount of clock cycles saved isn't worth the instability.
> > 
> > Thanks,
> > -Steve
> > 
> > P.S.  I tried rebuilding glibc myself locally, but gcc also segfaults
> > in the process :-(
> > 
> 
> Are you sure it is something related? Which gcc version are you using?
> Do you have a backtrace point to the same issue?
> 
> I am using this libc version for two months (on a CPU having ssse3
> instruction set), it is also used by other distributions, so I find
> strange it breaks something so common than gcc. For XOrg it can be due
> to the difference in configuration, that's why the problem stayed unnoticed.
> 

Any news about that? Which GCC version is affected? Can you please send
us the backtrace?

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurel...@aurel32.net                 http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110507102515.ga24...@hall.aurel32.net

Reply via email to