[Bug bootstrap/30915] New: [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu

------- Comment #19 from martin dot jansa at mk dot cvut dot cz  2007-03-12 22:30 -------
(In reply to comment #18)
> (In reply to comment #17)
> > I can confirm this patch works on an amd64 gentoo sytem too.
>
> And what happens if you just change that #include_next to #include <stdio.h>,
> that would be useful in understanding the issue and how much of it has to do
> with #include_next (note that, at the moment, as far as I can see, the
> #include_next special features are still not used)

this isn't enough even with building with this brand new
gcc-4.3.0_alpha20070309.
I'll repeat it with include of proper stdio.h, which looks in gentoo multilib
like this

jama gcc # cat /usr/include/stdio.h
/* Autogenerated by create_ml_includes() in multilib.eclass */

#ifdef __i386__
# include <gentoo-multilib/x86/stdio.h>
#endif /* __i386__ */

#ifdef __x86_64__
# include <gentoo-multilib/amd64/stdio.h>
#endif /* __x86_64__ */

and with
#include <stdio>
without ".h" after that

so I'll send results tomorrow


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915

------- Comment #20 from pcarlini at suse dot de  2007-03-12 23:09 -------
(In reply to comment #19)
...
> this isn't enough even with building with this brand new
> gcc-4.3.0_alpha20070309.
> I'll repeat it with include of proper stdio.h, which looks in gentoo multilib
> like this
>
> jama gcc # cat /usr/include/stdio.h

Ok, thanks. But then, an important question is: which (empty? not including any
declaration of the expected facilities?!? What header is that?) stdio.h is
instead included at build time if you don't specify explicitely the path? You
should try to figure out that, whether on your system there are around (in the
build directory or elsewhere) stdio.h which in fact are not the correct one.

In order to do that, you could proceed as follows: go the build directory of
the library and invoke by hand the same line which is failing the build of
compatibility.cc, but running only the preprocessor, with -E. You save its
output, it should tell us what a heck of wrong stdio.h is included.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915

------- Comment #21 from pcarlini at suse dot de  2007-03-12 23:32 -------
(In reply to comment #15)
> ./build/gcc/include-fixed/stdio.h
...
> ./build/stage1-gcc/include-fixed/stdio.h
> ./build/prev-gcc/include-fixed/stdio.h

Interestingly, these stdio.h do not exist on my x86_64 builds...


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915

------- Comment #22 from pinskia at gcc dot gnu dot org  2007-03-12 23:33 -------
This is a bug in the gentoo distro ask them to fix how they do multilib.


--

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915

------- Comment #23 from martin dot jansa at mk dot cvut dot cz  2007-03-13 11:45 -------
(In reply to comment #22)
> This is a bug in the gentoo distro ask them to fix how they do multilib.
>

so results are (with gcc-4.3)

#include_next <stdio.h> - doesn't work
#include <stdio.h> - doesn't work
#include <stdio> - doesn't work
#include "/usr/include/stdio.h" - works
#include "/usr/include/gentoo-multilib/amd64/stdio.h" - works

when /usr/include/stdio.h works then it shouldn't be distro multilib bug,
should it?


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915

------- Comment #24 from eesrjhc at bath dot ac dot uk  2007-03-19 09:30 -------
(In reply to comment #20)

> (In reply to comment #19)
> ...
> > this isn't enough even with building with this brand new
> > gcc-4.3.0_alpha20070309.
> > I'll repeat it with include of proper stdio.h, which looks in gentoo multilib
> > like this
> >
> > jama gcc # cat /usr/include/stdio.h
>
> Ok, thanks. But then, an important question is: which (empty? not including any
> declaration of the expected facilities?!? What header is that?) stdio.h is
> instead included at build time if you don't specify explicitely the path? You
> should try to figure out that, whether on your system there are around (in the
> build directory or elsewhere) stdio.h which in fact are not the correct one.
>
> In order to do that, you could proceed as follows: go the build directory of
> the library and invoke by hand the same line which is failing the build of
> compatibility.cc, but running only the preprocessor, with -E. You save its
> output, it should tell us what a heck of wrong stdio.h is included.
>

Incidentally, I have (by using a binary search, bootstapping into an empty
build  directory each time) found that revision 121025 builds OK, while
revision 121027 fails with this problem.

Doing the suggestion above, this is what I get:

roger@hertz $ /MHz/roger/src/gcc-svn-121027/build-121027/./gcc/xgcc -sh
ared-libgcc -B/MHz/roger/src/gcc-svn-121027/build-121027/./gcc -nostdinc++
-L/MHz/roger/src/gcc-svn-121027/build-121027/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/MHz/roger/src/gcc-svn-121027/build-121027/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/usr/local/gcc-svn/x86_64-unknown-linux-gnu/bin/
-B/usr/local/gcc-svn/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/gcc-svn/x86_64-unknown-linux-gnu/include -isystem
/usr/local/gcc-svn/x86_64-unknown-linux-gnu/sys-include
-I/MHz/roger/src/gcc-svn-121027/build-121027/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/MHz/roger/src/gcc-svn-121027/build-121027/x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/MHz/roger/src/gcc-svn-121027/trunk/libstdc++-v3/libsupc++
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOURCE -c ../../../../trunk/libstdc++-v3/src/compatibility.cc  -fPIC
-DPIC -o .libs/compatibility.o -E -v
Reading specs from /MHz/roger/src/gcc-svn-121027/build-121027/./gcc/specs
Target: x86_64-unknown-linux-gnu
Configured with: ../trunk/configure --prefix=/usr/local/gcc-svn
--enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 4.3.0 20070121 (experimental)
 /MHz/roger/src/gcc-svn-121027/build-121027/./gcc/cc1plus -E -quiet -nostdinc++
-v
-I/MHz/roger/src/gcc-svn-121027/build-121027/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/MHz/roger/src/gcc-svn-121027/build-121027/x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/MHz/roger/src/gcc-svn-121027/trunk/libstdc++-v3/libsupc++ -iprefix
/MHz/roger/src/gcc-svn-121027/build-121027/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/
-isystem /MHz/roger/src/gcc-svn-121027/build-121027/./gcc/include -D_GNU_SOURCE
-D_GNU_SOURCE -DPIC -isystem
/usr/local/gcc-svn/x86_64-unknown-linux-gnu/include -isystem
/usr/local/gcc-svn/x86_64-unknown-linux-gnu/sys-include
../../../../trunk/libstdc++-v3/src/compatibility.cc -o .libs/compatibility.o
-mtune=generic -Wall -Wextra -Wwrite-strings -Wcast-qual
-fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -fPIC -fworking-directory -O2
ignoring nonexistent directory
"/usr/local/gcc-svn/x86_64-unknown-linux-gnu/include"
ignoring nonexistent directory
"/usr/local/gcc-svn/x86_64-unknown-linux-gnu/sys-include"
ignoring nonexistent directory
"/MHz/roger/src/gcc-svn-121027/build-121027/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/include"
ignoring nonexistent directory
"/MHz/roger/src/gcc-svn-121027/build-121027/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../x86_64-unknown-linux-gnu/include"
ignoring nonexistent directory
"/MHz/roger/src/gcc-svn-121027/build-121027/gcc/../lib/gcc//include"
ignoring nonexistent directory
"/MHz/roger/src/gcc-svn-121027/build-121027/gcc/../lib/gcc//lib/gcc/x86_64-unknown-linux-gnu/4.3.0/include"
ignoring nonexistent directory
"/MHz/roger/src/gcc-svn-121027/build-121027/gcc/../lib/gcc//lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/MHz/roger/src/gcc-svn-121027/build-121027/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu

/MHz/roger/src/gcc-svn-121027/build-121027/x86_64-unknown-linux-gnu/libstdc++-v3/include
 /MHz/roger/src/gcc-svn-121027/trunk/libstdc++-v3/libsupc++
 /MHz/roger/src/gcc-svn-121027/build-121027/./gcc/include
 /usr/local/include
 /usr/include
End of search list.

So, searching in order the directories listed above, the first occurence of
stdio.h in the directory concerned is this:

/MHz/roger/src/gcc-svn-121027/build-121027/./gcc/include/stdio.h

which contains this:

roger@hertz  $ cat
/MHz/roger/src/gcc-svn-121027/build-121027/./gcc/include/stdio.h
/*  DO NOT EDIT THIS FILE.

    It has been auto-edited by fixincludes from:

        "/usr/include/stdio.h"

    This had to be done to correct non-standard usages in the
    original, manufacturer supplied header file.  */

#ifndef FIXINC_WRAP_STDIO_H_STDIO_STDARG_H
#define FIXINC_WRAP_STDIO_H_STDIO_STDARG_H 1

#define __need___va_list
#include <stdarg.h>
/* Autogenerated by create_ml_includes() in multilib.eclass */

#ifdef __i386__
# include <gentoo-multilib/x86/stdio.h>
#endif /* __i386__ */

#ifdef __x86_64__
# include <gentoo-multilib/amd64/stdio.h>
#endif /* __x86_64__ */

#endif  /* FIXINC_WRAP_STDIO_H_STDIO_STDARG_H */


Could this be related to the problem in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29867


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915

------- Comment #25 from s_j_newbury at yahoo dot co dot uk  2007-08-08 01:45 -------
Created an attachment (id=14039)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14039&action=view)
Prevent fixincludes false positive on gentoo stdio.h wrapper

The fixincludes script is hitting a false positive when it scans the
/usr/include/stdio.h header wrapper on gentoo multilib systems.  Adding a
bypass for "gentoo-multilib" to the relevant fix solves this issue.
A multilib build successfully concludes with this patch.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915

------- Comment #26 from eesrjhc at bath dot ac dot uk  2007-08-08 13:19 -------
(In reply to comment #25)
> Created an attachment (id=14039)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14039&action=view) [edit]
> Prevent fixincludes false positive on gentoo stdio.h wrapper


Very many thanks, Steven: this has certainly done the trick. I can now
bootstrap into a clean build directory and the build (of C, C++ and fortran)
completes without errors.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915

------- Comment #27 from aldot at gcc dot gnu dot org  2007-09-11 18:58 -------
This also happens on SuSE-10.2, x86-64


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915

------- Comment #28 from jakub at gcc dot gnu dot org  2007-09-11 19:07 -------
Why does gentoo do this kind of crap with glibc headers?
They are already multilib clean.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915

------- Comment #29 from pcarlini at suse dot de  2007-11-22 12:58 -------
*** Bug 34190 has been marked as a duplicate of this bug. ***


--

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rene at gsse dot at


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915

------- Comment #30 from paolo dot carlini at oracle dot com  2008-06-07 13:34 -------
*** Bug 36456 has been marked as a duplicate of this bug. ***


--

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wbrana at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915

------- Comment #31 from paolo dot carlini at oracle dot com  2008-09-10 15:16 -------
*** Bug 37453 has been marked as a duplicate of this bug. ***


--

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lthode at mail dot unomaha
                   |                            |dot edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915

------- Comment #32 from lthode at mail dot unomaha dot edu  2008-09-12 10:36 -------
For all Gentoo users who are hitting this bug:

Update your GLibC to 2.7r2 or later, the new versions do not use multilib
wrappers any longer.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915