Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
going back and looking at this error: C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC compile options: '-c' gcc: _configtest.c gcc -pthread _configtest.o -L/usr/local/atlas/lib -llapack -lptf77blas -lptcblas -latlas -o _configtest /usr/bin/ld: _configtest: hidden symbol `__powidf2' in /usr/lib/gcc/i486-linux-gnu/4.3.2/libgcc.a(_powidf2.o) is referenced by DSO /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status /usr/bin/ld: _configtest: hidden symbol `__powidf2' in /usr/lib/gcc/i486-linux-gnu/4.3.2/libgcc.a(_powidf2.o) is referenced by DSO /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status failure. removing: _configtest.c _configtest.o isnt that saying that _configtest.o is referencing something in libgcc which is not lined to in the compile command? Is this something I can add to the numpy setup script? This problem is really beating me down. I've gone back and re-made the atlas .so like 15 times linking with libgcc in 15 different ways. all to no avail Thanks again for any help! Chris ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
2009/3/29 Chris Colbert sccolb...@gmail.com: going back and looking at this error: C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC compile options: '-c' gcc: _configtest.c gcc -pthread _configtest.o -L/usr/local/atlas/lib -llapack -lptf77blas -lptcblas -latlas -o _configtest /usr/bin/ld: _configtest: hidden symbol `__powidf2' in /usr/lib/gcc/i486-linux-gnu/4.3.2/libgcc.a(_powidf2.o) is referenced by DSO /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status /usr/bin/ld: _configtest: hidden symbol `__powidf2' in /usr/lib/gcc/i486-linux-gnu/4.3.2/libgcc.a(_powidf2.o) is referenced by DSO /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status failure. removing: _configtest.c _configtest.o isnt that saying that _configtest.o is referencing something in libgcc which is not lined to in the compile command? Is this something I can add to the numpy setup script? This problem is really beating me down. I've gone back and re-made the atlas .so like 15 times linking with libgcc in 15 different ways. all to no avail The way to build shared libraries in atlas does not always work, and some auto-detected settings are often the wrong ones. There is unfortunately not much we can do to help - and understanding the exact problem may be quite difficult if you are not familiar with various build issues. David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
Robin, Thanks. I need to get the backport for multiprocessing on 2.5. But now, it's more of a matter of not wanting to admit defeat Cheers, Chris On Sat, Mar 28, 2009 at 2:30 PM, Robin robi...@gmail.com wrote: 2009/3/28 Chris Colbert sccolb...@gmail.com: Alright, building numpy against atlas from the repositories works, but this atlas only contains the single threaded libraries. So i would like to get my build working completely. It doesn't help at all with your problem - but I thought I'd point out there are other ways to exploit multicore machines than using threaded ATLAS (if that is your goal). For example, I use single threaded libraries and control parallel execution myself using multiprocessing module (this is easier for simple batch jobs, but might not be appropriate for your case). There is some information about this on the wiki: http://scipy.org/ParallelProgramming Cheers Robin ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
2009/3/28 Chris Colbert sccolb...@gmail.com: Alright, building numpy against atlas from the repositories works, but this atlas only contains the single threaded libraries. So i would like to get my build working completely. It doesn't help at all with your problem - but I thought I'd point out there are other ways to exploit multicore machines than using threaded ATLAS (if that is your goal). For example, I use single threaded libraries and control parallel execution myself using multiprocessing module (this is easier for simple batch jobs, but might not be appropriate for your case). There is some information about this on the wiki: http://scipy.org/ParallelProgramming Cheers Robin ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
2009/3/28 Chris Colbert sccolb...@gmail.com this is really, really, half of numpy.linalg works, the other half doesn't. working functions: cholesky det inv norm solve non-working functions (they all hang at 100% cpu): eig eigh eigvals eigvalsh pinv lstsq svd I must be a total n00b to be the only person running into this problem :) Cheers, What does your lapack make.inc file look like? Here is what I used on 64 bit Hardy back when. # LAPACK make include file. # # LAPACK, Version 3.1.1 # # February 2007 # # # See the INSTALL/ directory for more examples. # SHELL = /bin/sh # # The machine (platform) identifier to append to the library names # PLAT = _LINUX # # Modify the FORTRAN and OPTS definitions to refer to the # compiler and desired compiler options for your machine. NOOPT # refers to the compiler options desired when NO OPTIMIZATION is # selected. Define LOADER and LOADOPTS to refer to the loader and # desired load options for your machine. # FORTRAN = gfortran OPTS = -funroll-all-loops -O3 -fPIC DRVOPTS = $(OPTS) NOOPT= -fPIC LOADER = gfortran LOADOPTS = # # Timer for the SECOND and DSECND routines # # Default : SECOND and DSECND will use a call to the EXTERNAL FUNCTION ETIME # TIMER= EXT_ETIME # For RS6K : SECOND and DSECND will use a call to the EXTERNAL FUNCTION ETIME_ # TIMER= EXT_ETIME_ # For gfortran compiler: SECOND and DSECND will use a call to the INTERNAL FUNCTION ETIME TIMER= INT_ETIME # If your Fortran compiler does not provide etime (like Nag Fortran Compiler, etc...) # SECOND and DSECND will use a call to the INTERNAL FUNCTION CPU_TIME # TIMER= INT_CPU_TIME # If neither of this works...you can use the NONE value... In that case, SECOND and DSECND will always return 0 # TIMER = NONE # # The archiver and the flag(s) to use when building archive (library) # If you system has no ranlib, set RANLIB = echo. # ARCH = ar ARCHFLAGS= cr RANLIB = ranlib # # The location of the libraries to which you will link. (The # machine-specific, optimized BLAS library should be used whenever # possible.) # BLASLIB = ../../blas$(PLAT).a LAPACKLIB= lapack$(PLAT).a TMGLIB = tmglib$(PLAT).a EIGSRCLIB= eigsrc$(PLAT).a LINSRCLIB= linsrc$(PLAT).a Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
this is really, really, half of numpy.linalg works, the other half doesn't. working functions: cholesky det inv norm solve non-working functions (they all hang at 100% cpu): eig eigh eigvals eigvalsh pinv lstsq svd I must be a total n00b to be the only person running into this problem :) Cheers, Chris On Sat, Mar 28, 2009 at 2:42 PM, Chris Colbert sccolb...@gmail.com wrote: alright, so i solved the linking error by building numpy against the static atlas libraries instead of .so's. But my original problem persists. Some functions work properly, buy numpy.linalg.eig() still hangs. the build log is attached. Chris ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
here it is: 32 bit Intrepid # LAPACK make include file. # # LAPACK, Version 3.1.1 # # February 2007 # # SHELL = /bin/sh # # The machine (platform) identifier to append to the library names # PLAT = _LINUX # # Modify the FORTRAN and OPTS definitions to refer to the # compiler and desired compiler options for your machine. NOOPT # refers to the compiler options desired when NO OPTIMIZATION is # selected. Define LOADER and LOADOPTS to refer to the loader and # desired load options for your machine. # FORTRAN = gfortran OPTS = -O2 -fPIC DRVOPTS = $(OPTS) NOOPT= -O0 -fPIC LOADER = gfortran LOADOPTS = # # Timer for the SECOND and DSECND routines # # Default : SECOND and DSECND will use a call to the EXTERNAL FUNCTION ETIME #TIMER= EXT_ETIME # For RS6K : SECOND and DSECND will use a call to the EXTERNAL FUNCTION ETIME_ # TIMER= EXT_ETIME_ # For gfortran compiler: SECOND and DSECND will use a call to the INTERNAL FUNCTION ETIME TIMER= INT_ETIME # If your Fortran compiler does not provide etime (like Nag Fortran Compiler, etc...) # SECOND and DSECND will use a call to the INTERNAL FUNCTION CPU_TIME # TIMER= INT_CPU_TIME # If neither of this works...you can use the NONE value... In that case, SECOND and DSECND will always return 0 # TIMER = NONE # # The archiver and the flag(s) to use when building archive (library) # If you system has no ranlib, set RANLIB = echo. # ARCH = ar ARCHFLAGS= cr RANLIB = ranlib # # The location of the libraries to which you will link. (The # machine-specific, optimized BLAS library should be used whenever # possible.) # BLASLIB = ../../blas$(PLAT).a LAPACKLIB= lapack$(PLAT).a TMGLIB = tmglib$(PLAT).a EIGSRCLIB= eigsrc$(PLAT).a LINSRCLIB= linsrc$(PLAT).a ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
I notice my OPTS and NOOPTS are different than yours. (I went of scipy.orginstall guide) Do you think that's the issue? Cheers, Chris ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
2009/3/28 Chris Colbert sccolb...@gmail.com I notice my OPTS and NOOPTS are different than yours. (I went of scipy.orginstall guide) Do you think that's the issue? Probably not, but my experience is limited. IIRC, I also had to get the command line for building ATLAS just right and build LAPACK separately instead of having ATLAS do it. It took several tries and much poring through the ATLAS instructions. Something else to check is if you have another LAPACK/ATLAS sitting around somewhere. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
i just ran a dummy config on atlas and its giving me different OPTS and NOOPTS flags than the scipy tutorial. so im gonna try that and report back Chris 2009/3/28 Charles R Harris charlesr.har...@gmail.com 2009/3/28 Chris Colbert sccolb...@gmail.com I notice my OPTS and NOOPTS are different than yours. (I went of scipy.org install guide) Do you think that's the issue? Probably not, but my experience is limited. IIRC, I also had to get the command line for building ATLAS just right and build LAPACK separately instead of having ATLAS do it. It took several tries and much poring through the ATLAS instructions. Something else to check is if you have another LAPACK/ATLAS sitting around somewhere. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
2009/3/28 Chris Colbert sccolb...@gmail.com i just ran a dummy config on atlas and its giving me different OPTS and NOOPTS flags than the scipy tutorial. so im gonna try that and report back I think that I also had to explicitly specify the bit size flag on the ATLAS command line during various builds, -b32/64 or something like that... Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
yeah, I set -b 32 on atlas... the bogus atlas config was telling me to set OPTS = O -fPIC -m32 and NOPTS = O -fPIC -m32, this caused the make process of lapack to hang. So i set OPTS = O2 -fPIC -m32 and NOPTS = O0 -fPIC -m32. Which is the same as all of my first attempts except for the presence of -m32. so maybe specifying bit size here is needed too. Chris 2009/3/28 Charles R Harris charlesr.har...@gmail.com 2009/3/28 Chris Colbert sccolb...@gmail.com i just ran a dummy config on atlas and its giving me different OPTS and NOOPTS flags than the scipy tutorial. so im gonna try that and report back I think that I also had to explicitly specify the bit size flag on the ATLAS command line during various builds, -b32/64 or something like that... Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
YES! YES! YES! YES! HAHAHAHA! YES! using these flags in make.inc to build lapack 1.3.1 worked: OPTS = O2 -fPIC -m32 NOPTS = O2 -fPIC -m32 then build atlas as normal and build numpy against the static atlas libraries (building against the .so's created by atlas causes a linking error in numpy build.log. Numpy will still work, but who knows what function may be broken). Now, off to build numpy 1.3.0rc1 Thanks for all the help gents! Chris On Sat, Mar 28, 2009 at 4:27 PM, Chris Colbert sccolb...@gmail.com wrote: yeah, I set -b 32 on atlas... the bogus atlas config was telling me to set OPTS = O -fPIC -m32 and NOPTS = O -fPIC -m32, this caused the make process of lapack to hang. So i set OPTS = O2 -fPIC -m32 and NOPTS = O0 -fPIC -m32. Which is the same as all of my first attempts except for the presence of -m32. so maybe specifying bit size here is needed too. Chris 2009/3/28 Charles R Harris charlesr.har...@gmail.com 2009/3/28 Chris Colbert sccolb...@gmail.com i just ran a dummy config on atlas and its giving me different OPTS and NOOPTS flags than the scipy tutorial. so im gonna try that and report back I think that I also had to explicitly specify the bit size flag on the ATLAS command line during various builds, -b32/64 or something like that... Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
2009/3/28 Chris Colbert sccolb...@gmail.com YES! YES! YES! YES! HAHAHAHA! YES! using these flags in make.inc to build lapack 1.3.1 worked: OPTS = O2 -fPIC -m32 NOPTS = O2 -fPIC -m32 then build atlas as normal and build numpy against the static atlas libraries (building against the .so's created by atlas causes a linking error in numpy build.log. Numpy will still work, but who knows what function may be broken). Now, off to build numpy 1.3.0rc1 Thanks for all the help gents! You might need to run ldconfig to get the dynamic linking working. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
On Sat, Mar 28, 2009 at 3:34 PM, Charles R Harris charlesr.har...@gmail.com wrote: 2009/3/28 Chris Colbert sccolb...@gmail.com YES! YES! YES! YES! HAHAHAHA! YES! using these flags in make.inc to build lapack 1.3.1 worked: OPTS = O2 -fPIC -m32 NOPTS = O2 -fPIC -m32 then build atlas as normal and build numpy against the static atlas libraries (building against the .so's created by atlas causes a linking error in numpy build.log. Numpy will still work, but who knows what function may be broken). Now, off to build numpy 1.3.0rc1 Thanks for all the help gents! You might need to run ldconfig to get the dynamic linking working. Oh, and the *.so libs don't install automagically, I had to explicitly copy them into the library. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
what does ldconfig do other than refresh the library path? i copied the .so's to /usr/local/atlas/lib and added that path to /etc/ld.so.conf.d/scipy.conf and then did ldconfig this was before building numpy Chris 2009/3/28 Charles R Harris charlesr.har...@gmail.com On Sat, Mar 28, 2009 at 3:34 PM, Charles R Harris charlesr.har...@gmail.com wrote: 2009/3/28 Chris Colbert sccolb...@gmail.com YES! YES! YES! YES! HAHAHAHA! YES! using these flags in make.inc to build lapack 1.3.1 worked: OPTS = O2 -fPIC -m32 NOPTS = O2 -fPIC -m32 then build atlas as normal and build numpy against the static atlas libraries (building against the .so's created by atlas causes a linking error in numpy build.log. Numpy will still work, but who knows what function may be broken). Now, off to build numpy 1.3.0rc1 Thanks for all the help gents! You might need to run ldconfig to get the dynamic linking working. Oh, and the *.so libs don't install automagically, I had to explicitly copy them into the library. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
aside from a smaller numpy install size, what do i gain from linking against the .so's vs the static libraries? Chris On Sat, Mar 28, 2009 at 6:09 PM, Chris Colbert sccolb...@gmail.com wrote: what does ldconfig do other than refresh the library path? i copied the .so's to /usr/local/atlas/lib and added that path to /etc/ld.so.conf.d/scipy.conf and then did ldconfig this was before building numpy Chris 2009/3/28 Charles R Harris charlesr.har...@gmail.com On Sat, Mar 28, 2009 at 3:34 PM, Charles R Harris charlesr.har...@gmail.com wrote: 2009/3/28 Chris Colbert sccolb...@gmail.com YES! YES! YES! YES! HAHAHAHA! YES! using these flags in make.inc to build lapack 1.3.1 worked: OPTS = O2 -fPIC -m32 NOPTS = O2 -fPIC -m32 then build atlas as normal and build numpy against the static atlas libraries (building against the .so's created by atlas causes a linking error in numpy build.log. Numpy will still work, but who knows what function may be broken). Now, off to build numpy 1.3.0rc1 Thanks for all the help gents! You might need to run ldconfig to get the dynamic linking working. Oh, and the *.so libs don't install automagically, I had to explicitly copy them into the library. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
just to see if it would work. I compiled against the .so's and just didnt worry about the linking error. Then i installed numpy and ran numpy.test() these are the results: Ran 2030 tests in 9.778s OK (KNOWNFAIL=1, SKIP=11) nose.result.TextTestResult run=2030 errors=0 failures=0 so i guess that means its ok.. Chris On Sat, Mar 28, 2009 at 6:30 PM, Chris Colbert sccolb...@gmail.com wrote: aside from a smaller numpy install size, what do i gain from linking against the .so's vs the static libraries? Chris On Sat, Mar 28, 2009 at 6:09 PM, Chris Colbert sccolb...@gmail.comwrote: what does ldconfig do other than refresh the library path? i copied the .so's to /usr/local/atlas/lib and added that path to /etc/ld.so.conf.d/scipy.conf and then did ldconfig this was before building numpy Chris 2009/3/28 Charles R Harris charlesr.har...@gmail.com On Sat, Mar 28, 2009 at 3:34 PM, Charles R Harris charlesr.har...@gmail.com wrote: 2009/3/28 Chris Colbert sccolb...@gmail.com YES! YES! YES! YES! HAHAHAHA! YES! using these flags in make.inc to build lapack 1.3.1 worked: OPTS = O2 -fPIC -m32 NOPTS = O2 -fPIC -m32 then build atlas as normal and build numpy against the static atlas libraries (building against the .so's created by atlas causes a linking error in numpy build.log. Numpy will still work, but who knows what function may be broken). Now, off to build numpy 1.3.0rc1 Thanks for all the help gents! You might need to run ldconfig to get the dynamic linking working. Oh, and the *.so libs don't install automagically, I had to explicitly copy them into the library. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
Hey Everyone,
I built Lapack and Atlas from source last night on a C2D running 32-bit
Linux Mint 6. I ran 'make check' and 'make time' on the lapack build, and
ran the dynamic LU decomp test on atlas. Both packages checked out fine.
Then, I built numpy and scipy against them using the appropriate flags in
site.cfg for the parallel thread atlas libraries. This seems to have worked
properly as numpy.dot() utilizes both cores at 100% on very large arrays. I
have also done id(numpy.dot) and id(numpy.core.multiarray.dot) and verified
that the two ids are different.
So I believe the build went properly. The problem I am having now is that
numpy.linalg.eig (and the eig functions in scipy) hang at 100% CPU and never
returns (no matter the array size). Numpy.test() hung as well, I'm assuming
for this same reason. I have included the configurations below. Any idea
what would cause this?
Thanks!
Chris
Python 2.5.2 (r252:60911, Oct 5 2008, 19:24:49)
[GCC 4.3.2] on linux2
Type help, copyright, credits or license for more information.
import numpy
import scipy
numpy.show_config()
atlas_threads_info:
libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas']
library_dirs = ['/usr/local/atlas/lib']
language = f77
include_dirs = ['/usr/local/atlas/include']
blas_opt_info:
libraries = ['ptf77blas', 'ptcblas', 'atlas']
library_dirs = ['/usr/local/atlas/lib']
define_macros = [('NO_ATLAS_INFO', 2)]
language = c
include_dirs = ['/usr/local/atlas/include']
atlas_blas_threads_info:
libraries = ['ptf77blas', 'ptcblas', 'atlas']
library_dirs = ['/usr/local/atlas/lib']
language = c
include_dirs = ['/usr/local/atlas/include']
lapack_opt_info:
libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas']
library_dirs = ['/usr/local/atlas/lib']
define_macros = [('NO_ATLAS_INFO', 2)]
language = f77
include_dirs = ['/usr/local/atlas/include']
lapack_mkl_info:
NOT AVAILABLE
blas_mkl_info:
NOT AVAILABLE
mkl_info:
NOT AVAILABLE
scipy.show_config()
umfpack_info:
NOT AVAILABLE
atlas_threads_info:
libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas']
library_dirs = ['/usr/local/atlas/lib']
language = f77
include_dirs = ['/usr/local/atlas/include']
blas_opt_info:
libraries = ['ptf77blas', 'ptcblas', 'atlas']
library_dirs = ['/usr/local/atlas/lib']
define_macros = [('ATLAS_INFO', '\\3.8.3\\')]
language = c
include_dirs = ['/usr/local/atlas/include']
atlas_blas_threads_info:
libraries = ['ptf77blas', 'ptcblas', 'atlas']
library_dirs = ['/usr/local/atlas/lib']
language = c
include_dirs = ['/usr/local/atlas/include']
lapack_opt_info:
libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas']
library_dirs = ['/usr/local/atlas/lib']
define_macros = [('NO_ATLAS_INFO', 2)]
language = f77
include_dirs = ['/usr/local/atlas/include']
lapack_mkl_info:
NOT AVAILABLE
blas_mkl_info:
NOT AVAILABLE
mkl_info:
NOT AVAILABLE
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
Chris Colbert wrote: Hey Everyone, I built Lapack and Atlas from source last night on a C2D running 32-bit Linux Mint 6. I ran 'make check' and 'make time' on the lapack build, and ran the dynamic LU decomp test on atlas. Both packages checked out fine. Then, I built numpy and scipy against them using the appropriate flags in site.cfg for the parallel thread atlas libraries. This seems to have worked properly as numpy.dot() utilizes both cores at 100% on very large arrays. I have also done id(numpy.dot) and id(numpy.core.multiarray.dot) and verified that the two ids are different. So I believe the build went properly. The problem I am having now is that numpy.linalg.eig (and the eig functions in scipy) hang at 100% CPU and never returns (no matter the array size). Numpy.test() hung as well, I'm assuming for this same reason. I have included the configurations below. Any idea what would cause this? What does numpy.test() returns ? This smells like a fortran runtime problem, cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
numpy.test() doesn't return (after 2 hours of running at 100% at least). I imagine its hanging on this eig function as well. Chris On Fri, Mar 27, 2009 at 10:12 AM, David Cournapeau da...@ar.media.kyoto-u.ac.jp wrote: Chris Colbert wrote: Hey Everyone, I built Lapack and Atlas from source last night on a C2D running 32-bit Linux Mint 6. I ran 'make check' and 'make time' on the lapack build, and ran the dynamic LU decomp test on atlas. Both packages checked out fine. Then, I built numpy and scipy against them using the appropriate flags in site.cfg for the parallel thread atlas libraries. This seems to have worked properly as numpy.dot() utilizes both cores at 100% on very large arrays. I have also done id(numpy.dot) and id(numpy.core.multiarray.dot) and verified that the two ids are different. So I believe the build went properly. The problem I am having now is that numpy.linalg.eig (and the eig functions in scipy) hang at 100% CPU and never returns (no matter the array size). Numpy.test() hung as well, I'm assuming for this same reason. I have included the configurations below. Any idea what would cause this? What does numpy.test() returns ? This smells like a fortran runtime problem, cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
Chris Colbert wrote: numpy.test() doesn't return (after 2 hours of running at 100% at least). I imagine its hanging on this eig function as well. Can you run the following test ? nosetests -v -s test_build.py (in numpy/linalg). If it fails, it almost surely a problem in the way you built numpy and/or atlas. Make sure that everything is built with the same fortran compiler (blas, lapack, atlas and numpy). cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
2009/3/27 Chris Colbert sccolb...@gmail.com Hey Everyone, I built Lapack and Atlas from source last night on a C2D running 32-bit Linux Mint 6. I ran 'make check' and 'make time' on the lapack build, and ran the dynamic LU decomp test on atlas. Both packages checked out fine. Then, I built numpy and scipy against them using the appropriate flags in site.cfg for the parallel thread atlas libraries. This seems to have worked properly as numpy.dot() utilizes both cores at 100% on very large arrays. I have also done id(numpy.dot) and id(numpy.core.multiarray.dot) and verified that the two ids are different. So I believe the build went properly. The problem I am having now is that numpy.linalg.eig (and the eig functions in scipy) hang at 100% CPU and never returns (no matter the array size). Numpy.test() hung as well, I'm assuming for this same reason. I have included the configurations below. Any idea what would cause this? This is a problem that used to turn up regularly and was related to the atlas build. The atlas version can matter here, but I don't know what the currently recommended atlas version is. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
here are the results from that test: test_lapack (test_build.TestF77Mismatch) ... ok -- Ran 1 test in 0.055s OK thanks again for the help, Chris On Fri, Mar 27, 2009 at 10:24 AM, David Cournapeau da...@ar.media.kyoto-u.ac.jp wrote: Chris Colbert wrote: numpy.test() doesn't return (after 2 hours of running at 100% at least). I imagine its hanging on this eig function as well. Can you run the following test ? nosetests -v -s test_build.py (in numpy/linalg). If it fails, it almost surely a problem in the way you built numpy and/or atlas. Make sure that everything is built with the same fortran compiler (blas, lapack, atlas and numpy). cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
I compiled everything with gfortran. I dont even have g77 on my system. On Fri, Mar 27, 2009 at 11:18 AM, Chris Colbert sccolb...@gmail.com wrote: here are the results from that test: test_lapack (test_build.TestF77Mismatch) ... ok -- Ran 1 test in 0.055s OK thanks again for the help, Chris On Fri, Mar 27, 2009 at 10:24 AM, David Cournapeau da...@ar.media.kyoto-u.ac.jp wrote: Chris Colbert wrote: numpy.test() doesn't return (after 2 hours of running at 100% at least). I imagine its hanging on this eig function as well. Can you run the following test ? nosetests -v -s test_build.py (in numpy/linalg). If it fails, it almost surely a problem in the way you built numpy and/or atlas. Make sure that everything is built with the same fortran compiler (blas, lapack, atlas and numpy). cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
I built Atlas 3.8.3 which I assume is the newest release. Chris 2009/3/27 Charles R Harris charlesr.har...@gmail.com 2009/3/27 Chris Colbert sccolb...@gmail.com Hey Everyone, I built Lapack and Atlas from source last night on a C2D running 32-bit Linux Mint 6. I ran 'make check' and 'make time' on the lapack build, and ran the dynamic LU decomp test on atlas. Both packages checked out fine. Then, I built numpy and scipy against them using the appropriate flags in site.cfg for the parallel thread atlas libraries. This seems to have worked properly as numpy.dot() utilizes both cores at 100% on very large arrays. I have also done id(numpy.dot) and id(numpy.core.multiarray.dot) and verified that the two ids are different. So I believe the build went properly. The problem I am having now is that numpy.linalg.eig (and the eig functions in scipy) hang at 100% CPU and never returns (no matter the array size). Numpy.test() hung as well, I'm assuming for this same reason. I have included the configurations below. Any idea what would cause this? This is a problem that used to turn up regularly and was related to the atlas build. The atlas version can matter here, but I don't know what the currently recommended atlas version is. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
Atlas 3.8.3 and Lapack 3.1.1 On Fri, Mar 27, 2009 at 11:05 AM, David Cournapeau da...@ar.media.kyoto-u.ac.jp wrote: Chris Colbert wrote: I compiled everything with gfortran. I dont even have g77 on my system. Ok. Which version of atlas and lapack are you using ? Lapack 3.2 is known to cause trouble. Atlas 3.8.0 and 3.8.1 had some bugs too, I can't remember exactly which one. cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
Chris Colbert wrote: Atlas 3.8.3 and Lapack 3.1.1 Hm... I am afraid I don't see what may cause this problem. Could you rebuild numpy from scratch and give us the log ? rm -rf build python setup.py build build.log David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
David, The log was too big for the list, so I sent it to your email address directly. Chris 2009/3/27 Chris Colbert sccolb...@gmail.com David, The log is attached. Thanks for giving me the bash command. I would have never figured that one out Chris On Fri, Mar 27, 2009 at 11:23 AM, David Cournapeau da...@ar.media.kyoto-u.ac.jp wrote: Chris Colbert wrote: Atlas 3.8.3 and Lapack 3.1.1 Hm... I am afraid I don't see what may cause this problem. Could you rebuild numpy from scratch and give us the log ? rm -rf build python setup.py build build.log David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
Chris Colbert wrote: David, The log was too big for the list, so I sent it to your email address directly. Hm, never saw this one. In the build log, one can see: ... compile options: '-c' gcc: _configtest.c gcc -pthread _configtest.o -L/usr/local/atlas/lib -llapack -lptf77blas -lptcblas -latlas -o _configtest /usr/bin/ld: _configtest: hidden symbol `__powidf2' in /usr/lib/gcc/i486-linux-gnu/4.3.2/libgcc.a(_powidf2.o) is referenced by DSO /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status /usr/bin/ld: _configtest: hidden symbol `__powidf2' in /usr/lib/gcc/i486-linux-gnu/4.3.2/libgcc.a(_powidf2.o) is referenced by DSO /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status failure. This does not look good. It may be a problem in your toolchain (i.e. how your distribution build gcc and co). I am afraid there is not much we can do at this point - you should report the problem to your OS vendor, hoping someone knows about this, cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
So you think its a problem with gcc? im using version 4.3.1 shipped with the ubuntu 8.10 distro. Chris On Fri, Mar 27, 2009 at 11:56 AM, David Cournapeau da...@ar.media.kyoto-u.ac.jp wrote: Chris Colbert wrote: David, The log was too big for the list, so I sent it to your email address directly. Hm, never saw this one. In the build log, one can see: ... compile options: '-c' gcc: _configtest.c gcc -pthread _configtest.o -L/usr/local/atlas/lib -llapack -lptf77blas -lptcblas -latlas -o _configtest /usr/bin/ld: _configtest: hidden symbol `__powidf2' in /usr/lib/gcc/i486-linux-gnu/4.3.2/libgcc.a(_powidf2.o) is referenced by DSO /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status /usr/bin/ld: _configtest: hidden symbol `__powidf2' in /usr/lib/gcc/i486-linux-gnu/4.3.2/libgcc.a(_powidf2.o) is referenced by DSO /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status failure. This does not look good. It may be a problem in your toolchain (i.e. how your distribution build gcc and co). I am afraid there is not much we can do at this point - you should report the problem to your OS vendor, hoping someone knows about this, cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
Chris Colbert wrote: So you think its a problem with gcc? That's my guess, yes. im using version 4.3.1 shipped with the ubuntu 8.10 distro. I thought you were using mint ? If you are using ubuntu, then it is very strange, because many people build and use numpy on this platform without any trouble. Is your OS 64 bits ? cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
mint is built from like 98% ubuntu. In this case, Mint 6 is built from ubuntu 8.10. Most repository access is through the Ubuntu repositories. gcc falls under this... 32 bit OS Thanks again for your patience! I'm wet behind the ears when it comes to this kind of stuff. Chris On Fri, Mar 27, 2009 at 12:05 PM, David Cournapeau da...@ar.media.kyoto-u.ac.jp wrote: Chris Colbert wrote: So you think its a problem with gcc? That's my guess, yes. im using version 4.3.1 shipped with the ubuntu 8.10 distro. I thought you were using mint ? If you are using ubuntu, then it is very strange, because many people build and use numpy on this platform without any trouble. Is your OS 64 bits ? cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
2009/3/28 Chris Colbert sccolb...@gmail.com: mint is built from like 98% ubuntu. Ok. The problem is that fortran often falls into the bottom percent as far as support is concerned, since so few people care :) Note that on Ubuntu 8.10, you can just install atlas from the repositories - and 1.3.0 deb will be provided once it is released cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
forgive my ignorance, but wouldn't installing atlas from the repositories defeat the purpose of installing atlas at all, since the build process optimizes it to your own cpu timings? Chris On Fri, Mar 27, 2009 at 12:43 PM, David Cournapeau courn...@gmail.comwrote: 2009/3/28 Chris Colbert sccolb...@gmail.com: mint is built from like 98% ubuntu. Ok. The problem is that fortran often falls into the bottom percent as far as support is concerned, since so few people care :) Note that on Ubuntu 8.10, you can just install atlas from the repositories - and 1.3.0 deb will be provided once it is released cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
Chris Colbert wrote: forgive my ignorance, but wouldn't installing atlas from the repositories defeat the purpose of installing atlas at all, since the build process optimizes it to your own cpu timings? Yes and no. Yes, it will be slower than a cutom-build atlas, but it will be reasonably faster than blas/lapack. Please also keep in mind that this mostly matters for linear algebra and big matrices. Thinking from another POV: how many 1000x1000 matrices could have you inverted while wasting your time on this already :) cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
this is true. but not nearly as good of a learning experience :) I'm a mechanical engineer, so all of this computer science stuff is really new and interesting to me. So i'm trying my best to get a handle on exactly what is going on behind the scenes. Chris On Fri, Mar 27, 2009 at 12:36 PM, David Cournapeau da...@ar.media.kyoto-u.ac.jp wrote: Chris Colbert wrote: forgive my ignorance, but wouldn't installing atlas from the repositories defeat the purpose of installing atlas at all, since the build process optimizes it to your own cpu timings? Yes and no. Yes, it will be slower than a cutom-build atlas, but it will be reasonably faster than blas/lapack. Please also keep in mind that this mostly matters for linear algebra and big matrices. Thinking from another POV: how many 1000x1000 matrices could have you inverted while wasting your time on this already :) cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
some other things I might mention, though I doubt they would have an effect: When i built Atlas, I had to force it to use a 32-bit pointer length (I assume this is correct for a 32-bit OS as gcc.stub_64 wasnt found on my system) in numpy's site.cfg I only linked to the pthread .so's. Should I have also linked to the single threaded counterparts in the section above? (I assumed one would be overridden by the other) Other than those, I followed closely the instructions on scipy.org. Chris On Fri, Mar 27, 2009 at 12:57 PM, Chris Colbert sccolb...@gmail.com wrote: this is true. but not nearly as good of a learning experience :) I'm a mechanical engineer, so all of this computer science stuff is really new and interesting to me. So i'm trying my best to get a handle on exactly what is going on behind the scenes. Chris On Fri, Mar 27, 2009 at 12:36 PM, David Cournapeau da...@ar.media.kyoto-u.ac.jp wrote: Chris Colbert wrote: forgive my ignorance, but wouldn't installing atlas from the repositories defeat the purpose of installing atlas at all, since the build process optimizes it to your own cpu timings? Yes and no. Yes, it will be slower than a cutom-build atlas, but it will be reasonably faster than blas/lapack. Please also keep in mind that this mostly matters for linear algebra and big matrices. Thinking from another POV: how many 1000x1000 matrices could have you inverted while wasting your time on this already :) cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
Ok, im getting the same error on an install of straight ubuntu 8.10 the guy in this thread got the same error as me, but its not clear how he worked it out: http://www.mail-archive.com/numpy-discussion@scipy.org/msg13565.html from googling here: http://sources.redhat.com/ml/binutils/2004-12/msg00033.html it says that the library was not built correctly. does this mean my atlas .so's (which i built via - make ptshared) are incorrect? I suppose I could just grab atlas from the repositories, but that would be admitting defeat. Chris On Fri, Mar 27, 2009 at 1:09 PM, Chris Colbert sccolb...@gmail.com wrote: some other things I might mention, though I doubt they would have an effect: When i built Atlas, I had to force it to use a 32-bit pointer length (I assume this is correct for a 32-bit OS as gcc.stub_64 wasnt found on my system) in numpy's site.cfg I only linked to the pthread .so's. Should I have also linked to the single threaded counterparts in the section above? (I assumed one would be overridden by the other) Other than those, I followed closely the instructions on scipy.org. Chris On Fri, Mar 27, 2009 at 12:57 PM, Chris Colbert sccolb...@gmail.comwrote: this is true. but not nearly as good of a learning experience :) I'm a mechanical engineer, so all of this computer science stuff is really new and interesting to me. So i'm trying my best to get a handle on exactly what is going on behind the scenes. Chris On Fri, Mar 27, 2009 at 12:36 PM, David Cournapeau da...@ar.media.kyoto-u.ac.jp wrote: Chris Colbert wrote: forgive my ignorance, but wouldn't installing atlas from the repositories defeat the purpose of installing atlas at all, since the build process optimizes it to your own cpu timings? Yes and no. Yes, it will be slower than a cutom-build atlas, but it will be reasonably faster than blas/lapack. Please also keep in mind that this mostly matters for linear algebra and big matrices. Thinking from another POV: how many 1000x1000 matrices could have you inverted while wasting your time on this already :) cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Built Lapack, Atlas from source.... now numpy.linalg.eig() hangs at 100% CPU
Alright, building numpy against atlas from the repositories works, but this atlas only contains the single threaded libraries. So i would like to get my build working completely. I think the problem has to do with how im making the atlas .so's from the .a files. I am simply calling the command 'make ptshared' in the atlas lib directory. The LDFLAGS of that particular makefile is set to '-melf_i386'. I have no idea what this means, the only thing I know is that LDFLAGS has something to do with linking, and from what I read on google, the error I am getting is do to improperly created .so files. I've attached both makefiles to this message, if anyone could take a look and see if something obvious is amiss. Thanks, Chris On Fri, Mar 27, 2009 at 10:32 PM, Chris Colbert sccolb...@gmail.com wrote: Ok, im getting the same error on an install of straight ubuntu 8.10 the guy in this thread got the same error as me, but its not clear how he worked it out: http://www.mail-archive.com/numpy-discussion@scipy.org/msg13565.html from googling here: http://sources.redhat.com/ml/binutils/2004-12/msg00033.html it says that the library was not built correctly. does this mean my atlas .so's (which i built via - make ptshared) are incorrect? I suppose I could just grab atlas from the repositories, but that would be admitting defeat. Chris On Fri, Mar 27, 2009 at 1:09 PM, Chris Colbert sccolb...@gmail.comwrote: some other things I might mention, though I doubt they would have an effect: When i built Atlas, I had to force it to use a 32-bit pointer length (I assume this is correct for a 32-bit OS as gcc.stub_64 wasnt found on my system) in numpy's site.cfg I only linked to the pthread .so's. Should I have also linked to the single threaded counterparts in the section above? (I assumed one would be overridden by the other) Other than those, I followed closely the instructions on scipy.org. Chris On Fri, Mar 27, 2009 at 12:57 PM, Chris Colbert sccolb...@gmail.comwrote: this is true. but not nearly as good of a learning experience :) I'm a mechanical engineer, so all of this computer science stuff is really new and interesting to me. So i'm trying my best to get a handle on exactly what is going on behind the scenes. Chris On Fri, Mar 27, 2009 at 12:36 PM, David Cournapeau da...@ar.media.kyoto-u.ac.jp wrote: Chris Colbert wrote: forgive my ignorance, but wouldn't installing atlas from the repositories defeat the purpose of installing atlas at all, since the build process optimizes it to your own cpu timings? Yes and no. Yes, it will be slower than a cutom-build atlas, but it will be reasonably faster than blas/lapack. Please also keep in mind that this mostly matters for linear algebra and big matrices. Thinking from another POV: how many 1000x1000 matrices could have you inverted while wasting your time on this already :) cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion Makefile Description: Binary data Make.inc Description: Binary data ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
