View previous topic :: View next topic |
Author |
Message |
pappy_mcfae Watchman
Joined: 27 Dec 2007 Posts: 5999 Location: Pomona, California.
|
Posted: Fri Jun 06, 2014 11:44 pm Post subject: No __thread support in gcc! <FIXED> |
|
|
I have a bit of a long-standing situation on my hands. Whenever I attempt to update i686-pc-linux-gnu/glibc, I run headlong into the following:
Code: | Calculating dependencies... done!
[ebuild U ] cross-i686-pc-linux-gnu/glibc-2.19:2.2::Local-Portage-Overlay [2.17:2.2::Local-Portage-Overlay] USE="-debug -gd -hardened -multilib -nscd -profile (-selinux) -suid -systemtap -vanilla" 0 kB
Total: 1 package (1 upgrade), Size of downloads: 0 kB
Would you like to merge these packages? [Yes/No]
>>> Verifying ebuild manifests
>>> Emerging (1 of 1) cross-i686-pc-linux-gnu/glibc-2.19::Local-Portage-Overlay
* glibc-2.19.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ]
* glibc-2.19-patches-1.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ...[ ok ]
>>> Unpacking source...
* 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-i686-pc-linux-gnu/glibc-2.19::Local-Portage-Overlay failed (unpack phase):
* No __thread support in gcc!
*
* Call stack:
* ebuild.sh, line 93: Called src_unpack
* environment, line 3061: Called eblit-run 'src_unpack'
* environment, line 838: Called eblit-glibc-src_unpack
* src_unpack.eblit, line 158: Called toolchain-glibc_src_unpack
* src_unpack.eblit, line 82: 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-i686-pc-linux-gnu/glibc-2.19::Local-Portage-Overlay'`,
* the complete build log and the output of `emerge -pqv '=cross-i686-pc-linux-gnu/glibc-2.19::Local-Portage-Overlay'`.
* The complete build log is located at '/var/tmp/portage/cross-i686-pc-linux-gnu/glibc-2.19/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/cross-i686-pc-linux-gnu/glibc-2.19/temp/environment'.
* Working directory: '/var/tmp/portage/cross-i686-pc-linux-gnu/glibc-2.19/work'
* S: '/var/tmp/portage/cross-i686-pc-linux-gnu/glibc-2.19/work/glibc-2.19'
>>> Failed to emerge cross-i686-pc-linux-gnu/glibc-2.19, Log file:
>>> '/var/tmp/portage/cross-i686-pc-linux-gnu/glibc-2.19/temp/build.log'
*
* The following package has failed to build or install:
*
* (cross-i686-pc-linux-gnu/glibc-2.19:2.2/2.2::Local-Portage-Overlay, ebuild scheduled for merge), Log file:
* '/var/tmp/portage/cross-i686-pc-linux-gnu/glibc-2.19/temp/build.log'
*
|
After looking at things and doing a bit of investigating, I can see the error is generated in /usr/portage/sys-libs/glibc/files/eblits/src_unpack.eblit. It is looking for something, and not quite finding it. My question is where and what is it looking for?
The code in the file listed above is as follows:
Code: | # Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/sys-libs/glibc/files/eblits/src_unpack.eblit,v 1.23 2013/06/29 03:22:32 heroxbd Exp $
int_to_KV() {
local version=$1 major minor micro
major=$((version / 65536))
minor=$(((version % 65536) / 256))
micro=$((version % 256))
echo ${major}.${minor}.${micro}
}
eend_KV() {
[[ $(KV_to_int $1) -ge $(KV_to_int $2) ]]
eend $?
}
get_kheader_version() {
printf '#include <linux/version.h>\nLINUX_VERSION_CODE\n' | \
$(tc-getCPP ${CTARGET}) -I "${EPREFIX}/$(alt_build_headers)" | \
tail -n 1
}
check_nptl_support() {
# don't care about the compiler here as we arent using it
just_headers && return
local run_kv build_kv want_kv
run_kv=$(int_to_KV $(get_KV))
build_kv=$(int_to_KV $(get_kheader_version))
want_kv=${NPTL_KERN_VER}
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
|
Both the native and the cross-dev versions of gcc are built with the nptl USE flag set to on. While I can almost understand what it is looking for, I would be lying if I said I had a clue. That is why I am asking the question.
I have googled, and while I have seen fleeting references, I have yet to see a concrete this is what I did in reference to the error or fixing it.
I am pretty sure it's file corruption, and since I have another 64-bit server that is not experiencing this issue, I should be able to fix this by just replacing the corrupted or missing file that is causing the issues.
So, if there's anyone out there who can give me a rough idea of where to look to find the answer, I'd be most appreciative.
Thanks in advance.
Cheers,
Pappy _________________ This space left intentionally blank, except for these ASCII symbols.
Last edited by pappy_mcfae on Tue Jun 24, 2014 7:42 am; edited 1 time in total |
|
Back to top |
|
|
pappy_mcfae Watchman
Joined: 27 Dec 2007 Posts: 5999 Location: Pomona, California.
|
Posted: Fri Jun 06, 2014 11:45 pm Post subject: |
|
|
emerge --info:
Code: | core-too ~ # emerge --info
Portage 2.2.10 (default/linux/amd64/13.0, gcc-4.7.3, glibc-2.19, 3.15.0-rc7 x86_64)
=================================================================
System uname: Linux-3.15.0-rc7-x86_64-Intel-R-_Core-TM-2_Duo_CPU_E6550_@_2.33GHz-with-gentoo-2.2
KiB Mem: 2562488 total, 767820 free
KiB Swap: 1951892 total, 1951716 free
Timestamp of tree: Fri, 06 Jun 2014 06:00:01 +0000
ld GNU ld (GNU Binutils) 2.24
distcc 3.1 x86_64-pc-linux-gnu [enabled]
app-shells/bash: 4.2_p47
dev-java/java-config: 2.2.0
dev-lang/python: 2.6.9, 2.7.6-r1, 3.1.5-r1, 3.2.5-r4, 3.3.5, 3.4.0
dev-util/cmake: 2.8.12.2-r1
dev-util/pkgconfig: 0.28-r1
sys-apps/baselayout: 2.2
sys-apps/openrc: 0.12.4
sys-apps/sandbox: 2.6-r1
sys-devel/autoconf: 2.13, 2.69
sys-devel/automake: 1.4_p6, 1.5, 1.6.3-r1, 1.7.9-r1, 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.6, 1.12.6, 1.13.4, 1.14.1
sys-devel/binutils: 2.24-r3
sys-devel/gcc: 4.7.3::Local-Portage-Overlay
sys-devel/gcc-config: 1.8
sys-devel/libtool: 2.4.2-r1
sys-devel/make: 4.0-r1
sys-kernel/linux-headers: 3.14 (virtual/os-headers)
sys-libs/glibc: 2.19
Repositories: gentoo Local-Portage-Overlay
Installed sets: @system
ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="* -@EULA dlj-1.1 googleearth AdobeFlash-11.x Oracle-BCLA-JavaSE"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=core2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/polkit-1/actions"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.5/ext-active/ /etc/php/cgi-php5.5/ext-active/ /etc/php/cli-php5.5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -march=core2 -pipe"
DISTDIR="/mnt/seeds/64-too/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--autounmask=n --quiet-build=n"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distcc distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LANG="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j4"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://192.168.0.105/gentoo-portage"
USE="X a52 aac acpi ads alsa amd64 apache2 apng audiofile avi bash-completion berkdb bitmap-fonts bzip2 cairo cdr clang cli consolekit cracklib crypt css ctype cups cxx dbus dlloader dri drm dvd dvdr dvdread emboss encode fam ffmpeg fftw filter flac fontconfig foomaticdb fortran gdbm gif glib gnutls gpm gsl gtk gudev hwdb iconv icu jpeg kde kdenlive kdgraphics ladspa lame ldap libkms libsamplerate libwww live lm_sensors mad mikmod mmx mng modules mp3 mp4 mpeg multilib mysql nas ncurses nls nptl nptlonly objc ogg opengl openmp openvg pam pcre pdcre pdf pdflib perl php plasma png ppds python qt3 qt3support qt4 quicktime readline reflection samba script sdl semantic-desktop session slang slp smp sndfile spell spl sql sqlite sse sse2 ssl ssse3 startup-notification svg swat tcpd theora thunar tiff truetype udev udisks unicode upcall v4l v4l2 vhosts vorbis winbind wxwindows x264 xml xmp xorg xscreensaver xv xvid zlib" ABI_X86="64" ALSA_CARDS="intel-hda" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd 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 dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status thunar unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_1 python3_2" RUBY_TARGETS="ruby20" USERLAND="GNU" VIDEO_CARDS="nouveau" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset: CPPFLAGS, CTARGET, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
|
_________________ This space left intentionally blank, except for these ASCII symbols. |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21518
|
Posted: Sat Jun 07, 2014 3:57 am Post subject: |
|
|
You receive a failure if the shell function want__thread returns failure. It is defined in /usr/portage/sys-libs/glibc/files/eblits/common.eblit. Your CHOST would not cause want_tls to return failure, so either you have $WANT__THREAD defined to non-zero or running tc-has-tls -c fails. |
|
Back to top |
|
|
xaviermiller Bodhisattva
Joined: 23 Jul 2004 Posts: 8706 Location: ~Brussels - Belgique
|
Posted: Sat Jun 07, 2014 8:06 am Post subject: |
|
|
Hi Pappy,
I have that sometimes when distcc is activated. I try again and sometimes it works. My workaround is to temporary disable distcc with FEATURES="-distcc" for that package.
Distcc seems really unstable those last months, but we cannot live without it... _________________ Kind regards,
Xavier Miller |
|
Back to top |
|
|
krinn Watchman
Joined: 02 May 2003 Posts: 7470
|
Posted: Sat Jun 07, 2014 8:01 pm Post subject: |
|
|
It's because your distcc hosts are not in sync.
building host and helpers MUST share gcc and glibc version.
it's easy to see a host with glibc-2.17 trying to upgrade to 2.19 using another host that already have 2.19 install.
DO NOT DESYNC your toolchain to use distcc. Even if you are not cross compiling. People just care to keep gcc high version (4.7.1 and 4.7.3) but i just recommand to also not do that and keep versions equal.
Upgrade toolchain should not be made with distcc ; use binhost for that. |
|
Back to top |
|
|
pappy_mcfae Watchman
Joined: 27 Dec 2007 Posts: 5999 Location: Pomona, California.
|
Posted: Sun Jun 08, 2014 9:15 am Post subject: |
|
|
It is not a distcc issue. Adding FEATURES='-distcc' didn't do anything.
To reiterate, this happens during source unpack; long before compilation even begins. Please refer to the snippet of code from the .eblit file listed above, and please tell me what is being looked for, and where it's being looked for. I have considered editing the eblit to remove that function, but I think it would work better if I fixed the file that isn't being found, or the reference in that file that isn't being found. That would seem to go a long way in actually fixing the issue.
Cheers,
Pappy. _________________ This space left intentionally blank, except for these ASCII symbols. |
|
Back to top |
|
|
krinn Watchman
Joined: 02 May 2003 Posts: 7470
|
Posted: Sun Jun 08, 2014 10:25 am Post subject: |
|
|
both infos for glibc and gcc threads support can be seen with gcc -v and /lib/libc.so.6 |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21518
|
Posted: Sun Jun 08, 2014 4:11 pm Post subject: |
|
|
pappy_mcfae wrote: | To reiterate, this happens during source unpack; long before compilation even begins. Please refer to the snippet of code from the .eblit file listed above, and please tell me what is being looked for, and where it's being looked for. | Before entering this thread, I had never looked at how this works. I am reasoning this out as I go.
Compilation of files can happen at any phase where someone invokes the compiler. In this case, a test program is being compiled during src_unpack. This is probably done so that a failure can be reported immediately, rather than unpacking glibc and then discovering you will not be able to build it. The function I mentioned previously, tc-has-tls, is in /usr/portage/eclass/toolchain-funcs.eclass. It works as you might expect from its name and location. It compiles a test program to test if your toolchain has working thread local storage. You can run the same test by hand. Create a C source file as below, which is taken from tc-has-tls. Compile it with gcc -c file.c. If the compilation does not succeed, then the failure is consistent between your user and the Portage user. file.c: | int foo(int *i) {
static __thread int j = 0;
return *i ? j : *i;
}
|
|
|
Back to top |
|
|
pappy_mcfae Watchman
Joined: 27 Dec 2007 Posts: 5999 Location: Pomona, California.
|
Posted: Mon Jun 09, 2014 5:06 pm Post subject: |
|
|
It compiles without issue. I used the system gcc.
Cheers,
Pappy _________________ This space left intentionally blank, except for these ASCII symbols. |
|
Back to top |
|
|
pappy_mcfae Watchman
Joined: 27 Dec 2007 Posts: 5999 Location: Pomona, California.
|
Posted: Mon Jun 09, 2014 5:38 pm Post subject: |
|
|
For grins I also attempted Code: | i686-pc-linux-gnu-gcc -c file.c | and Code: | x86_64-pc-linux-gnu-gcc -c file.c | just in case there was some weird link issue or some other out-there thing that might come up in the course of using Linux over a long period of time. Both compilers worked fine, as far as I can tell. They made an object file, and didn't give errors in the process.
:scratching head:
EDIT: Just in case I wasn't clear, sys-libs/glibc compiles perfectly. It always has. /EDIT
Cheers,
Pappy _________________ This space left intentionally blank, except for these ASCII symbols. |
|
Back to top |
|
|
pappy_mcfae Watchman
Joined: 27 Dec 2007 Posts: 5999 Location: Pomona, California.
|
Posted: Mon Jun 09, 2014 6:00 pm Post subject: |
|
|
krinn wrote: | both infos for glibc and gcc threads support can be seen with gcc -v and /lib/libc.so.6 |
System gcc (x86_64):
Code: | x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.3/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.3/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.7.3/work/gcc-4.7.3/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.3 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.3/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include/g++-v4 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.7.3/python --enable-languages=c,c++,objc,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.7.3 p1.2, pie-0.5.5' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --enable-lto --without-cloog --without-ppl
Thread model: posix
gcc version 4.7.3 (Gentoo 4.7.3 p1.2, pie-0.5.5)
|
cross-compiler (x86):
Code: | i686-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/gcc-bin/4.7.3/i686-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.7.3/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/cross-i686-pc-linux-gnu/gcc-4.7.3/work/gcc-4.7.3/configure --host=x86_64-pc-linux-gnu --target=i686-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/gcc-bin/4.7.3 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.3/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.3 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.3/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.3/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.3/include/g++-v4 --with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.7.3/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.7.3 p1.2, pie-0.5.5' --enable-libstdcxx-time --enable-poison-system-directories --with-sysroot=/usr/i686-pc-linux-gnu --disable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-altivec --disable-fixed-point --with-arch=i686 --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --enable-lto --without-cloog --without-ppl
Thread model: posix
gcc version 4.7.3 (Gentoo 4.7.3 p1.2, pie-0.5.5)
|
Cheers,
Pappy _________________ This space left intentionally blank, except for these ASCII symbols. |
|
Back to top |
|
|
Navar Guru
Joined: 20 Aug 2012 Posts: 353
|
Posted: Tue Jun 10, 2014 2:19 am Post subject: |
|
|
Hi Pappy,
I'm just going to go off the presumption everyone knows what they're talking about here regarding TLS being the issue and follow from that. My bash knowledge also tends to be in the recall one day, forget the next (same for x other scripting language differences). With that in mind:
My /usr/local/portage/cross-i686-pc-linux-gnu/ are just links here back to respective tree packages in /usr/portage. This will be one of my questions later...
I'm not keyworded ~ in this case, but two things stand out to me:
pappy_mcfae wrote: | gcc version 4.7.3 (Gentoo 4.7.3 p1.2, pie-0.5.5) |
Quote: | i686-pc-linux-gnu-gcc -v
[...]
gcc version 4.7.3 (Gentoo 4.7.3-r1 p1.4, pie-0.5.5)
|
(same for x86_64-pc-linux-gnu-gcc -v of course)
I feel like I'm missing information.
pappy_mcfae wrote: | * Could not find a gcc that supports the __thread directive!
* Please update your binutils/gcc and try again. |
pappy_mcfae wrote: | sys-devel/gcc: 4.7.3::Local-Portage-Overlay | ?
Mine is Quote: | sys-devel/gcc: 4.7.3-r1 |
For the copied eclass test, try also the -S flag (compiler) instead of -c (assembler). Or go for broke and run them all including C library:
Quote: | (i686|x86_64)-pc-linux-gnu-gcc -S file.c
(i686|x86_64)-pc-linux-gnu-gcc -fPIC -shared -Wl,-z,defs file.c
|
Those four ran fine for me. My gut feeling is to follow the error message above and update your gcc (/binutils). |
|
Back to top |
|
|
pappy_mcfae Watchman
Joined: 27 Dec 2007 Posts: 5999 Location: Pomona, California.
|
Posted: Tue Jun 10, 2014 8:50 pm Post subject: |
|
|
It only happens on the one machine. The other 64 bit server is not having any issues in the least. As far as recompiling gcc, libtool, and binutils, I don't think recompiling them again is going to fix them anymore than recompiling them has fixed them the last few times I've tried. 'Twere it to be that easy.
EDIT: Attempting all the listed variations on compilation produced no errors, and file.o, as one would expect. /EDIT
Cheers,
Pappy _________________ This space left intentionally blank, except for these ASCII symbols. |
|
Back to top |
|
|
Navar Guru
Joined: 20 Aug 2012 Posts: 353
|
Posted: Tue Jun 10, 2014 11:47 pm Post subject: |
|
|
Didn't mean re-compiling your existing gcc overlay, but in the case of file corruption as being the actual cause, sure. I was hoping for an explanation of the use with 4.7.3 which is a year old and removed from the tree last fall.
I meant what was suggested in the error. Consider updating gcc to sys-devel/gcc-4.7.3-r1::gentoo. |
|
Back to top |
|
|
pappy_mcfae Watchman
Joined: 27 Dec 2007 Posts: 5999 Location: Pomona, California.
|
Posted: Wed Jun 11, 2014 3:01 am Post subject: |
|
|
The age of the compiler has nothing to do with this error. If it did, then it would show up on my other machine. As far as not updating the compiler, I only do that when there's a pressing reason, not just to say I have the latest gcc version on my machine. I last updated gcc when a package complained that it wouldn't compile on anything less. I don't recall the package, but I do recall the update.
Cheers,
Pappy _________________ This space left intentionally blank, except for these ASCII symbols. |
|
Back to top |
|
|
pappy_mcfae Watchman
Joined: 27 Dec 2007 Posts: 5999 Location: Pomona, California.
|
Posted: Wed Jun 11, 2014 4:16 am Post subject: |
|
|
So, I grabbed the binary x86_64 gcc-4.7.3-r1, and installed it manually. The error stays. I am currently recompiling the compiler...again. I need to go back to the version I was using, since it is clearly not the issue at present. I did clean out some old gcc files in /usr/bin, but that didn't help, either.
This is really beginning to get on my nerves. I may have to nuke this bad boy, and start over with a fresh funtoo install if this error doesn't resolve soon. I'm better off starting from scratch than sizzling my neurons trying to figure this thing out.
Cheers,
Pappy _________________ This space left intentionally blank, except for these ASCII symbols. |
|
Back to top |
|
|
krinn Watchman
Joined: 02 May 2003 Posts: 7470
|
Posted: Wed Jun 11, 2014 4:40 am Post subject: |
|
|
pappy_mcfae wrote: |
System gcc (x86_64):
x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.3/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.3/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.7.3/work/gcc-4.7.3/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.3 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.3/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include/g++-v4 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.7.3/python --enable-languages=c,c++,objc,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.7.3 p1.2, pie-0.5.5' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --enable-lto --without-cloog --without-ppl
Thread model: posix
gcc version 4.7.3 (Gentoo 4.7.3 p1.2, pie-0.5.5)
cross-compiler (x86):
i686-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/gcc-bin/4.7.3/i686-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.7.3/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/cross-i686-pc-linux-gnu/gcc-4.7.3/work/gcc-4.7.3/configure --host=x86_64-pc-linux-gnu --target=i686-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/gcc-bin/4.7.3 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.3/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.3 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.3/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.3/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.3/include/g++-v4 --with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.7.3/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.7.3 p1.2, pie-0.5.5' --enable-libstdcxx-time --enable-poison-system-directories --with-sysroot=/usr/i686-pc-linux-gnu --disable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-altivec --disable-fixed-point --with-arch=i686 --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --enable-lto --without-cloog --without-ppl
Thread model: posix
gcc version 4.7.3 (Gentoo 4.7.3 p1.2, pie-0.5.5)
Cheers,
Pappy |
Look at red part, cross compiler miss it. |
|
Back to top |
|
|
pappy_mcfae Watchman
Joined: 27 Dec 2007 Posts: 5999 Location: Pomona, California.
|
Posted: Wed Jun 11, 2014 4:56 am Post subject: |
|
|
So does the cross-compiler for the other machine.
Cheers,
Pappy _________________ This space left intentionally blank, except for these ASCII symbols. |
|
Back to top |
|
|
pappy_mcfae Watchman
Joined: 27 Dec 2007 Posts: 5999 Location: Pomona, California.
|
Posted: Wed Jun 18, 2014 8:59 pm Post subject: |
|
|
I have to bump this. I am also a bit bummed because I've tried a few things, like moving the i686 compiler setup from the machine that works to the one that has issues, as well as binutils.
Is there anyone who can help by maybe suggesting a place to take a crash-course in whatever language makes this tick (python?) so that I might be able to find out what this script is looking for, where its trying to find it, and why it's so much different between sys-libs/glibc, and cross-i686-pc-linux-gnu/glibc. As far as I can tell, there should be no difference, but once again, this is next to impossible for me to understand without someone who at least has an idea of what variables are being requested from where.
On the good side of things for this machine, I finally got nvidia-drivers to set itself for the proper resolution of the monitor I have it attached to. It took some looking, but someone in Ubuntuland was having similar issues (1024x768 on a 1280x1024) had some additions to his /etc/X11/xorg.conf file that made it call up the right EDID profile. I modified my file, and I now have full resolution. Nice!
Still, I'd like to move beyond this annoyance and on to the next long-term bug waiting to take up residence in my machines.
Cheers,
Pappy _________________ This space left intentionally blank, except for these ASCII symbols. |
|
Back to top |
|
|
Navar Guru
Joined: 20 Aug 2012 Posts: 353
|
Posted: Thu Jun 19, 2014 1:22 am Post subject: |
|
|
You disagree with the error messages, fine. You disagree with those who tried to assist you here, that's fine too.
Re-examine your complete setups for cross on machine A vs B, be it local overlay differences, respective links and so on. Whatever it is you have differently that you remain steadfast functions perfect for the one. If that is the case, the answer should be there.
Or...
pappy_mcfae wrote: | Is there anyone who can help by maybe suggesting a place to take a crash-course in whatever language makes this tick [...] |
man bash. Also Ebuild writing.
pappy_mcfae wrote: | As far as I can tell, there should be no difference, but once again, this is next to impossible for me to understand without someone who at least has an idea of what variables are being requested from where. |
Then post a bug report and let the experts respond while you explain the differences between your setups because I'm sure they'll want more info regarding: ~ keyworded toolchain items coupled with an overlay copy of older gcc, etc. We are left to further guess your details.
I suspect you will be told similiar as you were here. If it's a packaged controlled file, then re-emerging should have overwrote to resolve (w.r.t. related file corruption). If it's a user generated file issue...
As I said prior, I believe the bash crossdev script establishes links in your local overlay (if present) which should just point back to the respective tree locations (set_links() in /usr/bin/crossdev), e.g.:
Code: |
ls -al /usr/local/portage/cross-i686-pc-linux-gnu/
total 8
drwxr-xr-x 2 root root 4096 Mar 29 2013 .
drwxr-xr-x 11 portage portage 4096 Apr 27 13:31 ..
lrwxrwxrwx 1 root root 31 Mar 29 2013 binutils -> /usr/portage/sys-devel/binutils
lrwxrwxrwx 1 root root 26 Mar 29 2013 gcc -> /usr/portage/sys-devel/gcc
lrwxrwxrwx 1 root root 26 Mar 29 2013 gdb -> /usr/portage/sys-devel/gdb
lrwxrwxrwx 1 root root 27 Mar 29 2013 glibc -> /usr/portage/sys-libs/glibc
lrwxrwxrwx 1 root root 37 Mar 29 2013 linux-headers -> /usr/portage/sys-kernel/linux-headers
|
I'm left with the impression yours does not look like this, at least for gcc if not more. See my prior post and the first post from Hu. You're failing the conditional in check_nptl_support():
Code: |
if ! eend $(want__thread ; echo $?) ; then
|
want__thread() {} is in /usr/portage/sys-libs/glibc/files/eblits/common.eblit. Which leads you back to another post by Hu regarding the tc-has-tls function used. |
|
Back to top |
|
|
pappy_mcfae Watchman
Joined: 27 Dec 2007 Posts: 5999 Location: Pomona, California.
|
Posted: Thu Jun 19, 2014 7:42 am Post subject: |
|
|
1. I am asking a question on how to fix my machine. I am not asking for a personal inventory.
2. I don't know what your attitude is about, but whatever. In the future, you might want to keep that to yourself. Just a suggestion.
3. I have provided all requested information and then some. Due diligence is NOT the problem here.
If you desire to help, fine. That is what I am asking for. I am trying what I can as time allows. I have not given up on this issue, which is why I bumped.
If you're going to criticize me and my machinery, please step aside so that someone who doesn't seem to be interested in adding a bit of condescension and surliness can perhaps lead me down a path I haven't trodden a dozen or more times since this issue started. I don't have time to read personal criticisms while asking for help. If I wanted that sort of lame-brained nonsense, I'd have posted my request on Facebook instead.
Cheers,
Pappy _________________ This space left intentionally blank, except for these ASCII symbols. |
|
Back to top |
|
|
lagalopex Guru
Joined: 16 Oct 2004 Posts: 562
|
Posted: Thu Jun 19, 2014 9:38 am Post subject: |
|
|
You could modify /usr/portage/eclass/toolchain-funcs.eclass to not discard the output of the compilation in tc-has-tls().
If its fine add "debug" messages to want__thread() in /usr/portage/sys-libs/glibc/files/eblits/common.eblit to see where it fails. |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Thu Jun 19, 2014 2:13 pm Post subject: |
|
|
If you want a quick hack, you should be able to add: WANT__THREAD=0 to package.env, by adding:
Code: | cross-i686-pc-linux-gnu/glibc cross-x86.conf |
to /etc/portage/package.env/cross-i686-pc-linux-gnu and dropping cross-x86.conf (or some other filename) into /etc/portage/env with your settings. Of course, you can test that with: WANT__THREAD=0 cross-emerge .. It's zero as Hu mentioned, since it's a shell return status, and 0 is true in shell.
However I don't think that will help much (though it might get you further in the process, ie a failure from autoconf, instead of from ebuild), as the disparity krinn pointed out appears to be the root cause.
Something that occurred to me is if you're running multilib then the wrong compiler might be chosen, though I don't understand why you need a cross-compiler. You mentioned using the system compiler for the test program, but that doesn't sound right either.
Sorry if I'm not being much help: you said your other cross-compiler has the same difference, which I found puzzling, unless the multilib mess means that your system compiler is in fact being used. So I'd be looking to find out why that's being built without threads; it may just be you need another ac_cv_* (or gcc_cv_*) added to one of the linux files in crossdev.
You can sort that once you know what's happening with the gcc build (which thinks its output-target doesn't support pthreads) and know what variable it sets, based on the test it's not running when building a cross-compiler. ##workingset on IRC:chat.freenode.net can help you with that. Then add the variable to the package.env or the local crossdev site file (and file a bug.)
As I said though, I thought you could use the amd64 system compiler to cross-compile to x86. |
|
Back to top |
|
|
pappy_mcfae Watchman
Joined: 27 Dec 2007 Posts: 5999 Location: Pomona, California.
|
Posted: Fri Jun 20, 2014 6:46 am Post subject: |
|
|
I have this machine, which is x86, and my other laptop, which I do plan on repairing as soon as I can afford a new mobo. I use the cross-compiler for both of those machines. Without it, I don't even want to consider how long it would take for this machine to update a new version of KDE (for instance).
I am about to the point where I'm ready to just get rid of the cross-compiler stuff, nuking all the associated files that aren't getting overwritten, then reinstall it through using the crossdev setup scripts instead of just a standard update.
It was my hope that I'd learn something about scripting and how some of these internals work. Apparently, there are some who think that's too much to ask. Therefore, to save everyone time, I'm probably going to do what everyone else does who runs into this problem; let the thread die unless and until I find a fix that does the trick.
EDIT: My apologies for the tone of the above, but I was harangued by someone in a private message before I got here. I will give some of the ideas here a try. I'm also getting together a list of files to nuke and copy. I am also considering creating a binary for gcc and so on so I can do a file refresh from one machine to the next without all the manual stuff. It's been a long day, and I have to work tomorrow, so it's time to go.
I do want to thank everyone (except the one doing the haranguing) for their input so far. I'm far from giving up. /EDIT
Cheers,
Pappy _________________ This space left intentionally blank, except for these ASCII symbols. |
|
Back to top |
|
|
krinn Watchman
Joined: 02 May 2003 Posts: 7470
|
Posted: Fri Jun 20, 2014 9:59 am Post subject: |
|
|
If distcc get an argument it cannot handle it will pass it gcc.
As distcc understand --version but not -v (that of course gcc understand), just go with distcc -v and you will at least see what gcc your distcc is calling. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|