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
On 30 Oct 2007, Mike Frysinger told this:
> On Tuesday 30 October 2007, Nix wrote:
>> Maybe this is a GCC version thing? Are you building with 4.2.x?
> of course ... your subject says "GCC 4.2.x" after all and using anything other
> than 4.2.2 would be silly considering the # of crap bugs in gcc-4.2.x so far
Er. OK, sorry, I managed to forget my own subject line. :)
>> Checked with a tree pristine except for the following utterly trivial
>> patch (provided for completeness), which I need in order for configure
>> to run at all, because my installed Linux headers are stowed like
>> everything else and thus are expected to be symlinks. (Also the check
>> might be considered wrong: `make install' won't destroy the target of
>> the symlinks if you install in the recommended way, by `make install
>> install_root=somewhere-else' and then using your packaging system to
>> move it into place. It will if you just use `make install', but hasn't
>> Ulrich said over and over again that anyone doing that deserves what
>> they get?):
> nowadays, you should not have symlinks in /usr/include for your kernel
> headers ... are you saying you're
> symlinks /usr/include/... -> /usr/src/linux/include/... ? also, you never
Nope. I manage my system with stow, so the /usr/include paths are
(indirect) symlinks to /usr/stow/linux-kernel-headers/18.104.22.168/include/,
all generated by `make headers-install'.
> patch configure, you patch configure.in and regenerating configure is
I patched both because this was a short-term kludge and it was trivial
to do so (I just didn't see the point in spamming you with essentially
the same text twice over).
`Some people don't think performance issues are "real bugs", and I think
such people shouldn't be allowed to program.' --- Linus Torvalds