During some configure step it calls gcc -V which is used to call a different version of gcc than the binary that you are just calling. Maybe a typo in the build-system? Reproducible: Always I have this package installed, but it needs to be rebuilt according to revdep-rebuild, the rebuild fails and I think the only thing that changed since I successfully built it is that I upgraded gcc to 4.4.3. I also have glibc-2.11.1 for archtesting purposes installed, otherwise this is a stable x86 system. $ emerge --info Portage 2.1.8.3 (default/linux/x86/10.0/desktop, gcc-4.4.3, glibc-2.11.1-r0, 2.6.33-gentoo i686) ================================================================= System uname: Linux-2.6.33-gentoo-i686-Intel-R-_Core-TM-2_Duo_CPU_L7500_@_1.60GHz-with-gentoo-2.0.1 Timestamp of tree: Wed, 19 May 2010 04:30:15 +0000 ccache version 2.4 [enabled] app-shells/bash: 4.0_p37 dev-java/java-config: 2.1.10 dev-lang/python: 2.6.4-r99 dev-python/pycrypto: 2.1.0_beta1 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.6.4-r3 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.0-r1 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.5, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.3-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="*" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=core2 -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config /var/lib/hsqldb" 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/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=core2 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests ccache collision-protect distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms splitdebug strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://de-mirror.org/distro/gentoo/ http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en en_US de ja es fr it" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_EXTRA_OPTS="--timeout=300" 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/sunrise /usr/local/portage/tom-overlay /home/tom/gentoo/sci /home/tom/gentoo/sage-on-gentoo" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa anthy apache2 avahi bash-completion berkdb bluetooth branding bzip2 cairo cddb cdparanoia cdr cjk cli consolekit cracklib crypt ctype cups curl cxx daap dbus djvu dri dts dvd dvdr emacs encode exif expat fam fbcon ffmpeg firefox flac fortran ftp gd gdbm gif gimp glut gmp gnome gnome-keyring gnutls gpm graphviz gstreamer gtk guile hal hdaps iconv ieee1394 imagemagick imap imlib ipod ipv6 java javascript jpeg kde latex lcms ldap leim libnotify lm_sensors m17n-lib mad migemo mikmod mime mmx mng modules mp3 mp4 mpeg mplayer mudflap mule musicbrainz mysql mysqli ncurses nls nptl nptlonly nsplugin obex ocaml ogg oggvorbis openal opengl openmp pam pango pcmcia pcre pdf perl php plasma plotutils png policykit ppds pppd python qt3support qt4 readline reflection samba sasl sdl semantic-desktop session slang smartcard spell spl sqlite sqlite3 sse ssl startup-notification svg sysfs tcpd texlive theora threads tiff tk truetype uim unicode usb v4l v4l2 visualization vorbis wicd wifi win32codecs wxwindows x264 x86 xcb xcomposite xft xine xinerama xml xorg xulrunner xv xvid zeroconf zlib zsh-completion" 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 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 unique_id userdir usertrack vhost_alias" DVB_CARDS="usb-dib0700" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_US de ja es fr it" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="intel" 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, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS
Created attachment 232055 [details] zipped build.log with failures (was 2MB)
I tried again and successfully compiled it this time. This package has this self-tuning business (which makes no sense with portage anyway... unless portage could ensure that cpu-throttling is deactivated), and it could be related to that. Could be that the error occurs on a path that I have not taken this time?
Hmm, I think I've hit a problem with gcc-4.4.3-r2 and blas-atlas-3.8.0 (latest stable x86). Will attach my log shortly.
Created attachment 233933 [details] build.log
I claim that this bug is independent of the gcc-version. It results from bugs in the makefiles where people try to call libtool or gcc with the "-V" option to get the version string. This is simply wrong (should be "-v"). The build.log confirms this, and I grep'ed the source tree. Here are a couple of candidates: configure: OUTTMP=`$LIBTOOL -V` configure: OUTTMP=`/usr/bin/libtool -V` Make.top: - $(ICC) -V 2>&1 >> bin/INSTALL_LOG/ERROR.LOG tune/sysinfo/emit_buildinfo.c: char *vflag[4] = {"--version", "-V", "-v", "-version"}; I think this stayed unnoticed since the respective make path is conditional on the tuning code and thus may be unnoticed on many machines.
Makes sense. This shouldn't block GCC stabilization then. :) Thanks for checking.
I disagree that the problem is with the "-V" switch or any of the other errors related to flags to gcc which are deprecated. In looking at the LOG files, I believe the problem is in: .../portage/sci-libs/blas-atlas-3.9.23-r4/work/ATLAS/gentoo-build/tune/blas/ger There is a command xr1ksearch. If one re-runs it, e.g.: ./xr1ksearch -p c as is done in the build, it produces a segmentation fault and core dumps. A quick gdb suggests that the fault is in main() -> CloneR1Node() with a fault at CloneR1Node+45. The code appears to be: 0x804912d <CloneR1Node>: push %ebp 0x804912e <CloneR1Node+1>: mov %esp,%ebp 0x8049130 <CloneR1Node+3>: push %edi 0x8049131 <CloneR1Node+4>: push %esi 0x8049132 <CloneR1Node+5>: push %ebx 0x8049133 <CloneR1Node+6>: sub $0x2c,%esp 0x8049136 <CloneR1Node+9>: cld 0x8049137 <CloneR1Node+10>: mov %eax,-0x1c(%ebp) 0x804913a <CloneR1Node+13>: movl $0x94,(%esp) 0x8049141 <CloneR1Node+20>: call 0x8048848 <malloc@plt> 0x8049146 <CloneR1Node+25>: mov %eax,%ebx 0x8049148 <CloneR1Node+27>: test %eax,%eax 0x804914a <CloneR1Node+29>: je 0x80491d9 <CloneR1Node+172> 0x8049150 <CloneR1Node+35>: mov $0x25,%ecx 0x8049155 <CloneR1Node+40>: mov %eax,%edi 0x8049157 <CloneR1Node+42>: mov -0x1c(%ebp),%esi => 0x804915a <CloneR1Node+45>: rep movsl %ds:(%esi),%es:(%edi) And looking at this and info reg, %esi is 0 which is going to cause a segfault. %esi comes from -0x1c(%ebp) which in turn comes from %eax. The code doesn't make any sense to me unless they are passing the arguments in registers in which case there is still a problem because that would suggest that CloneR1Node is called with a null argument. The error appears to be coming from the vicinity of lines 572-580 of .../work/ATLAS/tune/blas/ger/r1ksearch.c. The code is: /* * Find best kernel for in-L2 and in-L1 usage */ r1bestL1 = TimeAllKernelsForContext(L1CacheElts, 4, pre, r1b); r1bestL2 = TimeAllKernelsForContext(L1CacheElts, 3, pre, r1b); r1bestOC = TimeAllKernelsForContext(L1CacheElts, 2, pre, r1b); r1bestL1 = CloneR1Node(r1bestL1); r1bestL2 = CloneR1Node(r1bestL2); with the most probable error being r1bestL2 being null. CloneR1Node() is a static function defined in .../include/atlas_r1parse.h. Without going through the code in more detail it would look like TimeAllKernelsForContext() could potentially return a NULL and in that case calling CloneR1Node should be avoided (or at least handle NULL cases). I'd label this as a bug. But reading the notes in "INSTALL.txt" there are some hints that the ebuild may need to adjust the CPU throttling for the tuning to work properly. Perhaps that is the cause of the problem (I was running the "ondemand" CPU frequency scheduler (hacked to do the old-style Intel p4-clockmod.c scaling on a 2.8 GHz Pentium IV Prescott). But clearly xr1ksearch should not segfault no matter what the CPU frequencies are tuned to.
It might also be useful for someone to notify upstream regarding comment #7 because from where I sit the original source code is problematic and without knowing what the developer(s) are really intending to do (optimize performance across many MBO/OS/CPU architectures???) it would be difficult to patch downstream.
On a Pentium IV Prescott @ 2.8 GHz, the following sequence: /usr/bin/cpufreq-selector -g performance emerge blas-atlas > blas-atlas.lst 2>&1 /usr/bin/cpufreq-selector -g ondemand appeared to work around the problems with TimeAllKernelsForContext() and xr1ksearch segfaulting. However this isn't a good solution. Better would be code in the ebuild (or Makefile) to alter the CPU settings during the chip cache analysis phase. The cpufreq-selector utility appears to be part of the gnome-applets package and runs SUID root so it should always work if the kernel is configured for it. One could attempt to use cpufreq-selector in the ebuild and warn if it is missing or fails.
Hi, nice analysis! > I'd label this as a bug. But reading the notes in "INSTALL.txt" there are some > hints that the ebuild may need to adjust the CPU throttling for the tuning to > work properly. Perhaps that is the cause of the problem (I was running the > "ondemand" CPU frequency scheduler (hacked to do the old-style Intel > p4-clockmod.c scaling on a 2.8 GHz Pentium IV Prescott). Just a note: If I remember correctly I encountered the problem also with the performance governor for both cpu's. > But clearly xr1ksearch should not segfault no matter what the CPU frequencies > are tuned to. Indeed.
I am having problem of not being able to recompile blas-atlas on an older quad-opteron which has no throttling nor cpu frequency management at all (disabled in kernel). The problem actually started over a year ago, so it is not related to the latest gcc. I recall I run few times revdep-rebuild since then and it always fails.
(In reply to comment #11) > I am having problem of not being able to recompile blas-atlas on an older > quad-opteron which has no throttling nor cpu frequency management at all > (disabled in kernel). The problem actually started over a year ago, so it is > not related to the latest gcc. I recall I run few times revdep-rebuild since > then and it always fails. > Could you upload a build log? I have a slightly different problem in bug #324889 which one is closer to yours?
Somehow I managed to compile it using MAKEOPTS='-j1'. somehow it looks as autotunning conflicts with parallel compiling. Of course, all unnecessary scripts (X, xdm, hal, acpi, etc) should be stopped when emerging.
It looks for me, if I hit the same error on an old Pentium II, without any cpufreq scaling but with a hardened gentoo installation. 'emerge blas-atlas' fails every time with: ... Configured with: /var/tmp/portage/sys-devel/gcc-4.4.4-r2/work/gcc-4.4.4/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.4.4 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.4/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.4 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.4/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.4/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.4/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-esp --enable-libgomp --with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.4.4/python --enable-checking=release --enable-java-awt=gtk --with-arch=i686 --enable-languages=c,c++,java,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 4.4.4-r2 p1.2, pie-0.4.5' Thread model: posix gcc version 4.4.4 (Gentoo Hardened 4.4.4-r2 p1.2, pie-0.4.5) i686-pc-linux-gnu-gcc -V 2>&1 >> bin/INSTALL_LOG/ERROR.LOG i686-pc-linux-gnu-gcc: '-V' option must have argument make[4]: [error_report] Error 1 (ignored) i686-pc-linux-gnu-gcc --version 2>&1 >> bin/INSTALL_LOG/ERROR.LOG tar cf error_PII32.tar Make.inc bin/INSTALL_LOG/* gzip --best error_PII32.tar mv error_PII32.tar.gz error_PII32.tgz make[4]: Leaving directory `/var/tmp/portage/sci-libs/blas-atlas-3.8.0/work/ATLAS/gentoo-build' make[3]: Leaving directory `/var/tmp/portage/sci-libs/blas-atlas-3.8.0/work/ATLAS/gentoo-build' make[2]: Leaving directory `/var/tmp/portage/sci-libs/blas-atlas-3.8.0/work/ATLAS/gentoo-build/bin' Error report error_<ARCH>.tgz has been created in your top-level ATLAS directory. Be sure to include this file in any help request. cat: ../../CONFIG/error.txt: No such file or directory cat: ../../CONFIG/error.txt: No such file or directory make[1]: *** [build] Error 255 MAKEOPTS are not set in /etc/make.conf. What can I still test?
(In reply to comment #14) > It looks for me, if I hit the same error on an old Pentium II, without any > cpufreq scaling but with a hardened gentoo installation. > The bit you quoted is not very useful. It doesn't show the problem, just ATLAS report on your configuration. We'd need what came before that.
I hit this bug about 6 months ago and resolved it. Then my laptop died and I got a new one and hit it again today. Disable the ccache feature and that should fix the problem of the MVTUNE error. No idea where or how I got this idea, but it's at the top of my personal log file, which also noted this bug number and how none of the posted solutions work. Maybe other people can confirm, but I think this was all I changed in both cases between the failure reported here and successful build. If it's true, then the ebuild should be modified to turn off the feature, and we can close the bug as resolved.
(In reply to comment #16) > If it's true, then the ebuild should be modified to turn off the feature, and > we can close the bug as resolved. daid, I have the same problem and I do not use ccache. I do not believe ccache is the problem... or at least the only problem. Chris
same probelm here with gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.0, pie-0.4.7) no ccache, makeopts=j1and cpu set to performace! i hat this package compiled without problems, with no workarounds some weeks ago. now i made a complete reinstall of the whole system and getting this error. actually need this for working! :( did i miss any workaround? or is it completely broken? regards
(In reply to comment #18) > same probelm here with > > gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.0, pie-0.4.7) > > no ccache, makeopts=j1and cpu set to performace! > > > i hat this package compiled without problems, with no workarounds some weeks > ago. > now i made a complete reinstall of the whole system and getting this error. > > actually need this for working! :( > > did i miss any workaround? or is it completely broken? > I think it is broken. Do you really need 3.9.xx (development)? It has a few problems and the version in the main tree is quite old. I would recommend you use the stable version of atlas (3.8.4). If you _really_ need 3.9.xx you should use the science overlay but there is some work involved.
(In reply to comment #19) > (In reply to comment #18) > > same probelm here with > > > > gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.0, pie-0.4.7) > > > > no ccache, makeopts=j1and cpu set to performace! > > > > > > i hat this package compiled without problems, with no workarounds some weeks > > ago. > > now i made a complete reinstall of the whole system and getting this error. > > > > actually need this for working! :( > > > > did i miss any workaround? or is it completely broken? > > > I think it is broken. Do you really need 3.9.xx (development)? It has a few > problems and the version in the main tree is quite old. > > I would recommend you use the stable version of atlas (3.8.4). If you _really_ > need 3.9.xx you should use the science overlay but there is some work involved. Well, i dont think i really need 3.9.xx. I removed all cpu governors and intel idle drivers, etc. and try to remerge now. seems better than with governor performace, but is not ready yet. if it does not work, ill try with stable!
same problem with sci-libs/blas-atlas-3.8.2
(In reply to comment #21) > same problem with sci-libs/blas-atlas-3.8.2 you mean 3.8.4?
(In reply to comment #22) > (In reply to comment #21) > > same problem with sci-libs/blas-atlas-3.8.2 > > you mean 3.8.4? No, 3.8.4 is not existing on my tree: * sci-libs/blas-atlas [gentoo] Herd: sci (sci@gentoo.org) Maintainer: None specified Upstream: None specified Homepage: http://math-atlas.sourceforge.net/ Location: /usr/portage/sci-libs/blas-atlas Keywords: 3.8.0:0: alpha amd64 ppc ppc64 sparc x86 Keywords: 3.8.2:0: Keywords: 3.9.3:0: Keywords: 3.9.21:0: Keywords: 3.9.21-r1:0: Keywords: 3.9.23:0: Keywords: 3.9.23-r2:0: Keywords: 3.9.23-r4:0: ~alpha ~amd64 ~amd64-linux ~ppc ~ppc64 ~sparc ~x86 ~x86-linux ~x86-macos I accomplished emering 3.8.2 with removing INTLE_IDLE, ACPI_IDLE and all CPUFREQ options complete from my kernel config. I think it could be possible emerging 3.9.x too, because my errors were the same :) I can try i someone want to!
(In reply to comment #23) > (In reply to comment #22) > > (In reply to comment #21) > > > same problem with sci-libs/blas-atlas-3.8.2 > > > > you mean 3.8.4? > > No, 3.8.4 is not existing on my tree: > > * sci-libs/blas-atlas [gentoo] > Herd: sci (sci@gentoo.org) > Maintainer: None specified > Upstream: None specified > Homepage: http://math-atlas.sourceforge.net/ > Location: /usr/portage/sci-libs/blas-atlas > Keywords: 3.8.0:0: alpha amd64 ppc ppc64 sparc x86 > Keywords: 3.8.2:0: > Keywords: 3.9.3:0: > Keywords: 3.9.21:0: > Keywords: 3.9.21-r1:0: > Keywords: 3.9.23:0: > Keywords: 3.9.23-r2:0: > Keywords: 3.9.23-r4:0: ~alpha ~amd64 ~amd64-linux ~ppc ~ppc64 ~sparc ~x86 > ~x86-linux ~x86-macos > > > I accomplished emering 3.8.2 with removing INTLE_IDLE, ACPI_IDLE and all > CPUFREQ options complete from my kernel config. > > I think it could be possible emerging 3.9.x too, because my errors were the > same :) > > I can try i someone want to! How long since you last synced your tree? 3.8.4 has been in for months and 3.8.2 has been gone for some time. From what I can see I would date your tree at about 2 years behind.
(In reply to comment #24) > (In reply to comment #23) > > (In reply to comment #22) > > > (In reply to comment #21) > > > > same problem with sci-libs/blas-atlas-3.8.2 > > > > > > you mean 3.8.4? > > > > No, 3.8.4 is not existing on my tree: > > > > * sci-libs/blas-atlas [gentoo] > > Herd: sci (sci@gentoo.org) > > Maintainer: None specified > > Upstream: None specified > > Homepage: http://math-atlas.sourceforge.net/ > > Location: /usr/portage/sci-libs/blas-atlas > > Keywords: 3.8.0:0: alpha amd64 ppc ppc64 sparc x86 > > Keywords: 3.8.2:0: > > Keywords: 3.9.3:0: > > Keywords: 3.9.21:0: > > Keywords: 3.9.21-r1:0: > > Keywords: 3.9.23:0: > > Keywords: 3.9.23-r2:0: > > Keywords: 3.9.23-r4:0: ~alpha ~amd64 ~amd64-linux ~ppc ~ppc64 ~sparc ~x86 > > ~x86-linux ~x86-macos > > > > > > I accomplished emering 3.8.2 with removing INTLE_IDLE, ACPI_IDLE and all > > CPUFREQ options complete from my kernel config. > > > > I think it could be possible emerging 3.9.x too, because my errors were the > > same :) > > > > I can try i someone want to! > > How long since you last synced your tree? 3.8.4 has been in for months and > 3.8.2 has been gone for some time. From what I can see I would date your tree > at about 2 years behind. Syncing every day. Installed this system this week. Checked another server, which has exactly the same output of equery m sci-libs/blas-atlas. Which versiond do you see on your system? I also checked http://gpo.zugaina.org/sci-libs/blas-atlas Same versions here... No 3.8.4 in gentoo or overlays. weird!!
(In reply to comment #25) > (In reply to comment #24) > > (In reply to comment #23) > > > (In reply to comment #22) > > > > (In reply to comment #21) > > > > > same problem with sci-libs/blas-atlas-3.8.2 > > > > > > > > you mean 3.8.4? > > > > > > No, 3.8.4 is not existing on my tree: > > > > > > * sci-libs/blas-atlas [gentoo] > > > Herd: sci (sci@gentoo.org) > > > Maintainer: None specified > > > Upstream: None specified > > > Homepage: http://math-atlas.sourceforge.net/ > > > Location: /usr/portage/sci-libs/blas-atlas > > > Keywords: 3.8.0:0: alpha amd64 ppc ppc64 sparc x86 > > > Keywords: 3.8.2:0: > > > Keywords: 3.9.3:0: > > > Keywords: 3.9.21:0: > > > Keywords: 3.9.21-r1:0: > > > Keywords: 3.9.23:0: > > > Keywords: 3.9.23-r2:0: > > > Keywords: 3.9.23-r4:0: ~alpha ~amd64 ~amd64-linux ~ppc ~ppc64 ~sparc ~x86 > > > ~x86-linux ~x86-macos > > > > > > > > > I accomplished emering 3.8.2 with removing INTLE_IDLE, ACPI_IDLE and all > > > CPUFREQ options complete from my kernel config. > > > > > > I think it could be possible emerging 3.9.x too, because my errors were the > > > same :) > > > > > > I can try i someone want to! > > > > How long since you last synced your tree? 3.8.4 has been in for months and > > 3.8.2 has been gone for some time. From what I can see I would date your tree > > at about 2 years behind. > > Syncing every day. > Installed this system this week. > Checked another server, which has exactly the same output of equery m > sci-libs/blas-atlas. Which versiond do you see on your system? > I also checked http://gpo.zugaina.org/sci-libs/blas-atlas > Same versions here... > No 3.8.4 in gentoo or overlays. > weird!! google -> blas-atlas-3.8.4 --> 0 results are you really sure??
No, I have been living with the science overlay for so long that I didn't realize 3.8.4 hadn't made it to the main tree. Naming is a bit different too. We really have to get something new from the science overlay on that front.
http://sourceforge.net/tracker/index.php?func=detail&aid=3179681&group_id=23725&atid=379483 Date: 2011-05-16 10:30:05 PDT Sender: rwhaleyProject Admin OK, let's try 3.9.41, and let us start out with simple flags and go from there. You should *NEVER* throw the -Si cputhrchk 0 . I am seriously considering removing this option, because it seems everyone is using rather than turning off throttling, and thus the ATLAS libraries they generate, when they do succeed in generating them, are complete pieces of crap. So if -Si cputhrchk 0 is crap and broken , why is Gentoo using this on my ~x86 for 3.9.x ???
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.
