[SciPy-dev] {Num, Sci}Py on 64bit Intel Macs with icc, ifort, mkl

David Cournapeau david@ar.media.kyoto-u.ac...
Wed Jun 11 12:16:13 CDT 2008

Ulrik Günther wrote:
> The problem is, when compiling/linking, for example, multiarray.so, 
> the compiler spits
> out many not found symbols, primarily due to not appending -framework 
> Python to the
> compiling options. The problem can be solved be manually compiling the 
> file, while appending
> the respective option (along with -undefined dynamic_lookup, as _main 
> is not found else, which
> may also be a Fortran-compiler related problem, so maybe -no-formain 
> for the ifort is more
> appropriate than using dynamic lookups...)

-undefined dynamic_lookup tells the apple linker to succeed even if some 
symbols are missing. But that should be handled by distutils, actually 
(or maybe distutils does not know about icc on the mac ?)

> Could you please tell me what I need now for using the SCons branch? 
> Updating my old version
> via svn up didn't work, so the first thing I thought was that it has 
> been discontinued. I'm very
> glad to hear that this is not the case. If I manage to get a working 
> build on my configuration,
> may I direct to patches to you?

Before, scons support was a separate branch, but now, it is integrated 
in both numpy and scipy trunk (even in the source tarball for numpy 
starting at 1.1.0).

scons support has two sides:
    - numpy/scipy side: just some hooks to call scons, as well as the 
scons scripts themselves.
    - numscons: it implements everything to build python extensions, 
check for blas/lapack/co, fortran capabilities, etc...

So you need sources (from the trunk for scipy), and numscons, which 
development happens on launchpad (code, bugs, patches, and co):


If you want to look at the code, and hack on it, I would suggest to get 
the sources with bzr:

bzr branch lp:numpy.scons.support/trunk

You can then send your changes to launchpad, which will handle the merge 
requests (for review).

Unfortunately, I have to confess the code for performance libraries 
checkers is still pretty bad (it is clearly over-designed, and the 
simple concepts are still struggling to get out: there are way too many 
classes over there). There are some things which are better than 
distutils IMHO; in particular, all the checkers use the same code (which 
is one reason why the actual code is so convoluted for now), and the 
basic options for each library are in configuration files, not in code 

That's a part of the code which definitely needs some cleaning and 



More information about the Scipy-dev mailing list