Re: [PATCH] glibc 2.7 compilation failure with GCC 4.2.x due to 486+-specific memmove() redeclaration and _FORTIFY_SOURCEry

[Nix <nix at esperi dot org dot uk>]

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/2.6.23.1/include/,
all generated by `make headers-install'.

> patch configure, you patch configure.in and regenerating configure is 
> implied.

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