| Summary: | blas-atlas 3.6.0 fails during install | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | giggles1 <bevdv> |
| Component: | [OLD] Library | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | VERIFIED WORKSFORME | ||
| Severity: | normal | CC: | crowbar, dberkholz, george, lv, morfic, paulh, ppc64, sci, z23 |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | atlas.log | ||
Hi giggles1. Can you please post the libtool version you have installed? These ebuilds require 1.5 to build correctly. They actually have ">=sys-devel/libtool-1.5" in their DEPEND, but I wonder if you by some chance ended up with some combination of 1.4 and 1.5.. George I have libtool 1.5.6 installed. The problem shows on a clean install of ppc too, from stage1 folow manual and emerge lapack-atlas will break at blas-atlas if you remove the patch for shared lib and related make it will continue. Ok, tested one other variable that you had - I am in process of switching to gcc-3.4. blas-atlas built fine with gcc-3.4.1-r1. That leaves only libtool as a reason.. Apparently libtool-1.5.6 again breaks some compatibility. BTW, why are you running 1.5.6, its not even unmasked yet! 1.5.2 is the testing one at the moment and 1.4.3 is the stable one. Things are masked for a reason usually ;). From how it looks, I think it'll make a bit longer for libtool-1.5.6 to go into testing.. Derek: Adding you to this bug. Looks like we have yet another libtool issue on our hands. Could you please take a look? Travis: Looks like you are the one who is tracking libtool-1.5.6 Adding you to CC so that you are aware of another issue ;). George Downgrading to libtool 1.5.2 does not fix. Same error, it's trying to cd into a *file* cd gentoo/libf77blas.a Can you make a use flag to turn the shared-lib patch off? If phillippe is right that is where the problem is. I should add, this problem is not isolated to one system. It happens on both my AMD desktop and my P4 laptop. I tried on both just now with libtool-1.5.2. Well, the thing is it did compile here with shared libs on two architectures (x86, amd64) as well as for a few other people (and there are test reports on ppc as well). So we'll have to look for more details on what exactly is the difference. (Oh, and I still cannot reproduce it here). Actually the error is very much like what I saw with libtool 1.4. The more relevant lines are these two: libtool: link: `*.lo' is not a valid libtool object libtool: install: `libblas.la' is not a valid libtool archive So, is there any chance that you have an old version of libtool still hanging around? Ok, will try to take a closer look into this soon. George please root # find / -name libtool /usr/bin/libtool /usr/lib/R/bin/libtool /usr/lib/apache2/build/libtool /usr/local/src/gaim-0.79-vv-3/libtool /usr/local/src/libj2k-0.0.8/libtool /usr/local/src/linphone-im/oRTP/libtool /usr/local/src/linphone-im/speex/libtool /usr/local/src/linphone-im/libtool /usr/local/src/linphone-im/ffmpeg/libavcodec/libtool /usr/local/src/linphone-im/osipua/libtool All of the libtool's outside /usr/local/src are 1.5 or later. In fact some of the ones buried in /usr/local/srx are 1.4.x but I only installed all of those /usr/local/src programs on July 15th and this problem is from earlier than that date (and I do not think the blas-atlas build would somehow have randomly found and used those libtools anyhow). OK, the problem is not libtool. The problem is that the gentoo/libf77blas.a directory is not getting created. I note that these directories are created by the archive wrapper "war" and that this is stored in the ARCHIVER variable. After a little digging in the makes directory, I noted that the only difference in the ARCHIVER lines in Make.cblas and make.f77blas was that in Make.f77blas the ARCHIVER lines were continued with a "\" over two lines. On a lark, I removed these and made the two lines into one line, as in makes/Make.cblas. After some more digging I noted that these makefiles get copied somewhere under the interfaces directory. So I copied it there by hand, did a "make clean" and "make all" in the f77 interface directory, and lo and behold the gentoo/libf77blas.a directory now exists where it did not before. Now going back to the top level and issuing make shared arch=Linux_ATHLONSSE1_2 finishes without any issue whatsoever. I don't know why my systems (and phillippe's presumeably) don't like the split lines in makes/Make.f77blas but that is almost certainly the problem. All right, it isn't the split lines, as trying to build with a patched Make.f77blas confirms (OK, well, this isn't really surprising..) But the root problem is that gentoo/libf77blas.a is not getting created in the first place -- libtool is only complaining because the files it expects are not there to begin with (which would certiainly make them "not valid libtool archives"). However, if I go down in the interfaces/blas/F77/src/Linux_XXXXX directory and do a "make all" by hand and then "ebuild ... install; ebuild ... qmerge" also by hand, so that the existing source tree (now with gentoo/libf77blas.a now present), it finally successfully installs. Why it does not build this one directory I don't know. giggles1, can you try something for me? libf77blas.a is the serial version of the f77 blas. I'm guessing that atlas only builds the parallel version, libptf77blas.a, on your architecture. I've built atlas on a dual Xeon and it built BOTH libf77blas and libptf77blas, but maybe something different happens on Athlon MP. I don't have access to such a machine...:( So can you build a clean atlas, no gentoo patches, no ebuild, just atlas by itself? Just unpack the atlas3.6.0.tar.bz2 in some temp location and do make config CC="gcc" make install arch=Linux_ATHLONSSE1_2 When its done, check in lib/Linux_ATHLONSSE1_2. Please tell me which libraries it built. By the way, did you use the interactive configure, or just the default build? Thanks, Derek I used the default ebuild. Also, just FYI I have the same problem on a P4 "SMP" (hyperthreaded) box as well. I also thought maybe is was only building the parallel parts. Anyhow, I would be happy to try and build it by hand from the tarball but I am playing LA tour guide to out of town visitors this week, so I probably won'tbe able to get to it until this weekend. No problem. Please try it when you can. I will try building on a dual Xeon again, just to be sure. This is kind of strange. Derek This is completely unpatched. It seems to get built: please ATLAS # la lib/Linux_ATHLONSSE1_2/ total 13M drwxr-xr-x 2 root root 320 Aug 1 11:26 ./ drwxr-xr-x 3 500 floppy 144 Aug 1 11:05 ../ lrwxrwxrwx 1 root root 44 Aug 1 11:05 Make.inc -> /usr/local/src/ATLAS/Make.Linux_ATHLONSSE1_2 -rw-r--r-- 1 root root 1.5K Aug 1 11:05 Makefile -rw-r--r-- 1 root root 11M Aug 1 11:25 libatlas.a -rw-r--r-- 1 root root 305K Aug 1 11:21 libcblas.a -rw-r--r-- 1 root root 359K Aug 1 11:25 libf77blas.a -rw-r--r-- 1 root root 347K Aug 1 11:25 liblapack.a -rw-r--r-- 1 root root 306K Aug 1 11:25 libptcblas.a -rw-r--r-- 1 root root 359K Aug 1 11:26 libptf77blas.a -rw-r--r-- 1 root root 376K Aug 1 11:07 libtstatlas.a I don't know what's happening. The war wrapper should make links for all the object files that went into libf77blas.a in gentoo/libf77blas.a/. It would be easy to reply works-for-me, but that doesn't help. If you don't mind, run emerge blas-atlas > atlas.log 2>&1 Then we can dig through the build messages for something. Maybe you already tried, but I want to look for any messages when it should be making libf77blas.a/ and dropping links in there. Created attachment 37080 [details]
atlas.log
It's really really big. I haven't looked at it yet, save to verify that the
problem still showed up.
Successfuly compile app-sci/blas-atlas-3.6.0 on ppc64 with gcc-3.4.1 Overnight testing with R should tell if it is actually returning meaning full numbers ... Portage 2.0.50-r10 (default-ppc64-2004.2, gcc-3.4.1, glibc-2.3.4.20040808-r0, 2.6.8-gentoo-r3) ================================================================= System uname: 2.6.8-gentoo-r3 ppc64 PPC970, altivec supported Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="ppc64" AUTOCLEAN="yes" CFLAGS="-O2 -mtune=970 -pipe" CHOST="powerpc64-unknown-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/share/config:/usr/kde/3.3/env:/usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mtune=970 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://trumpetti.atm.tut.fi/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://where.sgo.fi/gentoo-portage" USE="X berkdb blas bzlib cups dvd f77 foomaticdb gdbm gif gpm imlib jpeg kde libwww mitshm nls oggvorbis opengl oss pam perl png ppc64 python qt readline sdl slang ssl tcltk tcpd truetype xv" blas-atlas used on ppc-gentoo using gcc-3.4.1 seems to return believable numbers using R. I get the same here on a uniprocessor Athlon XP where blas-atlas fails with the same libtool error. Using libtool-1.5.2-r5. This strikes me as funny in the ...blas-atlas-3.6.0/work/ATLAS/makes/Make.bin
The line with the extra "-" occurs a few times...
>>>> - cd $(TOPdir)/interfaces/blas/F77/src/$(ARCH) ; $(MAKE) .....
I'll try later too see if it makes a difference.
This maybe why mine doesn't work -- so it never gets to the F77 build part. Though it still continues to try to install the libraries. The 'older' dev-libs/atlas compiles with no problem though (both are tagged 3.6.0) <BIG SNIP> /usr/bin/gcc -c -DL2SIZE=1048576 -I/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/include -I/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/include/Linux_AT HLONSSE1 -I/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/include/contrib -DAdd__ -DStringSunStyle -DATL_OS_Linux -DATL_ARCH_ATHLON -DATL_SSE1 -DATL_GAS_x 8632 -fomit-frame-pointer -O2 -DSREAL -DATL_NOL1PREFETCH -DATL_NOL2PREFETCH -DBETA0 -DALPHA1 -DATL_sgemvN_a1_x1_b0_y1=ATL_sgemvS_a1_x1_b0_y1 ATL_sgemvS. c -fPIC -DPIC -o .libs/ATL_sgemvS_b0.o /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/include/contrib/camm_dpa.h: In function `dp1dpNb0': /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/include/contrib/camm_dpa.h:1488: error: PIC register `bx' clobbered in `asm' /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/include/contrib/camm_dpa.h: In function `dp2dpNb0m': /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/include/contrib/camm_dpa.h:1488: error: PIC register `bx' clobbered in `asm' make[4]: *** [ATL_sgemvS_b0.o] Error 1 make[4]: *** Waiting for unfinished jobs.... /usr/bin/gcc -c -DL2SIZE=1048576 -I/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/include -I/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/include/Linux_AT HLONSSE1 -I/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/include/contrib -DAdd__ -DStringSunStyle -DATL_OS_Linux -DATL_ARCH_ATHLON -DATL_SSE1 -DATL_GAS_x 8632 -fomit-frame-pointer -O2 -DSREAL -DATL_NOL1PREFETCH -DATL_NOL2PREFETCH -DBETA1 -DALPHA1 -DATL_sgemvN_a1_x1_b1_y1=ATL_sgemvS_a1_x1_b1_y1 ATL_sgemvS. c -fPIC -DPIC -o .libs/ATL_sgemvS_b1.o /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/include/contrib/camm_dpa.h: In function `dp1dpNb1': /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/include/contrib/camm_dpa.h:1488: error: PIC register `bx' clobbered in `asm' /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/include/contrib/camm_dpa.h: In function `dp2dpNb1m': /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/include/contrib/camm_dpa.h:1488: error: PIC register `bx' clobbered in `asm' make[4]: *** [ATL_sgemvS_b1.o] Error 1 make[4]: Leaving directory `/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/src/blas/gemv/Linux_ATHLONSSE1' make[3]: *** [slib] Error 2 make[3]: Leaving directory `/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/src/blas/gemv/Linux_ATHLONSSE1' make[2]: *** [IBuildLibs] Error 2 make[2]: Leaving directory `/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/bin/Linux_ATHLONSSE1' I have finally found some time to work on this. giggles1 and Rob have the same problem: /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/include/contrib/camm_dpa.h: In function `dp1dpNb0': /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/include/contrib/camm_dpa.h:1488: error: PIC register `bx' clobbered in `asm' Rob is having this error on a uniprocessor Athlon XP, but this works-for-me on a uniprocessor Athlon XP, as I have again just verified. Rob, are you also using gcc 3.4? I'm now almost sure that's the problem. If either of you can, try with everything else the same, but use gcc 3.3. The old dev-libs/atlas works, even with gcc 3.4, because it does not try to compile PIC code (no shared libs). You are correct, I am using gcc-3.4. Thank you for the explanation. It's not really a huge problem not use the blas / atlas libs here. Just to update, it compiles fine here with gcc-3.3.4-r1, and the make sanity_test works as well (at least I couldn't find and sanityout files in the build directory). See how they behave with R-svn. :-) Rob, giggles1: gcc-3.4.2 is out, can you please test this package again? It (still) compiles fine here so we have to rely on you for testing. If the problem persists we will have to take the issue upstream to gcc developers. We will need a decent test-case for them I'd imagine, so we will need to narrow down the specific arch and C[XX]FLAGS used.. I would like to get done with this bug as its the only one holding new blas/lapack packages. We really need to complete the transition. Although I am leaning to press for transitioning all dependant packages to new bals/lapack anyway as old blas/lapack fail on more occasions already and are not really supported anymore.. George All right, I'll give this a whirl this afternoon. Still get the same no such file or directory error here. Ditto. Build still fails, in the same place as before as far as I can tell. OK, so the conclusion seems to be that this bug is due to gcc generating weird (asm) code on some specific arch(es). With that in mind I am reassigning the bug to our gcc team.
To expedite its processing could please everybody whose system tested "positive" on this bug report:
1. uname -a (so far it seems limited to certain line of Athlon-xp, 32 bit).
2. exact profile/gcc/glibc versions used, gcc-recognised USE flags and C[XX]FLAGS
Probably this will do better than trowing bunch of emerge info's here at this point. I am sure gcc people will ask for more if they need thisinfo.
gcc people: looking through herds.xml I decided to assign this bug to toolchain herd, is this the right place?
("Manages gcc/binutils/glibc and other toolchain-related packages")
Please reassign as appropriate if not.
Also, please see comment #21, which seems to be the real issue causing libtool complaints at a later stage.
George
bob@kruuslt ~ $ uname -a
Linux kruuslt 2.6.9-rc2-love4 #1 SMP Mon Oct 4 14:16:59 EDT 2004 i686 Mobile AMD Athlon(tm) XP 2400+ AuthenticAMD GNU/Linux
bob@kruuslt ~ $ grep CFLAGS /etc/make.conf
CFLAGS="-Os -march=athlon-xp -pipe -ftracer"
CXXFLAGS="${CFLAGS}"
(though changing the CFLAGS doesn't make it work either)
bob@kruuslt ~ $ gcc-config -c
i686-pc-linux-gnu-3.4.2
No this is not just limited to AMD, as I mentioned before it happens on both my dual AMD desktop and my P4 Intel laptop:
please ~ # uname -a
Linux please 2.6.8-gentoo-r3 #13 SMP Sun Oct 3 12:38:33 PDT 2004 i686 AMD Athlon(tm) MP 2000+ AuthenticAMD GNU/Linux
please ~ # gcc-config -c
i686-pc-linux-gnu-3.4.2
please ~ # grep CFLAGS /etc/make.conf
CFLAGS="-march=athlon-mp -O3 -fweb -ftracer -ffast-math -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"
laptop ~ # uname -a
Linux laptop 2.6.8-gentoo-r3 #11 SMP Sun Oct 10 10:52:42 PDT 2004 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux
laptop ~ # gcc-config -c
i686-pc-linux-gnu-3.4.2
laptop ~ # grep CFLAGS /etc/make.conf
CFLAGS="-O3 -fweb -ffast-math -march=pentium4 -ftracer -pipe -fomit-frame-pointer "
CXXFLAGS="$CFLAGS -fvisibility-inlines-hidden"
However, I have tried with C{XX}FLAGS reduced to nothing but "-pipe" to no avail.
Also, just to mention again, I got things working when I went into the work directory and started the make on the missing libs *by hand* It still seems to me that the "libtool" error is a problem with the build process just not building some things in the first place.
Dell Latitude C600 with Pentium3, also same bx clobbering message...
decoder ~ # uname -a Linux decoder 2.6.8.1 #7 Thu Aug 26 11:49:45 EEST 2004 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux
decoder ~ # gcc -v
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.2/specs
Configured with: /var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/configure --enable-version-specific-runtime-libs --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.4 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.2/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.2/include/g++-v3 --host=i686-pc-linux-gnu --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-shared --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --with-gnu-ld --enable-threads=posix --disable-multilib --enable-languages=c,c++,f77,objc,java
Thread model: posix
gcc version 3.4.2 (Gentoo Linux 3.4.2-r2, ssp-3.4.1-1, pie-8.7.6.5)
decoder ~ # grep CFLAGS /etc/make.conf
CFLAGS="-O2 -mtune=pentium3"
CXXFLAGS="${CFLAGS}"
decoder ~ #
I'm hitting this problem too. donnie@supernova ~ $ uname -a Linux supernova 2.6.9-gentoo-r1 #1 SMP Tue Oct 26 17:11:16 PDT 2004 i686 AMD Athlon(tm) MP 2000+ AuthenticAMD GNU/Linux donnie@supernova ~ $ emerge gcc -vp ... Calculating dependencies ...done! [ebuild R ] sys-devel/gcc-3.4.2-r3 -bootstrap -boundschecking -build -debug +f77 -gcj +gtk -hardened -multilib -n32 -n64 -nls -nocxx -objc -static (-uclibc) 0 kB donnie@supernova ~ $ gcc -v ... gcc version 3.4.2 20041025 (Gentoo Linux 3.4.2-r3, ssp-3.4.1-1, pie-8.7.6.5) donnie@supernova ~ $ emerge -V Portage 2.0.51-r2 (default-x86-2004.2, gcc-3.4.2, glibc-2.3.4.20041021-r0, 2.6.9-gentoo-r1 i686) donnie@supernova ~ $ grep ^CFLAGS /etc/make.conf CFLAGS="-O2 -march=athlon-mp -pipe -fomit-frame-pointer" ok, there are two bug reports here (BAD PEOPLE) i'm closing this bug because the original report seems to have been lost/fixed (the libtool / cd-ing into a .a file) the bug report that should have never been mentioned here (bx register being clobbered) is a bug in atlas, not gcc ... fix the atlas package (read: file a new bug report) i didnt notice another bug on this, so let me tell you blas-atlas is here locally fixed for the clobbering on x86, i will commit fixed ebuild soon, just a little fyi the libtool error comes from a error where something gets clobbered and make just never dies, anyway off to fixing it in portage now sync in 35 minutes, blas-atlas now compiles on x86 |
creating libatlas.la (cd .libs && rm -f libatlas.la && ln -s ../libatlas.la libatlas.la) install .libs/libatlas.so.0.0.0 /usr/local/portage/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libatlas.so.0.0.0 strip --strip-unneeded /usr/local/portage/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libatlas.so.0.0.0 (cd /usr/local/portage/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs && rm -f libatlas.so.0 && ln -s libatlas.so.0.0.0 libatlas.so.0) (cd /usr/local/portage/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs && rm -f libatlas.so && ln -s libatlas.so.0.0.0 libatlas.so) install .libs/libatlas.lai /usr/local/portage/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libatlas.la install .libs/libatlas.a /usr/local/portage/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libatlas.a strip --strip-debug /usr/local/portage/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libatlas.a ranlib /usr/local/portage/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libatlas.a chmod 644 /usr/local/portage/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libatlas.a libtool: install: warning: remember to run `libtool --finish /usr/lib' cd gentoo/libf77blas.a ; \ libtool --mode=link --tag=CC /usr/lib/ccache/bin/gcc -o libblas.la ../libs/libatlas.la *.lo \ -rpath /usr/lib/blas/atlas -lg2c ; \ libtool --mode=install install -s libblas.la /usr/local/portage/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs /bin/sh: line 1: cd: gentoo/libf77blas.a: No such file or directory libtool: link: `*.lo' is not a valid libtool object libtool: install: `libblas.la' is not a valid libtool archive Try `libtool --help --mode=install' for more information. make[1]: *** [libblas.so] Error 1 make[1]: Leaving directory `/usr/local/portage/portage/blas-atlas-3.6.0/work/ATLAS' make: *** [shared-strip] Error 2 !!! ERROR: app-sci/blas-atlas-3.6.0 failed. !!! Function src_compile, Line 102, Exitcode 2 !!! (no error messagge) The "cd gentoo/libf77blas.a" looks a bit strange to me. Here is what is in the gentoo and gentoo/libs dirs at this point in the build: please gentoo # la total 221K drwxr-xr-x 8 root root 232 Jul 12 15:57 ./ drwxr-xr-x 12 root root 560 Jul 12 16:07 ../ drwxr-xr-x 3 root root 167K Jul 12 16:39 libatlas.a/ drwxr-xr-x 3 root root 9.9K Jul 12 16:33 libcblas.a/ drwxr-xr-x 3 root root 11K Jul 12 16:36 libptcblas.a/ drwxr-xr-x 3 root root 20K Jul 12 16:37 libptf77blas.a/ drwxr-xr-x 2 root root 216 Jul 12 16:40 libs/ drwxr-xr-x 3 root root 16K Jul 12 16:11 libtstatlas.a/ please gentoo # la libs/ total 16M drwxr-xr-x 2 root root 216 Jul 12 16:40 ./ drwxr-xr-x 8 root root 232 Jul 12 15:57 ../ -rw-r--r-- 1 root root 8.6M Jul 12 16:40 libatlas.a -rwxr-xr-x 1 root root 791 Jul 12 16:39 libatlas.la* lrwxrwxrwx 1 root root 17 Jul 12 16:39 libatlas.so -> libatlas.so.0.0.0* lrwxrwxrwx 1 root root 17 Jul 12 16:39 libatlas.so.0 -> libatlas.so.0.0.0* -rwxr-xr-x 1 root root 6.9M Jul 12 16:39 libatlas.so.0.0.0* Reproducible: Always Steps to Reproduce: 1. 2. 3. please libs # emerge info Portage 2.0.50-r9 (default-x86-1.4, gcc-3.4.1, glibc-2.3.4.20040619-r0, 2.6.7-gentoo-r8) ================================================================= System uname: 2.6.7-gentoo-r8 i686 AMD Athlon(tm) MP 2000+ Gentoo Base System version 1.5.1 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-pipe -fvisibility-inlines-hidden" DISTDIR="/usr/local/portage/distfiles" FEATURES="autoaddcvs ccache fixpackages sandbox" GENTOO_MIRRORS="ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://gentoo.binarycompass.org http://gentoo.ccccom.com http://gentoo.llarian.net/ ftp://mirrors.sec.informatik.tu-darmstadt.de/gentoo/" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/usr/local/portage" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/ebuilds" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X aalib acpi alsa arts artswrappersuid atlas avi berkdb blas bzlib cdr crypt cups curl dga directfb dvd encode esd f77 faad fbcon ffmpeg fftw flac foomaticdb freetype gd gdbm ggi gif gimpprint gnuplot gpm gs gstreamer gtk gtk2 gtkhtml guile imagemagick imap imlib imlib2 java javascript jikes jpeg kde lcms lmtp mad mikmod mmx mng mozdomi mozilla moznocompose moznoirc moznomail mozsvg mozxmlterm mpeg mplayer mysql ncurses netcdf nls nptl nvidia odbc offensive oggvorbis opengl oss pam passfile pcap pcre pdflib perl pic plotutils png ppds python qt qtmt quicktime readline samba sdl slang spell sse ssl stencil-buffer svga tcltk tcpd tetex threads tiff transcode truetype type1 usb vim-with-x wmf x86 xml xml2 xmms xv zlib"