Summary: | sys-devel/gcc-4.3.2-r3 fails to compile on sys-libs/uclibc | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dan <dsg102> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | embedded |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Fix for gcc 4.3.2 |
Description
Dan
2009-07-22 08:01:09 UTC
I've had the same experience as Dan. http://forums.gentoo.org/viewtopic-p-5192459.html#5192459 has a suggested work-around, but it is not exactly a desirable solution since it essentially disables c++. However, it does indeed allow you to build gcc. As for the bug: http://www.ib.cnea.gov.ar/~oop/biblio/libstdc++/c++locale_8h-source.html is an example of how the libstdc++-v3 version probably should look. Note the C99 check. Various other places mention that vsnprintf is not apart of c++'s std, as well... but I could not deduce the context of C99 vs non-C99. I am currently pursuing the use of the latest, but masked, uclibc-0.9.30.1-r1. I am upgrading GCC in accordance with the Gentoo GCC Upgrade Guide: http://www.gentoo.org/doc/en/gcc-upgrading.xml They have seemed to include fenv.h in the latest uclibc, but GCC-4.3.2-r3 still fails at bits/c++locale.h:111 as previously indicated by Dan. This is rather expected since it is libstdc++-v3 within the GCC source that is seemingly at fault. I am giving gcc-4.3.3-r2 a spin with uclibc-0.9.30.1-r1, and I will let you know how it goes. (In reply to comment #1) > I've had the same experience as Dan. > > http://forums.gentoo.org/viewtopic-p-5192459.html#5192459 has a suggested > work-around, but it is not exactly a desirable solution since it essentially > disables c++. However, it does indeed allow you to build gcc. > > As for the bug: > http://www.ib.cnea.gov.ar/~oop/biblio/libstdc++/c++locale_8h-source.html is an > example of how the libstdc++-v3 version probably should look. Note the C99 > check. Various other places mention that vsnprintf is not apart of c++'s std, > as well... but I could not deduce the context of C99 vs non-C99. > > I am currently pursuing the use of the latest, but masked, uclibc-0.9.30.1-r1. > > I am upgrading GCC in accordance with the Gentoo GCC Upgrade Guide: > http://www.gentoo.org/doc/en/gcc-upgrading.xml > > They have seemed to include fenv.h in the latest uclibc, but GCC-4.3.2-r3 still > fails at bits/c++locale.h:111 as previously indicated by Dan. This is rather > expected since it is libstdc++-v3 within the GCC source that is seemingly at > fault. > > I am giving gcc-4.3.3-r2 a spin with uclibc-0.9.30.1-r1, and I will let you > know how it goes. > Follow-up: gcc-4.3.3-r2 compiles fine with uclibc-0.9.30.1-r1. Seems like they have already resolved these issues, but both packages are technically masked at the moment. I am going to continue following the GCC Upgrade Guide, and then back to the TinyGentoo guide. Assuming that all goes well, I'd rather see this bug report turn in to a push to get gcc-4.3.3-r2 and uclibc-0.9.30.1-r1 unmasked and considered stable. Follow-up: gcc-4.3.3-r2 with uclibc-0.9.30.1-r1 didn't fare too well in the end. Too many issues with compiling other apps, albeit mostly related to gettext/iconv. I am trying out another guide. It is a spin-off of TinyGentoo, but it seems more modern/concise: http://www.anticore.org/ratgentoo/ If gcc-4.3.2* doesn't work well with the aforementioned guide, I'll be all too happy to mask it and work with 4.1* until all bugs are resolved. I had the same problem too. It seems like either setting UCLIBC_HAS_FENV in uclibc or using --disable-decimal-float with gcc is suposed to solve the problem (http://www.mail-archive.com/gcc@gcc.gnu.org/msg37094.html). The UCLIBC_HAS_FENV option is enabled in (unstable) sys-libs/uclibc-0.9.30* (see bug #278639 ) i havent tested it yet, but it might work. Good luck everyone Created attachment 205245 [details, diff]
Fix for gcc 4.3.2
I use uclibc-0.9.30. The problem occurs during compilation of g++. If I use "nocxx" flag gcc compiles fine. The problem is in 90_all_200-uclibc-locale.patch in gcc-4.1.2-uclibc-patches-1.0.tar.bz2. See necessary changes above. Denis It appeared that my patch didn't work, because I commented out "template <>" in ctype_members.cc. So the solution is to move ctype_by_name<char>::ctype_byname() constructor to libstdc++-v3/include/bits/locale_facets.h:1530, where ctype_byname<char> specialization is declared. (In reply to comment #4) > It seems like either setting UCLIBC_HAS_FENV in uclibc or using > --disable-decimal-float with gcc is suposed to solve the problem > (http://www.mail-archive.com/gcc@gcc.gnu.org/msg37094.html). I can confirm that sys-devel/gcc-4.3.4 compiles fine on sys-libs/uclibc-0.9.28.3-r8 with UCLIBC_HAS_FENV enabled. gcc-4.3.4 already compiled 70+ packages without any problem. So this is fixed for >=4.3.4? i just emerged 4.5.3 and didn't hit any troubles, so let's call it fixed |