This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] glibc 2.7 compilation failure with GCC 4.2.x due to 486+-specific memmove() redeclaration and _FORTIFY_SOURCEry
- From: Nix <nix at esperi dot org dot uk>
- To: Greg Schafer <gschafer at zip dot com dot au>
- Cc: libc-alpha at sources dot redhat dot com, Jakub Jelinek <jakub at redhat dot com>
- Date: Wed, 31 Oct 2007 23:31:34 +0000
- Subject: Re: [PATCH] glibc 2.7 compilation failure with GCC 4.2.x due to 486+-specific memmove() redeclaration and _FORTIFY_SOURCEry
- References: <firstname.lastname@example.org> <20071031012650.GA5045@eyo32.local>
On 31 Oct 2007, Greg Schafer told this:
> Umm, it appears you built Glibc with `--enable-omitfp' which is why it
> doesn't fail for everyone. `-D__USE_STRING_INLINES' is the giveaway.
Ahhh, quite right.
> Not sure whether `--enable-omitfp' is a valid config these days...
I thought it had been recommended for donkey's years because of the
performance boost: I've been using it since 1999, and this is the first
problem I can attribute to it. (There has long been discussion of making
-fomit-frame-pointer the default for x86: my understanding was that if
-fasynchronous-inline-tables were the default, as it is on x86-64, so
that exception throws from signal handlers worked in the absence of
frame pointers and the stack-frame walking MD_FALLBACK_FRAME_STATE_FOR
was never needed, it would have been the default ever since GDB learned
to read DWARF2 unwind info. But I may be wrong.)
`Some people don't think performance issues are "real bugs", and I think
such people shouldn't be allowed to program.' --- Linus Torvalds