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. -- 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/4dc146eb.9000...@aurel32.net
