This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Tuesday 30 October 2007, Nix wrote:
> On 29 Oct 2007, Mike Frysinger uttered the following:
> > On Monday 29 October 2007, Nix wrote:
> >> CONFIGURE=$1
> >> shift
> >> $CONFIGURE --build=i686-pc-linux-gnu "$@"
> >
> > dunno man ... i have CFLAGS="-O2 -march=i686" and targetting
> > i686-pc-linux-gnu and it builds for me.
>
> 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

> The behaviour of inlines has changed in 4.3.x (but not, one would have
> thought, so much that redefining inlines with completely different
> definitions would be acceptable).

only "extern inline" is changing meaning, but glibc forces -fgnu89-inline onto 
the build system, so that doesnt matter

> >> --build-id and --as-needed by default at link time, and the latter at
> >> least is bad for the glibc testsuite. I have patches to allow glibc to
> >> build with a default-on --build-id, if you want them, but they're so
> >> trivial I thought nobody would care...)
> >
> > i'd check cvs head and if it's still broken, post the patch
>
> 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 
patch configure, you patch configure.in and regenerating configure is 
implied.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]