--- 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
--- 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
--- 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
--- 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
--- 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 #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=14039action=view) [edit]
Prevent fixincludes false positive on gentoo stdio.h wrapper
Very many
--- 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=14039action=view)
Prevent fixincludes false positive on gentoo stdio.h wrapper
The fixincludes script is hitting a false
--- 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
--- 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
--- Comment #17 from b33fc0d3 at gmail dot com 2007-03-12 20:48 ---
I can confirm this patch works on an amd64 gentoo sytem too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
--- Comment #18 from pcarlini at suse dot de 2007-03-12 21:08 ---
(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
--- 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
--- 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
--- 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...
--
--- 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
--- Comment #4 from martin dot jansa at mk dot cvut dot cz 2007-03-11
12:20 ---
(In reply to comment #3)
Well Ahmed, right now you can't possibly see the exact same error, because
stl_algobase.h does *not* include iosfwd anymore... Please provide more
info.
Thanks.
My error seems
--- Comment #5 from martin dot jansa at mk dot cvut dot cz 2007-03-11
12:29 ---
(In reply to comment #4)
And my toolchain:
jama gcc # /lib/libc.so.6
GNU C Library 20070214 release version 2.5.90, by Roland McGrath et al.
Copyright (C) 2007 Free Software Foundation, Inc.
This is free
--- Comment #6 from pcarlini at suse dot de 2007-03-11 12:32 ---
My error seems quite similar (with profiledbootstrap and bootstrap too). Older
snapshots have the same issue.
Thanks, but *how much* older, exactly, we must pin-point the exact source of
this problem.
I'm using latest
--- Comment #7 from pcarlini at suse dot de 2007-03-11 12:53 ---
People encountering this kind of problem should check whether this trivial C++
snippet compiles:
/
#include stdio.h
#undef clearerr
namespace my
{
using ::clearerr;
}
/
because really, in that place
--- Comment #8 from pcarlini at suse dot de 2007-03-11 13:03 ---
Then this snippet could be also useful, just in case we are doing something
wrong in the configury (I doubt it)
//
#include stdio.h
#include bits/c++config.h
#undef clearerr
_GLIBCXX_BEGIN_NAMESPACE(std)
--- Comment #9 from pcarlini at suse dot de 2007-03-11 13:05 ---
Oh well, if the build really failed bits/c++config.h has not been installed,
then include it from the exact place where is available in the build dir.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
--- Comment #10 from pcarlini at suse dot de 2007-03-11 13:14 ---
In c++config we have the below lines, which I never noriced before, I wonder
whether can cause problems given the our current framework (in the future is
another matter...)
Note hovewer, that currently __cplusplus in the
--- Comment #11 from pcarlini at suse dot de 2007-03-11 13:26 ---
(In reply to comment #10)
Note hovewer, that currently __cplusplus in the official GNU tree at least is
still *1*. Is it possible that only *Gentoo* GCC has an external patch
defining __cplusplus as 199711L???
But
--- Comment #12 from martin dot jansa at mk dot cvut dot cz 2007-03-11
13:36 ---
(In reply to comment #11)
Those 2 snippets working fine here and printf(%d,__cplusplus); says still
1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
--- Comment #13 from pcarlini at suse dot de 2007-03-11 13:46 ---
Ok, can we know when exactly this bootstrap problem appeared? Nobody among the
developers is seeing it, I repeat, we can't reproduce it, and if the submitters
are not going to help more, much more, the problem cannot be
--- Comment #14 from martin dot jansa at mk dot cvut dot cz 2007-03-11
13:54 ---
(In reply to comment #13)
Ok, can we know when exactly this bootstrap problem appeared? Nobody among the
developers is seeing it, I repeat, we can't reproduce it, and if the
submitters
are not going
--- Comment #15 from martin dot jansa at mk dot cvut dot cz 2007-03-11
20:35 ---
(In reply to comment #14)
downgrading glibc didn't that trick but now() I have successfully builded
latest snapshot with this patch:
--- ./gcc-4.3-20070309/libstdc++-v3/include/c_global/cstdio.orig
--- Comment #16 from pcarlini at suse dot de 2007-03-11 21:20 ---
I see, weird, I'm going to add Benjamin in CC, he added very recently the
c_global files and I'm not familiar with #include_next...
--
pcarlini at suse dot de changed:
What|Removed
--- Comment #3 from pcarlini at suse dot de 2007-03-07 19:05 ---
Well Ahmed, right now you can't possibly see the exact same error, because
stl_algobase.h does *not* include iosfwd anymore... Please provide more info.
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
--- Comment #2 from b33fc0d3 at gmail dot com 2007-03-07 03:37 ---
I am having the exact same problem.
I've tried a few things, tried building in a stable chroot with glibc-2.4
(since my box is mainly unstable with glibc-2.5 and hashstyle) but got the
exact same error. gcc-4.2
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|bootstrap |libstdc++
--- Comment #1 from pcarlini at suse dot de 2007-02-23 01:59 ---
Frankly, I have no idea what to do with this... Certainly lately we have got
plenty of succesful builds on x86_64-linux and other linux platforms (just look
to testresults). Something mysterious is going on during the
33 matches
Mail list logo
