Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 56842 - blas-atlas 3.6.0 fails during install
Summary: blas-atlas 3.6.0 fails during install
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Toolchain Maintainers
Depends on:
Reported: 2004-07-12 16:55 UTC by giggles1
Modified: 2004-11-28 17:43 UTC (History)
9 users (show)

See Also:
Package list:
Runtime testing required: ---

atlas.log (atlas.log.bz2,103.68 KB, text/plain)
2004-08-09 00:55 UTC, giggles1

Note You need to log in before you can comment on or make changes to this bug.
Description giggles1 2004-07-12 16:55:07 UTC
(cd .libs && rm -f && ln -s ../
install .libs/ /usr/local/portage/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/
strip --strip-unneeded /usr/local/portage/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/
(cd /usr/local/portage/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs && rm -f && ln -s
(cd /usr/local/portage/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs && rm -f && ln -s
install .libs/libatlas.lai /usr/local/portage/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/
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 ../libs/ *.lo \
        -rpath /usr/lib/blas/atlas -lg2c ; \
libtool --mode=install install -s /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: `' is not a valid libtool archive
Try `libtool --help --mode=install' for more information.
make[1]: *** [] 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*
lrwxrwxrwx  1 root root   17 Jul 12 16:39 ->*
lrwxrwxrwx  1 root root   17 Jul 12 16:39 ->*
-rwxr-xr-x  1 root root 6.9M Jul 12 16:39*

Reproducible: Always
Steps to Reproduce:

please libs # emerge info
Portage 2.0.50-r9 (default-x86-1.4, gcc-3.4.1, glibc-,
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
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"
FEATURES="autoaddcvs ccache fixpackages sandbox"
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"
Comment 1 George Shapovalov (RETIRED) gentoo-dev 2004-07-12 20:22:48 UTC
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..

Comment 2 giggles1 2004-07-12 23:15:43 UTC
I have libtool 1.5.6 installed.
Comment 3 Philippe Trottier (RETIRED) gentoo-dev 2004-07-14 01:20:22 UTC
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.
Comment 4 George Shapovalov (RETIRED) gentoo-dev 2004-07-17 12:41:30 UTC
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..

Adding you to this bug. Looks like we have yet another libtool issue on our hands. Could you please take a look?

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 ;).

Comment 5 giggles1 2004-07-17 18:22:11 UTC
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.
Comment 6 giggles1 2004-07-17 18:24:14 UTC
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.
Comment 7 George Shapovalov (RETIRED) gentoo-dev 2004-07-17 22:18:54 UTC
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: `' 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.

Comment 8 giggles1 2004-07-17 23:41:03 UTC
please root # find / -name 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). 
Comment 9 giggles1 2004-07-18 01:06:31 UTC
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.
Comment 10 giggles1 2004-07-18 17:28:47 UTC
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. 
Comment 11 Derek Dolney 2004-07-26 12:04:34 UTC
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?


Comment 12 giggles1 2004-07-27 09:22:55 UTC
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.
Comment 13 Derek Dolney 2004-07-27 09:35:06 UTC
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.

Comment 14 giggles1 2004-08-01 11:33:55 UTC
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 -> /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
Comment 15 Derek Dolney 2004-08-08 14:22:19 UTC
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.
Comment 16 giggles1 2004-08-09 00:55:39 UTC
Created attachment 37080 [details]

It's really really big. I haven't looked at it yet, save to verify that the
problem still showed up.
Comment 17 Philippe Trottier (RETIRED) gentoo-dev 2004-09-07 09:22:03 UTC
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.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
CFLAGS="-O2 -mtune=970 -pipe"
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"
FEATURES="autoaddcvs ccache sandbox"
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"
Comment 18 Philippe Trottier (RETIRED) gentoo-dev 2004-09-07 09:26:05 UTC
blas-atlas used on ppc-gentoo using gcc-3.4.1 seems to return believable numbers using R.
Comment 19 Rob Kruus 2004-09-07 12:13:26 UTC
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.
Comment 20 Rob Kruus 2004-09-07 12:51:23 UTC
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.
Comment 21 Rob Kruus 2004-09-08 06:29:52 UTC
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)

 /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'
Comment 22 Derek Dolney 2004-09-08 11:32:22 UTC
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).
Comment 23 Rob Kruus 2004-09-08 13:16:16 UTC
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.
Comment 24 Rob Kruus 2004-09-13 06:16:03 UTC
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. :-)
Comment 25 George Shapovalov (RETIRED) gentoo-dev 2004-10-03 17:00:37 UTC
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..

Comment 26 giggles1 2004-10-04 10:14:17 UTC
All right, I'll give this  a whirl this afternoon.
Comment 27 Rob Kruus 2004-10-04 11:22:23 UTC
Still get the same no such file or directory error here.
Comment 28 giggles1 2004-10-04 19:47:47 UTC
Ditto. Build still fails, in the same place as before as far as I can tell. 
Comment 29 George Shapovalov (RETIRED) gentoo-dev 2004-10-11 18:05:34 UTC
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.

Comment 30 Rob Kruus 2004-10-12 06:29:14 UTC
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"

(though changing the CFLAGS doesn't make it work either)

bob@kruuslt ~ $ gcc-config -c

Comment 31 giggles1 2004-10-12 09:39:08 UTC
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
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
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. 
Comment 32 Priit Laes (IRC: plaes) 2004-10-12 12:37:01 UTC
Dell Latitude C600 with Pentium3, also same bx clobbering message...

decoder ~ # uname -a Linux decoder #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-
decoder ~ # grep CFLAGS /etc/make.conf
CFLAGS="-O2 -mtune=pentium3"
decoder ~ #
Comment 33 Donnie Berkholz (RETIRED) gentoo-dev 2004-11-03 22:25:07 UTC
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-
donnie@supernova ~ $ emerge -V
Portage 2.0.51-r2 (default-x86-2004.2, gcc-3.4.2, glibc-, 2.6.9-gentoo-r1 i686)
donnie@supernova ~ $ grep ^CFLAGS /etc/make.conf
CFLAGS="-O2 -march=athlon-mp -pipe -fomit-frame-pointer"
Comment 34 SpanKY gentoo-dev 2004-11-23 22:19:18 UTC
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)
Comment 35 Disenchanted (RETIRED) gentoo-dev 2004-11-28 16:16:27 UTC
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
Comment 36 Disenchanted (RETIRED) gentoo-dev 2004-11-28 17:43:45 UTC
sync in 35 minutes, blas-atlas now compiles on x86