When running emerge world on a new stage3-x86-uclibc-2008.0 install, gcc-4.3.2-r3 fails to build. I tried to work pass the problem described in bug 266298, which seems to work, however build fails later on as shown below. May be related to this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915 Reproducible: Always Steps to Reproduce: 1. extract new stage-3 tarball 2. configure chroot as at http://en.gentoo-wiki.com/wiki/Tiny_Gentoo 3. emerge portage 4. emerge world Actual Results: /var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/build/./gcc/xgcc -shared-libgcc -B/var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/build/./gcc -nostdinc++ -L/var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/build/i386-ge$ /var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/build/./gcc/xgcc -shared-libgcc -B/var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/build/./gcc -nostdinc++ -L/var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/build/i386-ge$ In file included from /var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/build/i386-gentoo-linux-uclibc/libstdc++-v3/include/bits/localefwd.h:47, from /var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/build/i386-gentoo-linux-uclibc/libstdc++-v3/include/string:50, from /var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/build/i386-gentoo-linux-uclibc/libstdc++-v3/include/bitset:54, from /var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/gcc-4.3.2/libstdc++-v3/include/precompiled/stdc++.h:67: /var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/build/i386-gentoo-linux-uclibc/libstdc++-v3/include/i386-gentoo-linux-uclibc/bits/c++locale.h: In function 'int std::__convert_from_v(int* const&, char*, int, cons$ /var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/build/i386-gentoo-linux-uclibc/libstdc++-v3/include/i386-gentoo-linux-uclibc/bits/c++locale.h:111: error: 'vsnprintf' is not a member of 'std' In file included from /var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/build/i386-gentoo-linux-uclibc/libstdc++-v3/include/bits/localefwd.h:47, from /var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/build/i386-gentoo-linux-uclibc/libstdc++-v3/include/string:50, from /var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/build/i386-gentoo-linux-uclibc/libstdc++-v3/include/bitset:54, from /var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/gcc-4.3.2/libstdc++-v3/include/precompiled/stdc++.h:67: /var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/build/i386-gentoo-linux-uclibc/libstdc++-v3/include/i386-gentoo-linux-uclibc/bits/c++locale.h: In function 'int std::__convert_from_v(int* const&, char*, int, cons$ /var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/build/i386-gentoo-linux-uclibc/libstdc++-v3/include/i386-gentoo-linux-uclibc/bits/c++locale.h:111: error: 'vsnprintf' is not a member of 'std' make[4]: *** [i386-gentoo-linux-uclibc/bits/stdc++.h.gch/O2g.gch] Error 1 make[4]: *** Waiting for unfinished jobs.... make[4]: *** [i386-gentoo-linux-uclibc/bits/stdc++.h.gch/O0g.gch] Error 1 make[4]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/build/i386-gentoo-linux-uclibc/libstdc++-v3/include' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/build/i386-gentoo-linux-uclibc/libstdc++-v3' make[2]: *** [all] Error 2 make[2]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/build/i386-gentoo-linux-uclibc/libstdc++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 make[1]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/build' make: *** [bootstrap-lean] Error 2 * * ERROR: sys-devel/gcc-4.3.2-r3 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 4803: Called toolchain_src_compile * environment, line 5329: Called gcc_src_compile * environment, line 3057: Called gcc_do_make * environment, line 2847: Called die * The specific snippet of code: * emake LDFLAGS="${LDFLAGS}" STAGE1_CFLAGS="${STAGE1_CFLAGS}" LIBPATH="${LIBPATH}" BOOT_CFLAGS="${BOOT_CFLAGS}" ${GCC_MAKE_TARGET} || die "emake failed with ${GCC_MAKE_TARGET}"; * The die message: * emake failed with bootstrap-lean * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/sys-devel/gcc-4.3.2-r3/temp/build.log'. Expected Results: gcc should compile cleanly emerge --info output: Portage 2.1.6.13 (uclibc/x86, gcc-4.1.2, uclibc-0.9.28.3-r2, 2.6.18-6-amd64 x86_64) ================================================================= System uname: Linux-2.6.18-6-amd64-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_4400+-with-libc0 Timestamp of tree: Tue, 21 Jul 2009 01:45:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p39 dev-lang/python: 2.4.4-r6, 2.5.4-r3 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.61-r1 sys-devel/automake: 1.10 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="x86" CBUILD="i386-gentoo-linux-uclibc" CFLAGS="-Os -mtune=i386 -pipe" CHOST="i386-gentoo-linux-uclibc" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-Os -mtune=i386 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig buildpkg ccache distlocks fixpackages nodoc noinfo noman parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_GB.UTF-8" LDFLAGS="-Wl,-O1" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages/uclibc" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="cli cracklib crypt dri midi minimal mudflap ncurses openmp pcre perl python readline reflection session spl ssl tcpd uclibc x86 xorg zlib" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="uclibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="dummy fbdev v4l" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
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
