[SciPy-dev] Compiling scipy with Intel ifort & MKL

[Pearu Peterson]

rex wrote:
> rex <rex at nosyntax.com> [2007-06-11 16:12]:
>> Pearu Peterson <pearu at cens.ioc.ee> [2007-06-11 15:12]:
>>> It is due to a bug in numpy introduced, I think, just before releasing 
>>> 1.0.3. It has been fixed in numpy svn. 
>> Thank you! Building numpy from svn did eliminate the "error: file
>> 'dfftpack/*.f' does not exist" message when building scipy, and the
>> scipy compilation proceeded much further. However, it still produces an
>> error which appears to be due to a failure to recognize the ID of ifort
>> 10.
>>
>> I've already had to fix one problem in distutils due to Intel changing
>> 'mkl_lapack32' in MKL8.1 to 'mkl_lapack' in MKL9.1. It appears another
>> change is needed, perhaps in numpy/distutils/fcompiler/intel.py
> 
> I don't understand the distutils/* code well enough to fix it, but it
> appears that the problem is triggered by packages that cause:
> 
> library 'mach' defined more than once, overwriting build_info {'sources': ['Lib/integrate/mach/i1mach.f', 'Lib/integrate/mach/d1mach.f', 'Lib/integrate/mach/r1mach.f', 'Lib/integrate/mach/xerror.f'], 'config_fc': {'noopt': ('Lib/integrate/setup.pyc', 1)}, 'source_languages': ['f77']} with {'sources': ['Lib/special/mach/i1mach.f', 'Lib/special/mach/d1mach.f', 'Lib/special/mach/r1mach.f', 'Lib/special/mach/xerror.f'], 'config_fc': {'noopt': ('Lib/special/setup.pyc', 1)}, 'source_languages': ['f77']}.
> extending extension 'scipy.linsolve._zsuperlu' defined_macros with [('USE_VENDOR_BLAS', 1)]

I think this is irrelevant.

> 
> This results in an error:
> 
> [...]
> customize IntelCCompiler
> customize IntelCCompiler using build_ext
> Traceback (most recent call last):
>   File "setup.py", line 55, in <module>
>     setup_package()
>   File "setup.py", line 47, in setup_package
>     configuration=configuration )
>   File "/usr/local/lib/python2.5/site-packages/numpy/distutils/core.py", line 176, in setup
>     return old_setup(**new_attr)
>   File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
>     dist.run_commands()
>   File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
>     self.run_command(cmd)
>   File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
>     cmd_obj.run()
>   File "/usr/lib/python2.5/distutils/command/build.py", line 112, in run
>     self.run_command(cmd_name)
>   File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command
>     self.distribution.run_command(command)
>   File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
>     cmd_obj.run()
>   File "/usr/local/lib/python2.5/site-packages/numpy/distutils/command/build_ext.py", line 181, in run
>     if fcompiler and fcompiler.get_version():
>   File "/usr/local/lib/python2.5/site-packages/numpy/distutils/ccompiler.py", line 265, in CCompiler_get_version
>     cmd = ' '.join(version_cmd)
> TypeError: sequence item 1: expected string, NoneType found
> 
> I determined this by the brute force method of deleting the current .f file
> that triggered the problem. The result was another .f file causing the
> same problem, leading to my conclusion that something in distutils/* is
> broken for the v10 Intel compilers. (I've already verified and fixed a
> problem in distutils/* re v9.1 MKL).

The Fortran compiler version checking code (among others related codes) 
in numpy.distutils has changed after merging David Cooke branch with
numpy trunk. It appears that the new code is not well tested. 
Unfortunately I don't have intel compiler in my system to track down
the problems you experince. I may get a chance to look at it in more 
detail may be on Friday.

Pearu