[SciPy-user] SciPy-user Digest, Vol 31, Issue 8

[Paul Ray]

Hi,

Thanks for all the replies on my 64 bit questions.  I'll compile  
several questions from different people into one reply to save list  
clutter...

pierregm wrote:
> But I'm surprised you have some 32b libraries in /usr/lib. Don't  
> you have
> a /usr/lib32 in parallel to /usr/lib64, with lib pointing to lib64  
> only ? I
> remmbr having the same problem with SuSE (the reason why I switched to
> Gentoo). What are the libraries being accessed, in fact ?

My machine has a /usr/lib and a /usr/lib64.  The blas contained in  
each is:
 > file /usr/lib64/libblas.so.3.0.3
/usr/lib64/libblas.so.3.0.3: ELF 64-bit LSB shared object, AMD  
x86-64, version 1 (SYSV), stripped
 > file /usr/lib/libblas.so.3.0.3
/usr/lib/libblas.so.3.0.3: ELF 32-bit LSB shared object, Intel 80386,  
version 1 (SYSV), stripped

mfmorss asked:
> Let me ask you this:  do you have Python itself built in 64 bit?   
> When I
> tried that here on my AIX server, I could not get the datetime  
> module to
> build.

Here is the answer:
 > file /usr/local/bin/python2.4
/usr/local/bin/python2.4: ELF 64-bit LSB executable, AMD x86-64,  
version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses  
shared libs), not stripped

George Nurser asked:
> I managed to get numpy/scipy/matplotlib set up on a single core (SUN)
> Opteron running a similar RedHat
> uname -a
> Linux nohow 2.6.9-22.0.2.EL #1 Thu Jan 5 17:03:08 EST 2006 x86_64
> x86_64 x86_64 GNU/Linux
> (BTW - was the uname -a issued last summer, or is your clock wrong:)
I just issued the uname -a command.  Isn't the date the build date of  
the kernel or something like that?

The link problem we are having now is the undefined symbol "srotmg_"  
which is a sign of an incomplete blas/lapack distribution that came  
with the OS, I believe.  How can I tell setup.py to NOT search for  
external blas/lapack and just use its own internal implementation  
(since we don't care at all about linalg performance)?

Also, using the profiler, it appears that fft's are still being done  
by the internal fft engine, instead of FFTW3, despite the fact that  
SciPy thinks it found FFTW:
scipy.show_config() gives the following:
fft_opt_info:
     libraries = ['fftw3']
     library_dirs = ['/usr/local/lib']
     define_macros = [('SCIPY_FFTW3_H', None)]
     include_dirs = ['/usr/local/include']

atlas_blas_threads_info:
   NOT AVAILABLE

djbfft_info:
   NOT AVAILABLE

fftw3_info:
     libraries = ['fftw3']
     library_dirs = ['/usr/local/lib']
     define_macros = [('SCIPY_FFTW3_H', None)]
     include_dirs = ['/usr/local/include']

Is there any way to positively confirm that FFTW3 is actually getting  
called?

Thanks,

-- Paul

--
Dr. Paul S. Ray              E-mail: Paul.Ray at nrl.navy.mil
Naval Research Laboratory    WWW   : http://xweb.nrl.navy.mil/ 
personnel/paulr/
Code 7655                    Phone : (202) 404-1619
Washington, DC 20375         AIM   : NRLPSR