Following this guide http://www.gentoo.org/proj/en/base/embedded/handbook/?part=1&chap=4 Ι am trying to build a x86_64 toolchain. Glibc fails to configure with the following error Maybe there is missing dependency? Reproducible: Always Steps to Reproduce: 1.crossdev -t x86_64-gentoo-linux-gnu 2. 3. Actual Results: checking for tls_model attribute... yes checking for libgd... no checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for long double... yes checking size of long double... 16 running configure fragment for sysdeps/x86_64/elf checking for x86-64 TLS support... yes running configure fragment for nptl/sysdeps/pthread checking for forced unwind support... no configure: error: forced unwind support is required * * ERROR: cross-x86_64-gentoo-linux-gnu/glibc-2.9_p20081201-r2 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 3615: Called eblit-run 'src_compile' * environment, line 1224: Called eblit-glibc-src_compile * src_compile.eblit, line 180: Called src_compile * environment, line 3615: Called eblit-run 'src_compile' * environment, line 1224: Called eblit-glibc-src_compile * src_compile.eblit, line 188: Called toolchain-glibc_src_compile * src_compile.eblit, line 121: Called glibc_do_configure 'nptl' * src_compile.eblit, line 98: 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/cross/x86_64-gentoo-linux-gnu/portage/cross-x86_64-gentoo-linux-gnu/glibc-2.9_p20081201-r2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/cross/x86_64-gentoo-linux-gnu/portage/cross-x86_64-gentoo-linux-gnu/glibc-2.9_p20081201-r2/temp/environment'. * This ebuild is from an overlay named 'kde': '/usr/local/portage/layman/kde-testing/' * Expected Results: crossdev -t x86_64-gentoo-linux-gnu should be able to create a valid x86_64 toolchain I can attach the whole build.log if you think it ll help you
emerge --info please.
Here it is Portage 2.2_rc33 (default/linux/amd64/2008.0, gcc-4.3.3, glibc-2.9_p20081201-r2, 2.6.29-gentoo-r1 x86_64) ================================================================= System uname: Linux-2.6.29-gentoo-r1-x86_64-AMD_Phenom-tm-_8650_Triple-Core_Processor-with-gentoo-2.0.0 Timestamp of tree: Mon, 04 May 2009 16:45:01 +0000 distcc 3.1 x86_64-pc-linux-gnu [disabled] ccache version 2.4 [disabled] app-shells/bash: 4.0_p17-r1 dev-java/java-config: 2.1.7 dev-lang/python: 2.4.4-r15, 2.5.4-r2, 2.6.2 dev-python/pycrypto: 2.0.1-r8 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.6.3-r1 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.4.3-r2 sys-apps/sandbox: 1.9 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.19.1-r1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.28-r1 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=k8 -pipe -ggdb -Wall" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=k8 -pipe -ggdb -Wall" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://files.gentoo.gr/ ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo ftp://ftp.first-world.info/" LDFLAGS="-Wl,-O1" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" 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" PORTDIR_OVERLAY="/usr/local/portage/layman/kde-testing /usr/local/portage/layman/qting-edge" SYNC="rsync://files.gentoo.gr/gentoo-portage" USE="X a52 aac acl acpi alsa amd64 apm bash-completion berkdb bluetooth bzip2 bzlib cairo cdr chm cli cracklib crypt ctype cups custom-cxxflags dbus dga divx divx4linux dri dvd dvdr dvdread encode fat ffmpeg flac foomaticdb ftp gd gdbm gif gimp gimpprint glib glitz gnutls gphoto2 gpm hal iconv id3tag imagemagick imlib ipw4965 isdnlog java jpeg kde laptop libwww lm_sensors midi mime mjpeg mmx mmxext mng mozilla mp3 mp4 mpeg mplayer mudflap multilib multiuser mysql ncurses nls nptl nsplugin ntfs ogg opengl openmp pam pcntl pcre pdf perl php png posix pppd python qt3 qt3support qt4 quicktime rar readline reflection reiserfs ruby session simplexml slang smp sockets spell spl sqlite sqlite3 srt sse sse2 ssl ssse3 subtitles subversion svg symlink sysfs syslog tcpd threads truetype unicode usb userlocales v4l v4l2 x264 xcomposite xfs xine xml xmlreader xorg xscreensaver xvid zip zlib" ALSA_CARDS="hda-intel" 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="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Somewhere in /var/tmp/cross/x86_64-gentoo-linux-gnu/portage/cross-x86_64-gentoo-linux-gnu/glibc-2.9_p20081201-r2/work should a config.log exist. Please attach it.
Created attachment 192214 [details] config.log from /var/tmp/cross/x86_64-gentoo-linux-gnu/portage/cross-x86_64-gentoo-linux-gnu/glibc-2.9_p20081201-r2/work/build-x86-x86_64-gentoo-linux-gnu-nptl/
Created attachment 192216 [details] /var/tmp/cross/x86_64-gentoo-linux-gnu/portage/cross-x86_64-gentoo-linux-gnu/glibc-2.9_p20081201-r2/work/build-amd64-x86_64-gentoo-linux-gnu-nptl/
a x86_64-gentoo-linux-gnu tuple on a x86_64-unknown-linux-gnu system makes no sense at all. that isnt cross-compiling.
It doesnt?? So how are you gonna compile packages for Intel machines when you are running an AMD host? What is your proposal?
your description is way too vague. both systems have the same exact ABI, so the only difference is in optimizations -- which gcc can already do on the fly with different compiler flags.
I am wondering if my scenario is too exotic to be conceived. Assuming you have 2 hosts. Phenom and Intel core2duo respectively. In order to build packages for intel core2duo on Phenom host you need to change a hell of files to match intel core2duo system optimization Such files are make.conf, package.use, package.keywords etc etc etc. Why is it unreasonable to built x86_64 toolchain on x86_64 machine? How am I supposed to build those intel optimized packages on phenom? by using a 'home-made' script which overrides those system files? Anyway, since this is the case, I think my scenario is pointless :/
if you're talking about distcc, then no you dont. if you're talking about dynamically linking, then no you dont. if you're talking about statically linking, then yeah probably.
I`m add this if is_crosscompile ; then echo "PWD is ${PWD}" rm -rf ${S}/../config.cache echo "libc_cv_forced_unwind=yes" > ${S}/../config.cache echo "libc_cv_c_cleanup=yes" >> ${S}/../config.cache myconf="${myconf} --cache-file=${S}/../config.cache" fi to end glibc_do_configure() in /usr/portage/sys-libs/glibc/files/eblits/src_compile.eblit
