See attached build log… not sure if it's caused by --as-needed or it's something that lives around. Portage 2.1.8.3 (default/linux/x86/10.0, gcc-4.4.3-asneeded, glibc-2.11-r1, 2.6.33.2 i686) ================================================================= System uname: Linux-2.6.33.2-i686-Quad-Core_AMD_Opteron-tm-_Processor_2350-with-gentoo-2.0.1 Timestamp of tree: Sun, 04 Apr 2010 19:30:01 +0000 ccache version 2.4 [disabled] app-shells/bash: 4.1_p2-r1 dev-java/java-config: 1.3.7-r1, 2.1.10 dev-lang/python: 2.6.5-r1, 3.1.2-r1 dev-python/pycrypto: 2.1.0 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.8.1 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.1-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.4_p6-r1, 1.5-r1, 1.6.3-r1, 1.7.9-r2, 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1 sys-devel/gcc: 4.4.3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.33 ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="*" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/openfire/resources/security/ /opt/openjms/config /usr/lib/tomoyo/conf /usr/share/X11/xkb /usr/share/bufrtables /usr/share/config /usr/share/qpsmtpd/plugins /var/bind /var/lib/hsqldb /var/phxd /var/spool/torque /var/vpopmail/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /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/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -pipe" DISTDIR="/var/cache/distfiles" FEATURES="assume-digests distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms split-log strict test test-fail-continue unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="http://ftp.uni-erlangen.de/pub/mirrors/gentoo" INSTALL_MASK=" /usr/share/doc /usr/share/info" LANG="en_US.utf8" LDFLAGS="-Wl,-O1" MAKEOPTS="-j14" PKGDIR="/var/spool/portage/packages" PORTAGE_COMPRESS="" 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="/var/cache/portage/tree-tinderbox" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl berkdb bzip2 cli cracklib crypt cups cxx dri fortran gdbm gpm iconv ipv6 java5 java6 modules mudflap ncurses nls nostatic nptl nptlonly openmp pam pcre perl pppd python qt3support readline reflection ruby session spl ssl sysfs tcpd unicode vhosts x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" 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 auth_digest" ELIBC="glibc" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" RUBY_TARGETS="ruby18 jruby ruby19" USERLAND="GNU"
Created attachment 226871 [details] Build log
Which atlas versions are you using?
sci-libs/blas-atlas-3.9.21-r1 sci-libs/lapack-atlas-3.9.21-r1
(In reply to comment #3) > sci-libs/blas-atlas-3.9.21-r1 > sci-libs/lapack-atlas-3.9.21-r1 > Those versions hard hardmasked for that reason. Sadly I don't know whats wrong with them, because it is just the move from EAPI 0 -> 3
*** This bug has been marked as a duplicate of bug 308581 ***
Different failure, the same happens within the tests for 3.9.23 (-r0).
Created attachment 227117 [details] Build log
Could you do me a favour and set at least FFLAGS="-O2" and tretry?
Doesn't seem to change even with FFLAGS="-O2 -pipe" :(
(In reply to comment #9) > Doesn't seem to change even with FFLAGS="-O2 -pipe" :( > okay thanks anyways. I will look into that, once I have fixed -r1. Do you emerge it with CPU freq scaling enabled and/or parallel emerges. The package is very fragile towards this.
It's the tinderbox, so it's a -j14 over an 8-way system :)
perhaps you could try it with --jobs=1. the makeopts are okay, as the buildsystem itself reduces it when needed.
--jobs=1 for make? Because the tinderbox is serial, Portage is not running anything else but a fetch during build (and last build, not even that). A build system is either parallel safe or not, there is no middle ground, there.
It is safe in it self, but I recognized strange effects, when there was other load in background. But if that wasn't the case for you I will dig deeper and find what's going wrong. Thanks for your efforts.
Load in the background can only cause problems when the build system is parallel-unsafe. As I said there is no middle ground. What you could perceive as a middle-ground is “it works as long as the files are built in the expected order” which often gets kicked out by *high* parallel jobs values, or by variable load in the machine. At the next tinderbox pause I'll try with MAKEOPTS=-j1; if it works, the build system *is* parallel-unsafe.
(In reply to comment #15) > Load in the background can only cause problems when the build system is > parallel-unsafe. As I said there is no middle ground. What you could perceive > as a middle-ground is “it works as long as the files are built in the > expected order” which often gets kicked out by *high* parallel jobs values, > or by variable load in the machine. So far so good for plain builds, but the atlas buildsystem creates customized headers for each platform during build by running a some kind of benchmark suite. And at least this is extremely sensitive to system load. Perhaps resulting from bad things in this, the complete build has problems. But you are right, missing symbols shouldn't be an issue. > > At the next tinderbox pause I'll try with MAKEOPTS=-j1; if it works, the build > system *is* parallel-unsafe. Thanks, that really would help
Still a problem, both with the new ebuild, and with serial make :(
Are you sure that you eselected atlas as blas implementation?
Dropped all atlas packages from tree. Please use sci-libs/atlas from sci overlay. If problem still exist with that package, please reopen the bug or file a new one.
