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
