This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/16371] gcc 3.4.1 fails to configure on amd64 with multilib enabled
- From: "mg_gentoo at yahoo dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 23 Jul 2004 03:29:40 -0000
- Subject: [Bug libstdc++/16371] gcc 3.4.1 fails to configure on amd64 with multilib enabled
- References: <20040705162800.16371.lv@gentoo.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From mg_gentoo at yahoo dot com 2004-07-23 03:29 -------
No, this is a bug in GLIBCXX_CHECK_COMPLEX_MATH_SUPPORT, it does not respect the
GCC_NO_EXECUTABLES at all. I ran into the problem building a cross compiler (on
gentoo/amd64, but it is not a gentoo-specific problem). When configuring in
libstdc++-v3, the host and target are i386-mingw32msvc and the build is
x86_64-pc-linux-gnu. Obviously we cant be testing executables on a foreign host.
I have worked around it by wrapping up the innards of
GLIBCXX_CHECK_COMPLEX_MATH_SUPPORT, but this is not a real fix. Real fix would
be to make it respect the xcompilation situation just like probably happens a
hundred other places in the build system. Have not tracked this fix down yet
myself though.
ccing Daniel, I think he might be able to help with fixing.
/me would reopen if could, but up to lv/unassigned
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |dan at debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371