--- Comment #36 from pinskia at gcc dot gnu dot org 2010-08-10 21:51
---
I am running into this also when doing a candian cross to mips64-linux-gnu. We
had locally reverted the patch for bug 3800 but I know that is wrong.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #35 from paolo dot carlini at oracle dot com 2010-08-02 06:53
---
Thanks a lot Armand (by the way, many thanks to Ralf too)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--- Comment #34 from armand dot potter at free dot fr 2010-08-01 17:21
---
Overall 3/ is not that good as in fact it will use directly system headers
without any wrapper (from in-tree or installed gcc).
I tried adding -nostdinc++ to PCHFLAGS and compilation runs OK (not that hard
cons
--- Comment #33 from paolo dot carlini at oracle dot com 2010-07-25 15:19
---
(In reply to comment #31)
> 1/ Use -nostdinc++ just as native compilers do. Like said in comment #28, it
> may break if used cross-compiler is incompatible with in-tree c++ headers (can
> gcc be built that way
--- Comment #32 from paolo dot carlini at oracle dot com 2010-07-21 22:03
---
Ralf, do you have any opinion on Comment #31? Maybe Armand can try to produce a
patch (or alternate patches) and post to the mailing lists in order to make
sure knowledgeable people actually have a chance to s
--- Comment #31 from armand dot potter at free dot fr 2010-07-21 21:35
---
I made some more investigations (a bit late as I am using now
--disable-libpchstdcxx like everyone else). IMHO three main options are
possible :
1/ Use -nostdinc++ just as native compilers do. Like said in comme
--- Comment #30 from armin76 at gentoo dot org 2010-06-19 11:31 ---
So...? :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--- Comment #29 from rwild at gcc dot gnu dot org 2010-05-16 17:32 ---
(In reply to comment #27)
> You mean the patch in Comment # 20? Because it seems an hack to me. Maybe Ralf
> is willing to explain why is the only possible fix.
Oh, I don't think it's the only possible fix, it's mere
--- Comment #28 from dougsemler at gmail dot com 2010-05-14 15:49 ---
I tried adding -nostdinc++ via --enable-cxx-flags configure option, but those
aren't passed through to the pch compilation...and I'm not sure that it's
appropriate to pass all the --enable-cxx-flags to the pch generati
--- Comment #27 from paolo dot carlini at oracle dot com 2010-05-14 15:11
---
You mean the patch in Comment # 20? Because it seems an hack to me. Maybe Ralf
is willing to explain why is the only possible fix. In the meanwhile just
disabling the generation of the PCHs works around the pr
--- Comment #26 from armin76 at gentoo dot org 2010-05-14 15:07 ---
Why hasn't that patch have been applied?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--- Comment #25 from hjl dot tools at gmail dot com 2010-01-10 17:15
---
(In reply to comment #24)
>
> Please show me how CLFS_CROSS_TOOLS gcc and binutils are configured.
>
Properly configured CLFS_CROSS_TOOLS gcc and binutils should
never use native header files/libraries even if t
--- Comment #24 from hjl dot tools at gmail dot com 2010-01-10 16:52
---
(In reply to comment #0)
> I'm using a gcc-4.4.1 cross-compiler to build another instance of gcc-4.4.1
> for
> the target system. make fails with the following error message:
>
>
> The configure command contain
--- Comment #23 from paolo dot carlini at oracle dot com 2010-01-10 12:17
---
I don't know what you mean exactly by "official", but certainly disabling the
build of the PCHs cannot hurt and cannot create any problem, beside the
testsuite running slower. Then, if you actually use PCHs in
--- Comment #22 from paolo dot carlini at oracle dot com 2010-01-10 12:16
---
I don't know what you mean exactly by "official", but certainly disabling the
build of the PCHs cannot hurt and cannot create any problem, beside the
testsuite running slower. Then, if you actually use PCHs in
--- Comment #21 from armand dot potter at free dot fr 2010-01-10 11:27
---
Build succeeds with the patch. Cannot test the just built compiler yet (have to
install the whole new system) but I will post the patch on clfs mailing list
for more testing (even if official instructions say to
--- Comment #20 from rwild at gcc dot gnu dot org 2009-12-22 21:04 ---
Created an attachment (id=19374)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19374&action=view)
patch to turn off multiple inclusion guard for fenv.h C++ wrapper
Comment #18 confirms #13.
It is probably suff
--- Comment #19 from paolo dot carlini at oracle dot com 2009-12-22 09:58
---
Ralf, is this information enough to debug the issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--- Comment #18 from armand dot potter at free dot fr 2009-12-19 15:44
---
Configure is as follow:
/tmp/gcc-4.4.2/configure --enable-shared --enable-clocale=gnu
--enable-__cxa_atexit --libexecdir=/usr/lib --enable-threads=posix
--enable-languages=c,c++ --build=i686-pc-linux-gnu --host=
--- Comment #17 from rwild at gcc dot gnu dot org 2009-12-16 21:51 ---
Armand, to expand on comment #13, could you post the exact command and error
message you're getting, as the original poster did?
Both of you, could you cd to the directory where the failure occurs, remove the
-o ARG
--- Comment #16 from paolo dot carlini at oracle dot com 2009-12-16 19:15
---
Well, for sure the testsuite runs much faster. Anyway, if we can't really
figure out a proper fix, maybe we can disable PCHs when we are building
cross-compilers.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #15 from bonzini at gnu dot org 2009-12-16 17:30 ---
Well, the solution could be disable PCH by default. :-) Is anybody using
it?...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--- Comment #14 from paolo dot carlini at oracle dot com 2009-12-16 16:17
---
Paolo, Ralf, I'd like to resolve this one for 4.5.0. Any idea?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--- Comment #13 from armand dot potter at free dot fr 2009-12-15 20:48
---
I'm using about the same configuration (cross-LFS build but with gcc 4.4.2) and
got the same error. I did some investigations and the problem is that fenv.h
file from build tree is first included (and defines _GL
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-09-26 19:44
---
fenv.h should come from glibc ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--- Comment #11 from booleandomain at gmail dot com 2009-08-07 12:10
---
There is no gcc/fenv.h in the build directory. I attached the only fenv.h files
I could find in it. I attached the script I use for building the
cross-toolchain, too. I slightly modified the build process: I remove
--- Comment #10 from booleandomain at gmail dot com 2009-08-07 12:03
---
Created an attachment (id=18318)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18318&action=view)
build-stage1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--- Comment #9 from booleandomain at gmail dot com 2009-08-07 12:00 ---
Created an attachment (id=18317)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18317&action=view)
x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1/fenv.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=409
--- Comment #8 from booleandomain at gmail dot com 2009-08-07 11:58 ---
Created an attachment (id=18316)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18316&action=view)
x86_64-unknown-linux-gnu/libstdc++-v3/include/fenv.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--- Comment #7 from bonzini at gnu dot org 2009-08-07 10:45 ---
What's the content of gcc/fenv.h in the build directory? If I have to guess,
I'd suppose it's generated by fixincludes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--- Comment #6 from paolo dot carlini at oracle dot com 2009-08-07 10:12
---
Paolo, if you could help, it would be great. About the driver, really I have no
idea. And I have never seen that almost-empty generated fenv.h, if it's really
happening maybe the library-proper isn't at fault..
--- Comment #5 from bonzini at gnu dot org 2009-08-07 09:46 ---
No, the build system should support everything; not just host==target != build
which is not so uncommon -- for example this is how cygwin worked before it
could host GCC -- but even the admittedly crazy target==build != host
--- Comment #4 from paolo dot carlini at oracle dot com 2009-08-07 08:22
---
Nice that we have a workaround, still, the problem should not happen anyway: in
normal builds on x86_64-linux, no fenv.h is generated during the build and the
one provided by the underlying libc is of course fi
--- Comment #3 from booleandomain at gmail dot com 2009-08-06 20:20 ---
I added the --disable-libstdcxx-pch option to the configure command for the
target gcc compiler, and now make works. Now I'm no longer sure if this is a
bug or my fault...
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #2 from booleandomain at gmail dot com 2009-08-06 19:21 ---
My goal is to build a GNU/Linux system similar to CLFS (cross-lfs.org), where
the host and the target are the same physical machine.
I'm not an expert, but anyway it seems that the C++ cross-compiler is trying to
bu
--- Comment #1 from paolo dot carlini at oracle dot com 2009-08-05 22:26
---
You should try to figure out the reason of those errors: whether, for some
reason, _GLIBCXX_HAVE_FENV_H is undefined, thus is not included in
tr1/cfenv. Or, the configure test for the facilities in (generated
36 matches
Mail list logo
