Bugzilla Bug 218748

GCC fails to build with sys-libs/glibc-2.5 installed. Here is the error
generated:

if /bin/sh ./libtool --tag=CC --mode=compile
/var/tmp/portage/sys-devel/gcc-4.3.0/work/build/./gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-4.3.0/work/build/./gcc/
-B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem
/usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include
-DHAVE_CONFIG_H -I.
-I/var/tmp/portage/sys-devel/gcc-4.3.0/work/gcc-4.3.0/libgfortran -I. 
-iquote/var/tmp/portage/sys-devel/gcc-4.3.0/work/gcc-4.3.0/libgfortran/io
-I/var/tmp/portage/sys-devel/gcc-4.3.0/work/gcc-4.3.0/libgfortran/../gcc
-I/var/tmp/portage/sys-devel/gcc-4.3.0/work/gcc-4.3.0/libgfortran/../gcc/config
-I../.././gcc -D_GNU_SOURCE  -std=gnu99 -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g -O2
-march=athlon-mp -pipe   -MT unix.lo -MD -MP -MF ".deps/unix.Tpo" -c -o unix.lo
`test -f 'io/unix.c' || echo
'/var/tmp/portage/sys-devel/gcc-4.3.0/work/gcc-4.3.0/libgfortran/'`io/unix.c; \
        then mv -f ".deps/unix.Tpo" ".deps/unix.Plo"; else rm -f
".deps/unix.Tpo"; exit 1; fi
libtool: compile:  /var/tmp/portage/sys-devel/gcc-4.3.0/work/build/./gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-4.3.0/work/build/./gcc/
-B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem
/usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include
-DHAVE_CONFIG_H -I.
-I/var/tmp/portage/sys-devel/gcc-4.3.0/work/gcc-4.3.0/libgfortran -I.
-iquote/var/tmp/portage/sys-devel/gcc-4.3.0/work/gcc-4.3.0/libgfortran/io
-I/var/tmp/portage/sys-devel/gcc-4.3.0/work/gcc-4.3.0/libgfortran/../gcc
-I/var/tmp/portage/sys-devel/gcc-4.3.0/work/gcc-4.3.0/libgfortran/../gcc/config
-I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g -O2
-march=athlon-mp -pipe -MT unix.lo -MD -MP -MF .deps/unix.Tpo -c
/var/tmp/portage/sys-devel/gcc-4.3.0/work/gcc-4.3.0/libgfortran/io/unix.c 
-fPIC -DPIC -o .libs/unix.o
/usr/include/bits/mathinline.h: Assembler messages:
/usr/include/bits/mathinline.h:6322: Error: symbol `fstatat64' is already
defined
/usr/include/bits/mathinline.h:6357: Error: symbol `fstat64' is already defined
/usr/include/bits/mathinline.h:7152: Error: symbol `lstat64' is already defined
/usr/include/bits/mathinline.h:7183: Error: symbol `stat64' is already defined
make[3]: *** [unix.lo] Error 1
make[3]: Leaving directory
`/var/tmp/portage/sys-devel/gcc-4.3.0/work/build/i686-pc-linux-gnu/libgfortran'
make[2]: *** [install] Error 2
make[2]: Leaving directory
`/var/tmp/portage/sys-devel/gcc-4.3.0/work/build/i686-pc-linux-gnu/libgfortran'
make[1]: *** [install-target-libgfortran] Error 2
make[1]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.3.0/work/build'
make: *** [install] Error 2

After upgrading to sys-libs/glibc-2.6.1, the same compilation line succeeds.

Reproducible: Always

Steps to Reproduce:
1. Have glibc-2.5 installed
2. Emerge gcc-4.3.0
3. Emerge failuse

emerge --info, please.

Also, why don't you just upgrade to a current glibc?

This might be a duplicate of bug 218603.

(In reply to comment #1)
> emerge --info, please.
Meh, I thought it to be irrelevant since gcc does merge if I upgrade glibc and
nothing else ;)

> Also, why don't you just upgrade to a current glibc?
> 

Did that, but that still means the ebuild doesn't set dependencies correctly.

(In reply to comment #2)
Probably, though the error is not indicated in that bug report so I can't
compare.

(In reply to comment #3)
> (In reply to comment #1)
> > emerge --info, please.
> Meh, I thought it to be irrelevant since gcc does merge if I upgrade glibc and
> nothing else ;)

glibc-2.5 is being deprecated left and right as we speak.

> > Also, why don't you just upgrade to a current glibc?
> > 
> 
> Did that, but that still means the ebuild doesn't set dependencies correctly.

The profile normally sets that, and `emerge -vuaDN system` makes sure you end
up with a sane base system.

It's still a maybe to me, so let's get the toolchain people to have the final
say.

(In reply to comment #4)
[..snip...]
> 
> > > Also, why don't you just upgrade to a current glibc?
> > > 
> > 
> > Did that, but that still means the ebuild doesn't set dependencies correctly.
> 
> The profile normally sets that, and `emerge -vuaDN system` makes sure you end
> up with a sane base system.
> 
> It's still a maybe to me, so let's get the toolchain people to have the final
> say.
> 

Running `emerge -vuaDN system` is evil and is definitely not the correct
procedure in my book. My systems are very sensitive to change and I can't
afford such major disruptions of the entire system. ;) 

Not the exact same error message but the same resolution as bug #191088.

*** This bug has been marked as a duplicate of bug 191088 ***