Emerge of cross-glibc for the requested platform fails. Reproducible: Always Steps to Reproduce: 1. crossdev -S -t sparc64-unknown-linux-gnu 2. 3. Actual Results: # crossdev -S -t sparc64-unknown-linux-gnu -------------------------------------------------------------------------------- * Host Portage ARCH: amd64 * Target Portage ARCH: sparc * Target System: sparc64-unknown-linux-gnu * Stage: 4 (C/C++ compiler) * binutils: binutils-[stable] * gcc: gcc-[stable] * headers: linux-headers-[stable] * libc: glibc-[stable] * PORTDIR_OVERLAY: /usr/local/portage * PORT_LOGDIR: /var/log/portage * PKGDIR: /usr/portage/packages/cross/sparc64-unknown-linux-gnu * PORTAGE_TMPDIR: /var/tmp/cross/sparc64-unknown-linux-gnu _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - * Forcing the latest versions of {binutils,gcc}-config/gnuconfig ... [ ok ] * Log: /var/log/portage/cross-sparc64-unknown-linux-gnu-binutils.log * Emerging cross-binutils ... [ ok ] * Log: /var/log/portage/cross-sparc64-unknown-linux-gnu-gcc-stage1.log * Emerging cross-gcc-stage1 ... [ ok ] * Log: /var/log/portage/cross-sparc64-unknown-linux-gnu-linux-headers.log * Emerging cross-linux-headers ... [ ok ] * Log: /var/log/portage/cross-sparc64-unknown-linux-gnu-glibc.log * Emerging cross-glibc ... * glibc failed :( * If you file a bug, please attach the following logfiles: * /var/log/portage/cross-sparc64-unknown-linux-gnu-info.log * /var/log/portage/cross-sparc64-unknown-linux-gnu-glibc.log
Created attachment 129607 [details] cross-sparc64-unknown-linux-gnu-info.log
Created attachment 129611 [details] cross-sparc64-unknown-linux-gnu-glibc.log gzip-ed
Created attachment 144764 [details] Emerge info
Created attachment 144765 [details] error message
Created attachment 144766 [details] rest of info
I have found a similar error while crossdeveloping for arm. I think it is related to this, that is why I do not generate a new bug. max joseba # crossdev --target arm-linux-gnu -------------------------------------------------------------------------------- * Host Portage ARCH: x86 * Target Portage ARCH: arm * Target System: arm-linux-gnu * Stage: 4 (C/C++ compiler) * binutils: binutils-[latest] * gcc: gcc-[latest] * headers: linux-headers-[latest] * libc: glibc-[latest] * PORTDIR_OVERLAY: /usr/local/portage * PORT_LOGDIR: /var/log/portage * PKGDIR: /usr/portage/packages/cross/arm-linux-gnu * PORTAGE_TMPDIR: /var/tmp/cross/arm-linux-gnu _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - * Forcing the latest versions of {binutils,gcc}-config/gnuconfig ... [ ok ] * Log: /var/log/portage/cross-arm-linux-gnu-binutils.log * Emerging cross-binutils ... [ ok ] * Log: /var/log/portage/cross-arm-linux-gnu-gcc-stage1.log * Emerging cross-gcc-stage1 ... [ ok ] * Log: /var/log/portage/cross-arm-linux-gnu-linux-headers.log * Emerging cross-linux-headers ... [ ok ] * Log: /var/log/portage/cross-arm-linux-gnu-glibc.log * Emerging cross-glibc ... [ ok ] * Log: /var/log/portage/cross-arm-linux-gnu-gcc-stage2.log * Emerging cross-gcc-stage2 ... * gcc failed :( * If you file a bug, please attach the following logfiles: * /var/log/portage/cross-arm-linux-gnu-info.log * /var/log/portage/cross-arm-linux-gnu-gcc-stage2.log
Created attachment 145802 [details] cross-arm-linux-gnu-info.log Related to comment #6
Created attachment 145804 [details] cross-arm-linux-gnu-gcc-stage2.log Related to comment #6
Comment on attachment 145802 [details] cross-arm-linux-gnu-info.log this bug is about sparc64/glibc ... glibc built for you for arm, so your issue is most def different
I can confirm this bug. The sparc64 gcc compiler is not compiled with "__thread support". I've tested the gcc manually if it has __thread support and it doesn't seem to have it. There is also a thread about this in the forum: http://forums.gentoo.org/viewtopic-t-682190.html
The problem seems to be the want_tls() function in $PORTDIR/sys-libs/glibc/files/eblits/common.eblit want_tls() { # Archs that can use TLS (Thread Local Storage) case $(tc-arch) in sparc) # 2.3.6 should have tls support on sparc64 # when using newer binutils case ${CTARGET/-*} in sparc64*) return 1 ;; *) return 0 ;; esac ;; x86) # requires i486 or better #106556 [[ ${CTARGET} == i[4567]86* ]] && return 0 return 1 ;; esac return 0 } which, by returning 1 for all sparc64 arch'es (not supported), bypasses the real test for __thread, wich will follow later on. At least for me with gcc-4.3.1 the __thread test passed (I also tried the test separately where it passed). By changing the returned result to 0 the compilation begins but later on dies with another error, configuring the glibc for sparcv9 system: * ABI: amd64 * CBUILD: x86_64-pc-linux-gnu * CHOST: x86_64-pc-linux-gnu * CTARGET: sparc64-unknown-linux-gnu * CBUILD_OPT: * CTARGET_OPT: sparcv9-unknown-linux-gnu * CC: sparc64-unknown-linux-gnu-gcc * CFLAGS: -pipe -fcall-used-g6 -O2 -fno-strict-aliasing * Configuring GLIBC for nptl with: --disable-stackguard-randomization --enable-old-ssp-compat --enable-omitfp --enable-add-ons=nptl,c_stubs,libidn,ports --enable-kernel=2.6.9 --without-selinux --without-cvs --enable-bind-now --build=x86_64-pc-linux-gnu --host=sparcv9-unknown-linux-gnu --disable-profile --with-gd --with-headers=/usr/sparc64-unknown-linux-gnu/usr/include --prefix=/usr --libdir=/usr/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --libexecdir=/usr/lib64/misc/glibc [...] running configure fragment for sysdeps/sparc/sparc32/elf checking for sparc32 TLS support... yes checking for sparc32 ld WDISP22 handling... ok running configure fragment for sysdeps/ieee754/ldbl-opt checking whether sparc64-unknown-linux-gnu-gcc -pipe -fcall-used-g6 -O2 -fno-strict-aliasing supports -mlong-double-128... no configure: error: this configuration requires -mlong-double-128 support * * ERROR: cross-sparc64-unknown-linux-gnu/glibc-2.8_p20080602 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 3511: Called eblit-run 'src_compile' * environment, line 1176: Called eblit-glibc-src_compile * src_compile.eblit, line 173: Called src_compile * environment, line 3511: Called eblit-run 'src_compile' * environment, line 1176: Called eblit-glibc-src_compile * src_compile.eblit, line 181: Called toolchain-glibc_src_compile * src_compile.eblit, line 120: Called glibc_do_configure 'nptl' * src_compile.eblit, line 97: Called die * The specific snippet of code: * "${S}"/configure ${myconf} || die "failed to configure glibc" * The die message: * failed to configure glibc * * 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/cross-sparc64-unknown-linux-gnu/glibc-2.8_p20080602/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/cross-sparc64-unknown-linux-gnu/glibc-2.8_p20080602/temp/environment'. * This ebuild is from an overlay: '/usr/local/portage/crossdev/' *
However when you disable the return 1s on SPARC(64) arch or CTARGET in the glibc common.eblit (lines 191 and 209) you run into bug 188729.
got the same with: crossdev --target i486-pc-linux-gnu * Log: /var/log/portage/cross-i486-pc-linux-gnu-glibc-headers.log * Emerging cross-glibc-headers ... * glibc failed :( * If you file a bug, please attach the following logfiles: * /var/log/portage/cross-i486-pc-linux-gnu-info.log * /var/log/portage/cross-i486-pc-linux-gnu-glibc-headers.log Solution: nano /usr/local/portage/cross-i486-pc-linux-gnu/glibc/files/eblits/src_unpack.eblit # ebegin "Checking gcc for __thread support" # if ! eend $(want__thread ; echo $?) ; then # echo # eerror "Could not find a gcc that supports the __thread directive!" # eerror "Please update your binutils/gcc and try again." # die "No __thread support in gcc!" # fi ebuild /usr/local/portage/cross-i486-pc-linux-gnu/glibc/glibc-.8_p20080602.ebuild digest crossdev --target i486-pc-linux-gnu now woks. After the glibc change the settings to normal: crossdev --clean i486-pc-linux-gnu change the glibc/files/eblits/src_unpack.eblit file + ebuild glibc-.8_p20080602.ebuild digest crossdev --target i486-pc-linux-gnu
there is too much unrelated noise here. the original bug was about glibc-2.5 and that is no longer supported, so punt this bug.
The bug is not fixed/outdated! If you try to cross compile from host amd64 for target sparc64 you still get exactly the same __thread errors with the following versions: cross-sparc64-unknown-linux-gnu/binutils-2.18-r3 cross-sparc64-unknown-linux-gnu/linux-headers-2.6.27-r2 cross-sparc64-unknown-linux-gnu/glibc-2.8_p20080602-r1 cross-sparc64-unknown-linux-gnu/gcc-4.3.2-r3
