[Numpy-discussion] Specifying compiler command line options for numpy.disutils.core

[David Cournapeau]

Matthieu Brucher wrote:
>
>     I think the default for the standard python distutils is to use the
>     compiler and the compiler settings for the C compiler that were
>     used to
>     build Python itself. There might be ways to specify other
>     compilers; but
>     if you have a shared python library build with one compiler and
>     modules
>     build with another you might run into trouble if the two compilers
>     use
>     different system libraries which are not resolved by standard python
>     build.
>
>
>
> Well, the Intel compiler uses the same libraries than gcc on Linux, 
> and on Windows, I don't know, but it is possible to mix VS2003 and 
> VS2005, whuch is forbidden by the distutils, so I find this too 
> restricting although understandable.
It is possible to mix object code, but not runtime, which is the problem 
AFAIK. VS2003 and VS2005 have different  C runtimes (msvcrt7.1.dll 
against msvcrt8.dll). The problem is (at least for me, who just go 
through the pain for windows users :) ) that VS2003 is not available 
anymore for free...
>  
>
>     I believe that numpy is similar in the sense that you can always build
>     additional modules with the compilers that were used to build the
>     numpy
>     core; then, using two fortran based modules (say) will work well
>     because
>     both require the same shared system libraries of the compiler.
>     Probably,
>     the  compiler options used to build numpy will also work for your
>     additinal modules (with respect to paths to linear algebra
>     libraries and
>     so on).
>
>
>
> No, in this case, I want to build with icc and special compiler 
> options. I tried by build by hand - and CMake - the libraries, it 
> works like a charm and it is very very fast compared to gcc :(
Which libraries are you talking about ? Also, beware that ICC uses by 
default some flags which are potentially dangerous (I don't know if this 
is true anymore, but ICC used to use the equivalent of --ffast-math of 
gcc by default: 
http://david.monniaux.free.fr/dotclear/index.php/2006/03/17/4-l-art-de-calculer-le-minimum-de-deux-nombres). 
For libraries like atlas, I don't think there will be a huge difference 
between ICC and gcc; if you use the mkl, then you don't care :)
>  
>
>     Again, I think there could be ways to build with different
>     compilers, but
>     you do run the risk of incompatibilities with the shared libraries.
>     Therefore, I have become used to build python with the C-compiler kI'd
>     like to use, even if that means a lot of work.
>
>  
>
> This would mean building every other modules added - numpy, scipy, 
> matplotlib, wxPython, ... -, doable, but I'd prefer not to do it, but 
> if it is not possible, I would have to live with it...
I think it is important to separate different issues: object code 
compatibility, runtime compatibility, etc... Those are different issues. 
First, mixing ICC compiled code and gcc code *has* to be possible (I 
have never tried), otherwise, I don't see much use for it under linux. 
Then you have the problem of runtime services: I really doubt that ICC 
runtime is not compatible with gcc, and more globally with the GNU 
runtime (glibc, etc...); actually, ICC used to use the "standard" linux 
runtime, and I would be surprised if that changed.

To say it simply: on linux at least, what should matter is whether the 
runtime services are compatible (on windows, it looks like they are not: 
official python is compiled with visual studio 2003, and you cannot use 
VS 2005; note that mingw seems to work).

David