emerge cross-armv5tel-softfloat-linux-gnueabi/glibc-2.11.2-r2 fails with: gcc-config: error: could not run/locate 'armv5tel-softfloat-linux-gnueabi-cpp' * Checking gcc for __thread support ... [ !! ] * Could not find a gcc that supports the __thread directive! * Please update your binutils/gcc and try again. * ERROR: cross-armv5tel-softfloat-linux-gnueabi/glibc-2.11.2-r2 failed: * No __thread support in gcc! Reproducible: Always Steps to Reproduce: 1.emerge cross-armv5tel-softfloat-linux-gnueabi/glibc-2.11.2-r2 Actual Results: * glibc-2.11.2.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * glibc-ports-2.11.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * glibc-2.11.2-patches-5.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * CPV: cross-armv5tel-softfloat-linux-gnueabi/glibc-2.11.2-r2 * REPO: * USE: amd64 elibc_glibc kernel_linux multilib nls userland_GNU >>> Unpacking source... gcc-config: error: could not run/locate 'armv5tel-softfloat-linux-gnueabi-cpp' * Checking gcc for __thread support ... [ !! ] * Could not find a gcc that supports the __thread directive! * Please update your binutils/gcc and try again. * ERROR: cross-armv5tel-softfloat-linux-gnueabi/glibc-2.11.2-r2 failed: * No __thread support in gcc! * * Call stack: * ebuild.sh, line 54: Called src_unpack * environment, line 3744: Called eblit-run 'src_unpack' * environment, line 1156: Called eblit-glibc-src_unpack * src_unpack.eblit, line 145: Called toolchain-glibc_src_unpack * src_unpack.eblit, line 78: Called check_nptl_support * src_unpack.eblit, line 38: Called die * The specific snippet of code: * die "No __thread support in gcc!" * * If you need support, post the output of 'emerge --info =cross-armv5tel-softfloat-linux-gnueabi/glibc-2.11.2-r2', * the complete build log and the output of 'emerge -pqv =cross-armv5tel-softfloat-linux-gnueabi/glibc-2.11.2-r2'. * This ebuild is from an overlay: '/usr/local/portage/' * The complete build log is located at '/var/tmp/portage/cross-armv5tel-softfloat-linux-gnueabi/glibc-2.11.2-r2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/cross-armv5tel-softfloat-linux-gnueabi/glibc-2.11.2-r2/temp/environment'. * S: '/var/tmp/portage/cross-armv5tel-softfloat-linux-gnueabi/glibc-2.11.2-r2/work/glibc-2.11.2' >>> Failed to emerge cross-armv5tel-softfloat-linux-gnueabi/glibc-2.11.2-r2, Log file: >>> '/var/tmp/portage/cross-armv5tel-softfloat-linux-gnueabi/glibc-2.11.2-r2/temp/build.log' * Messages for package cross-armv5tel-softfloat-linux-gnueabi/glibc-2.11.2-r2: * Could not find a gcc that supports the __thread directive! * Please update your binutils/gcc and try again. * ERROR: cross-armv5tel-softfloat-linux-gnueabi/glibc-2.11.2-r2 failed: * No __thread support in gcc! * * Call stack: * ebuild.sh, line 54: Called src_unpack * environment, line 3744: Called eblit-run 'src_unpack' * environment, line 1156: Called eblit-glibc-src_unpack * src_unpack.eblit, line 145: Called toolchain-glibc_src_unpack * src_unpack.eblit, line 78: Called check_nptl_support * src_unpack.eblit, line 38: Called die * The specific snippet of code: * die "No __thread support in gcc!" * * If you need support, post the output of 'emerge --info =cross-armv5tel-softfloat-linux-gnueabi/glibc-2.11.2-r2', * the complete build log and the output of 'emerge -pqv =cross-armv5tel-softfloat-linux-gnueabi/glibc-2.11.2-r2'. * This ebuild is from an overlay: '/usr/local/portage/' * The complete build log is located at '/var/tmp/portage/cross-armv5tel-softfloat-linux-gnueabi/glibc-2.11.2-r2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/cross-armv5tel-softfloat-linux-gnueabi/glibc-2.11.2-r2/temp/environment'. * S: '/var/tmp/portage/cross-armv5tel-softfloat-linux-gnueabi/glibc-2.11.2-r2/work/glibc-2.11.2' hermes ~ # Expected Results: successful build-install supporting files to follow.
Created attachment 252673 [details] build.log
Created attachment 252675 [details] environment
hermes ~ # emerge -pqv =cross-armv5tel-softfloat-linux-gnueabi/glibc-2.11.2-r2 [ebuild U ] cross-armv5tel-softfloat-linux-gnueabi/glibc-2.11.2-r2 [2.11.2-r1] USE="(multilib) nls -debug -gd -glibc-omitfp -hardened -profile (-selinux) -vanilla" hermes ~ #
Created attachment 252677 [details] emerge --info =cross-armv5tel-softfloat-linux-gnueabi/glibc-2.11.2-r2
This looks to be a problem with the gcc-config not finding/setting armv5tel-softfloat-linux-gnueabi-cpp. I don't know if that's a configuration error, or something really wrong one of the tools, so throwing it to the embedded group for further information.
so post the output of `gcc-config -l` and `armv5tel-softfloat-linux-gnueabi-cpp --version` ...
I apologize for not responding to the entry of 11/9; I was not at the machine at that time (I'm often away at work for 3 days at a time) and forgot to attend to the request when I returned home and was back on the box. I mindlessly went ahead a ran an "emerge --update --deep --newuse world " on the box and it pulled in glibc-2.11.2-r3 and I have the same problem. Should I add to this bug the "r3" files or close this bug and open a new bug to track the "r3" version? Here's the requested output: hermes mapserver-5.6.5 # gcc-config -l [1] armv5tel-softfloat-linux-gnueabi-4.5.1 [2] x86_64-pc-linux-gnu-4.4.5 * hermes mapserver-5.6.5 # armv5tel-softfloat-linux-gnueabi-cpp gcc-config: error: could not run/locate 'armv5tel-softfloat-linux-gnueabi-cpp' hermes mapserver-5.6.5 # Note: I had reinstalled distcc since the last update on this bug, too -- again forgetting that I had a bug pending on this box.
hermes / # armv5tel-softfloat-linux-gnueabi-cpp --version gcc-config: error: could not run/locate 'armv5tel-softfloat-linux-gnueabi-cpp' hermes / #
you need to `gcc-config 1` first and refresh your env
(In reply to comment #9) > you need to `gcc-config 1` first and refresh your env > Thank you, successfully emerged: cross-armv5tel-softfloat-linux-gnueabi/glibc. I am confused now about when to be in which configuration for gcc. I thought if I remained in the #2, x86_64-pc-linux-gnu-4.4.5 (the host's default configuration), I'd be okay for all "emerge --update --deep --newuse world ", but it appears I need to swith to the (or a) target configuration. Is there a best practices or guide that addresses the issue of when to be in your Host configuration as opposed to the Target configuration? I thought I had a handle on this and it's clear I've missed something important.
you may have one active gcc-config profile per CTARGET. there are no clashes across unique CTARGET values.
