This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
Attempting to build gcc-4.3.0 with a centos-4.6 (fully patched) using the centos compiler: Exact version of gcc used to build gcc-4.3.0: gcc version 4.1.2 20070626 (Red Hat 4.1.2-14) Options when GCC was configured/built: export CC=gcc4 ./configure --prefix=/opt/pkg/gcc-4.3.0 --with-gmp=/opt/pkg/gmp-4.2.2 --with -mpfr=/opt/pkg/mpfr-2.3.1 Options when building gmp-4.2.2: export CC=gcc4 ./configure --prefix=/opt/pkg/gmp-4.2.2 Options when building mpfr-2.3.1: export CC=gcc4 ./configure --prefix=/opt/pkg/mpfr-2.3.1 --with-gmp=/opt/pkg/gmp-4.2.2/ --with-gmp-build=/opt/src/gmp-4.2.2/ result from make (after an hour or so on a dual opteron): make[3]: Entering directory `/opt/src/gcc-4.3.0/x86_64-unknown-linux-gnu/libgfortran' /bin/sh ./libtool --tag=CC --mode=link /opt/src/gcc-4.3.0/host-x86_64-unknown-linux-gnu/gcc/xgcc -B/opt/src/gcc-4.3.0/host-x86_64-unknow n-linux-gnu/gcc/ -B/opt/pkg/gcc-4.3.0/x86_64-unknown-linux-gnu/bin/ -B/opt/pkg/gcc-4.3.0/x86_64-unknown-linux-gnu/lib/ -isystem /opt/pkg /gcc-4.3.0/x86_64-unknown-linux-gnu/include -isystem /opt/pkg/gcc-4.3.0/x86_64-unknown-linux-gnu/sys-include -std=gnu99 -Wall -Wstrict-p rototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g -g -O2 -o libgfortran.la -rpath /opt/pkg/gcc-4. 3.0/lib/../lib64 -version-info `grep -v '^#' ../.././libgfortran/libtool-version` -lm -Wl,--version-script=../.././libgfortran/gfortran .map backtrace.lo compile_options.lo environ.lo error.lo fpu.lo main.lo memory.lo pause.lo stop.lo string.lo select.lo all_l1.lo ...... libtool: link: /opt/src/gcc-4.3.0/host-x86_64-unknown-linux-gnu/gcc/xgcc -B/opt/src/gcc-4.3.0/host-x86_64-unknown-linux-gnu/gcc/ -B/opt/ pkg/gcc-4.3.0/x86_64-unknown-linux-gnu/bin/ -B/opt/pkg/gcc-4.3.0/x86_64-unknown-linux-gnu/lib/ -isystem /opt/pkg/gcc-4.3.0/x86_64-unknow n-linux-gnu/include -isystem /opt/pkg/gcc-4.3.0/x86_64-unknown-linux-gnu/sys-include -shared .libs/backtrace.o .libs/compile_options.o .libs/environ.o .libs/error.o .libs/fpu.o .libs/main.o . .... s/_dim_r4.o .libs/_dim_r8.o .libs/_dim_r10.o .libs/_dim_r16.o .libs/_atan2_r4.o .libs/_atan2_r8.o .libs/_atan2_r10.o .libs/_atan2_r16.o .libs/_mod_i4.o .libs/_mod_i8.o .libs/_mod_i16.o .libs/_mod_r4.o .libs/_mod_r8.o .libs/_mod_r10.o .libs/_mod_r16.o .libs/misc_specifics. o .libs/dprod_r8.o .libs/f2c_specifics.o -lm -Wl,--version-script=../.././libgfortran/gfortran.map -Wl,-soname -Wl,libgfortran.so.3 - o .libs/libgfortran.so.3.0.0 .libs/compile_options.o(.text+0x0): In function `feof_unlocked': /usr/include/bits/stdio.h:113: multiple definition of `feof_unlocked' .libs/backtrace.o(.text+0x0):/usr/include/bits/stdio.h:113: first defined here
This is a bug in the glibc headers. We should fixincludes them though. Can you attach /usr/include/bits/stdio.h ? And also mention which glibc version you are using.
Created an attachment (id=15339) [edit] stdio.h as requested.
rpm claims: glibc-2.3.4-2.39 glibc-headers-2.3.4-2.39 glibc-devel-2.3.4-2.39 compat-glibc-headers-2.3.2-95.30 ls -al /lib/libc-2.3.4.so -rwxr-xr-x 1 root root 1516768 Nov 16 08:37 /lib/libc-2.3.4.so
(In reply to comment #2) > Created an attachment (id=15339) [edit] > stdio.h as requested. That is /usr/include/stdio.h, not the one I requested /usr/include/bits/stdio.h :).
Created an attachment (id=15340) [edit] bits/stdio.h This is the correct file as requested, I'll attempt to delete the previous wrong version.
Looks like the reason why it was not being fixed because of: __NTH (feof_unlocked (FILE *__stream))
(In reply to comment #6) > Looks like the reason why it was not being fixed because of: > __NTH (feof_unlocked (FILE *__stream)) > So how would I fix it?
(In reply to comment #6) > Looks like the reason why it was not being fixed because of: > __NTH (feof_unlocked (FILE *__stream)) > So how would I fix it?(In reply to comment #6) > Looks like the reason why it was not being fixed because of: > __NTH (feof_unlocked (FILE *__stream)) > BTW, this seems pretty common, I looked at Ubuntu Gutsy 7.10 system and it has the same definition: cat /usr/include/bits/stdio.h | grep feof_unlocked | head -1 __NTH (feof_unlocked (FILE *__stream))
(In reply to comment #8) > (In reply to comment #6) > > Looks like the reason why it was not being fixed because of: > > __NTH (feof_unlocked (FILE *__stream)) > > > > So how would I fix it?(In reply to comment #6) > > Looks like the reason why it was not being fixed because of: > > __NTH (feof_unlocked (FILE *__stream)) > > > > BTW, this seems pretty common, I looked at Ubuntu Gutsy 7.10 system and it has > the same definition: > cat /usr/include/bits/stdio.h | grep feof_unlocked | head -1 > __NTH (feof_unlocked (FILE *__stream)) > I reproduced this error on Centos-5.1 as well.
Created an attachment (id=15361) [edit] Ubuntu 7.10 (fully patched) glibc-2.6.1 features.h As requested.
Created an attachment (id=15362) [edit] Centos-5.1, glibc-2.5, features.h as requested.
Created an attachment (id=15363) [edit] centos-4.6, glibc-2.3.4, features.h as requested, from a patched system.
The Ubuntu 7.10 features should have been matched. Maybe this is a problem with building in the src dir. Can you try building GCC in an object directory?
(In reply to comment #13) > The Ubuntu 7.10 features should have been matched. > > Maybe this is a problem with building in the src dir. > > Can you try building GCC in an object directory? > That fixed it on all 3 platforms (centos-4.6, 5.1, and ubuntu 7.10). Thanks.
Closed as invalid.
(In reply to comment #15) > Closed as invalid. This bug is not invalid, just you are not building GCC the recommended way.
*** Bug 36349 has been marked as a duplicate of this bug. ***
4.3.1 is being released, adjusting target milestone.
Andrew -- Why did you reopen this? It sounds like the submitter was building in the srcdir, and that when building in the objdir, it worked fined. Isn't that exactly the situation we expect? -- Mark
Actually we made it work at some point and that is even documented: "First, we @strong{highly} recommend that GCC be built into a separate directory than the sources which does @strong{not} reside within the source tree. This is how we generally build GCC; building where @var{srcdir} == @var{objdir} should still work, but doesn't get extensive testing; building where @var{objdir} is a subdirectory of @var{srcdir} is unsupported." but lowering priority according to the strong suggestion in the docs.
*** Bug 36946 has been marked as a duplicate of this bug. ***
4.3.2 is released, changing milestones to 4.3.3.
*** Bug 37564 has been marked as a duplicate of this bug. ***
*** Bug 37925 has been marked as a duplicate of this bug. ***
GCC 4.3.3 is being released, adjusting target milestone.
*** Bug 40212 has been marked as a duplicate of this bug. ***
*** Bug 40555 has been marked as a duplicate of this bug. ***
GCC 4.3.4 is being released, adjusting target milestone.
*** Bug 41362 has been marked as a duplicate of this bug. ***
*** Bug 41363 has been marked as a duplicate of this bug. ***
Subject: Bug 35619 Author: rwild Date: Sat Sep 19 08:29:58 2009 New Revision: 151880 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151880 Log: Fix long-standing in-tree build include-fixed bug. gcc/: PR bootstrap/35619 * Makefile.in (stmp-fixinc): Ensure `include-fixed' is created in the directory this rule is called from, rather than the toplevel 'gcc' directory, to fix in-tree build. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in
Fixed on trunk.