Re: [Numpy-discussion] building numpy/scipy
On Sat, Jan 3, 2009 at 1:07 AM, Mike Landis
Cygwin is present, so not just the dumbed down Windows CMD available.
I ran the numpy-1.2.1 superpak. Verified that it installed (cause you don't get near as much output as you do from a shell prompt) by running:
"
python -c 'import numpy; print numpy.__version__ '
"
and got the numpy version number back. Found the site.cfg that the installer left in the numpy package directory (it picked up on my ATLAS install, but not on MKL) and copied it into d:\temp\scipy-0.7.0b1 and ran "python setup.py install" there. Lots of positive looking output, but it ultimately crapped out. Here's the tail end of that transcript:
copying scipy\weave\__init__.py -> build\lib.win32-2.5\scipy\weave running build_clib Traceback (most recent call last): File "setup.py", line 92, in <module> setup_package() File "setup.py", line 84, in setup_package configuration=configuration ) File "d:\Programs\Python25\lib\site-packages\numpy\distutils\core.py", line 184, in setup return old_setup(**new_attr) File "d:\programs\python25\lib\distutils\core.py", line 151, in setup dist.run_commands() File "d:\programs\python25\lib\distutils\dist.py", line 974, in run_commands self.run_command(cmd) File "d:\programs\python25\lib\distutils\dist.py", line 994, in run_command cmd_obj.run() File "d:\Programs\Python25\lib\site-packages\numpy\distutils\command\install.py", line 49, in run r = old_install.run(self) File "d:\programs\python25\lib\distutils\command\install.py", line 506, in run self.run_command('build') File "d:\programs\python25\lib\distutils\cmd.py", line 333, in run_command self.distribution.run_command(command) File "d:\programs\python25\lib\distutils\dist.py", line 994, in run_command cmd_obj.run() File "d:\Programs\Python25\lib\site-packages\numpy\distutils\command\build.py", line 37, in run old_build.run(self) File "d:\programs\python25\lib\distutils\command\build.py", line 112, in run self.run_command(cmd_name) File "d:\programs\python25\lib\distutils\cmd.py", line 333, in run_command self.distribution.run_command(command) File "d:\programs\python25\lib\distutils\dist.py", line 994, in run_command cmd_obj.run() File "d:\Programs\Python25\lib\site-packages\numpy\distutils\command\build_clib.py", line 63, in run force=self.force) File "d:\Programs\Python25\lib\site-packages\numpy\distutils\ccompiler.py", line 366, in new_compiler compiler = klass(None, dry_run, force) File "d:\Programs\Python25\lib\site-packages\numpy\distutils\mingw32ccompiler.py", line 46, in __init__ verbose,dry_run, force) File "d:\programs\python25\lib\distutils\cygwinccompiler.py", line 84, in __init__ get_versions() File "d:\programs\python25\lib\distutils\cygwinccompiler.py", line 424, in get_versions ld_version = StrictVersion(result.group(1)) File "d:\programs\python25\lib\distutils\version.py", line 40, in __init__ self.parse(vstring) File "d:\programs\python25\lib\distutils\version.py", line 107, in parse raise ValueError, "invalid version number '%s'" % vstring ValueError: invalid version number '2.18.50.20080625'
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
If you want to get around this bug, you could correct the version parsing, change in File "d:\programs\python25\lib\distutils\cygwinccompiler.py", line 424, in
get_versions ld_version = StrictVersion(result.group(1))
to ld_version = StrictVersion(result.group(1).rsplit('.',1)[0]) see version problem
from distutils.version import StrictVersion StrictVersion('2.18.50.20080625') Traceback (most recent call last): File "
", line 1, in <module> StrictVersion('2.18.50.20080625') File "C:\Programs\Python25\lib\distutils\version.py", line 40, in __init__ self.parse(vstring) File "C:\Programs\Python25\lib\distutils\version.py", line 107, in parse raise ValueError, "invalid version number '%s'" % vstring ValueError: invalid version number '2.18.50.20080625' StrictVersion('2.18.50.20080625'.rsplit('.',1)[0]) StrictVersion ('2.18.50')
But, see my other message, try without cygwin. I usually don't have any problems building scipy with mingw. Josef
Mike Landis wrote:
Cygwin is present, so not just the dumbed down Windows CMD available.
You should not use cygwin: if you use cygwin, it will build numpy against the cygwin python, or worse, will be very confused, because you will mix cygwin compilers and mingw compilers. Unless you want to build numpy for cygwin python, you should not try anything from cygwin. Not that it is impossible, but there are many warts to avoid, and it does not worth the pain unless you are a numpy developer.
I ran the numpy-1.2.1 superpak. Verified that it installed (cause you don't get near as much output as you do from a shell prompt) by running:
" python -c 'import numpy; print numpy.__version__ ' "
See, it is easier :)
and got the numpy version number back. Found the site.cfg that the installer left in the numpy package directory (it picked up on my ATLAS install, but not on MKL) and copied it into d:\temp\scipy-0.7.0b1 and ran "python setup.py install" there.
This will not work: you need blas/lapack for scipy - the site.cfg in installed numpy refers to a blas/lapack which was used when I built the binary installer - and it not installed (blas/lapack is statically linked, as dynamically linked libraries is too difficult on windows). Please install from the scipy binary installer instead: http://sourceforge.net/project/showfiles.php?group_id=27747 Trust me, it will take you less time.
Lots of positive looking output, but it ultimately crapped out. Here's the tail end of that transcript:
Same python bug as before: the problem is that for some reason, python checks the version of your toolchain (here binutils), and refuses to build when the version is not the one expected. The easiest fix is to follow Joseph suggestion. But again, you need a blas/lapack first. David
participants (3)
-
David Cournapeau
-
josef.pktd@gmail.com
-
Mike Landis