Menu
▾
▴
numpy-discussion
|
From: Tim H. <tim...@co...> - 2006-02-04 03:24:11
|
Hi I recently installed the Visual Studio .NET 2003 (AKA VC7) compiler
and I took a stab at compiling numpy. I've tried previously with the
free, toolkit version of VC7 with little success, but I was hoping this
would be a piece of cake. No joy!
It's quite possible that my compiler setup is gummed up by the previous
existence of the toolkit compiler. A bunch of paths were set to this and
that and there may be some residue that is messing things up. However I
successfully compiled numarray 1.5 and a couple of my own extensions so
things *seem* OK. So before I go hunting, I thought I'd ask and see if
there were some known issues with compiling numpy 0.9.4 with VC7.
The symptoms I'm seeing are, first, that it can't run configure. It
can't find python24.lib. An abbreviated traceback is shown at the
bottom. I kludged my way past this by replacing line 33 of
numpy/core/setup.py with the two lines:
python_lib = sysconfig.EXEC_PREFIX + '/libs'
result =
config_cmd.try_run(tc,include_dirs=[python_include],library_dirs=[python_lib])
That got me a little farther, but I quickly ran into trouble compiling
multiarray module:
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c
/nologo /Ox /MD /W3 /GX /DNDEBU
G -Ibuild\src\numpy\core\src -Inumpy\core\include -Ibuild\src\numpy\core
-Inumpy\core\src -Inumpy\li
b\..\core\include -IC:\Python24\include -IC:\Python24\PC
/Tcnumpy\core\src\multiarraymodule.c /Fobui
ld\temp.win32-2.4\Release\numpy\core\src\multiarraymodule.obj
multiarraymodule.c
build\src\numpy\core\src\arraytypes.inc(5305) : error C2036: 'void *' :
unknown size
build\src\numpy\core\src\arraytypes.inc(5885) : error C2036: 'void *' :
unknown size
build\src\numpy\core\src\arraytypes.inc(6465) : error C2036: 'void *' :
unknown size
...a bunch of warnings...
c:\Documents and
Settings\End-user\Desktop\numpy\numpy-0.9.4\numpy\core\src\arrayobject.c(4049)
: er
ror C2036: 'void *' : unknown size
...some more warnings...
error: Command ""C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\bin\cl.exe" /c /nologo /Ox /
MD /W3 /GX /DNDEBUG -Ibuild\src\numpy\core\src -Inumpy\core\include
-Ibuild\src\numpy\core -Inumpy\c
ore\src -Inumpy\lib\..\core\include -IC:\Python24\include
-IC:\Python24\PC /Tcnumpy\core\src\multiar
raymodule.c
/Fobuild\temp.win32-2.4\Release\numpy\core\src\multiarraymodule.obj"
failed with exit st
atus 2
Anyway, like I said, my compiler could be broken, but if there is a
known issue with VC7 or this rings a bell with anyone please let me
know. I certainly wouldn't mind a hint.
-tim
Traceback from configure failure:
-----------------------------------------------------------------------------------------------------------------------
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c
/nologo /Ox /MD /W3 /GX /DNDEBU
G -IC:\Python24\include -Inumpy\core\src -Inumpy\lib\..\core\include
-IC:\Python24\include -IC:\Pyth
on24\PC /Tc_configtest.c /Fo_configtest.obj
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\link.exe
/nologo /INCREMENTAL:NO _configt
est.obj /OUT:_configtest.exe
LINK : fatal error LNK1104: cannot open file 'python24.lib'
failure.
removing: _configtest.c _configtest.obj
Traceback (most recent call last):
File "C:\Documents and
Settings\End-user\Desktop\numpy\numpy-0.9.4\setup.py", line 73, in ?
setup_package()
File "C:\Documents and
Settings\End-user\Desktop\numpy\numpy-0.9.4\setup.py", line 66, in setup_pa
ckage
setup( **config.todict() )
File "C:\Documents and
Settings\End-user\Desktop\numpy\numpy-0.9.4\numpy\distutils\core.py", line
93, in setup
return old_setup(**new_attr)
File "C:\Python24\lib\distutils\core.py", line 149, in setup
dist.run_commands()
File "C:\Python24\lib\distutils\dist.py", line 946, in run_commands
self.run_command(cmd)
File "C:\Python24\lib\distutils\dist.py", line 966, in run_command
cmd_obj.run()
File "C:\Python24\lib\distutils\command\build.py", line 112, in run
self.run_command(cmd_name)
File "C:\Python24\lib\distutils\cmd.py", line 333, in run_command
self.distribution.run_command(command)
File "C:\Python24\lib\distutils\dist.py", line 966, in run_command
cmd_obj.run()
File "C:\Documents and
Settings\End-user\Desktop\numpy\numpy-0.9.4\numpy\distutils\command\build_s
rc.py", line 86, in run
self.build_sources()
File "C:\Documents and
Settings\End-user\Desktop\numpy\numpy-0.9.4\numpy\distutils\command\build_s
rc.py", line 99, in build_sources
self.build_extension_sources(ext)
File "C:\Documents and
Settings\End-user\Desktop\numpy\numpy-0.9.4\numpy\distutils\command\build_s
rc.py", line 143, in build_extension_sources
sources = self.generate_sources(sources, ext)
File "C:\Documents and
Settings\End-user\Desktop\numpy\numpy-0.9.4\numpy\distutils\command\build_s
rc.py", line 199, in generate_sources
source = func(extension, build_dir)
File "numpy\core\setup.py", line 35, in generate_config_h
raise "ERROR: Failed to test configuration"
ERROR: Failed to test configuration
-----------------------------------------------------------------------------------------------------------------------
|
|
From: Travis O. <oli...@ie...> - 2006-02-07 04:03:17
|
Tim Hochberg wrote: > > Just a little update on this: > > It appears that all (or almost all) of the checks in generate_config_h > must be failing. I would guess from a missing library or some such. I > will investigate some more and see what I find. > That shouldn't be a big problem. It just means that NumPy will provide the missing features instead of using the system functions. More problematic is the strange errors you are getting about void * not having a size. The line numbers you show are where we have variable declarations like register intp i Is it possible that integers the size of void * cannot be placed in a register?? -Travis |
|
From: Travis O. <oli...@ie...> - 2006-02-07 06:13:36
|
Tim Hochberg wrote:
> Travis Oliphant wrote:
>
>> Tim Hochberg wrote:
>>
>>>
>>> Just a little update on this:
>>>
>>> It appears that all (or almost all) of the checks in
>>> generate_config_h must be failing. I would guess from a missing
>>> library or some such. I will investigate some more and see what I find.
>>>
>> That shouldn't be a big problem. It just means that NumPy will
>> provide the missing features instead of using the system functions.
>> More problematic is the strange errors you are getting about void *
>> not having a size. The line numbers you show are where we have
>> variable declarations like
>>
>> register intp i
>>
>> Is it possible that integers the size of void * cannot be placed in a
>> register??
>
>
> OK, I think I found what causes the problem. What we have is lines like:
>
> for(i=0; i<n; i++, ip+=skip, op+=oskip) {
>
> where op is declared (void*).
There shouldn't be anything like that. These should all be char *.
Where did you see these?
>
> Of course, unfuncmodule then failed to compile. A quick peak shows
> that it's throwing a lot of syntax errors. It appears to happen
> whenever there's a longdouble function defined. For example:
>
> longdouble sinl(longdouble x) {
> return (longdouble) sin((double)x);
> }
On your platform longdouble should be equivalent to double, so I'm not
sure why this would fail.
-Travis
|
|
From: Travis O. <oli...@ie...> - 2006-02-07 19:08:41
|
Tim Hochberg wrote: > > A couple of more minor issues. > > 1. numpy/random/mtrand/distributions.c needs M_PI defined if is not > already. I used the def from umathmodule.c: > > #ifndef M_PI > #define M_PI 3.14159265358979323846264338328 > #endif > > 2. The math library m.lib was hardcoded into numpy/random/setup.py. > I simply replaced ['m'] with [], which is probably not right in > general. It should probably be grabbed from config.h. > > 3. This made it through all the compiling, but blew up on linking > randomkit because sever CryptXXX functions were not defined. I added > 'Advapi32' to the libraries list. (In total libraries went from ['m'] > to ['Advapi32']. > > With this I got a full compile. I successfully imported numpy and > added a couple of matrices. Hooray! > > Is there a way to run it through some regression tests? That seems > like it should be the next step. > > Let's see if we can't fix up the setup.py file to handle this common platform correctly.... import numpy numpy.test(1,1) -Travis |
|
From: Travis O. <oli...@ie...> - 2006-02-08 00:51:53
|
Tim Hochberg wrote: > > OK, I finally got it to pass all of the tests. The final two pieces of > the puzzle were using _isnan and _finite and then realizing the > _finite was not in fact the opposite of isinf. Thanks for finding this. I've updated the ufuncobject.h file with definitions for isinf, isfinite, and isnan. Presumably this should allow the SVN version of numpy to build. Let me know what happens. -Travis |
|
From: Travis O. <oli...@ie...> - 2006-02-09 16:10:27
|
Tim Hochberg wrote:
> I'm attaching the two modified setup files. The first is
> numpy/core/setup.py and the second is numpy/random/setup.py. I tried
> to keep the modifications as minimal as possible. With these two setup
> files, and adding M_PI to numpy\random\mtrand\distributions.c, numpy
> compiles fine and passes all tests except for the test_minrelpath path
> I mentioned in my last message.
I'm trying to incorporate your changes.
1) M_PI was easy to fix.
2) In the core/setup.py file you sent you add the line:
python_libs = join(distutils.sysconfig.EXEC_PREFIX, 'libs')
I'm not sure what this is supposed to do. What problem does it fix on
your system? It makes no sence on mine as this becomes
python_libs = '/usr/libs'
which is not a directory.
3) For the setup.py file in random you are using Advapi for all win32
platforms. But, this seems to be a windows NT file or at least only
needed when compiling with certain compilers. Mingw32 built just fine
without it. So, I'm not sure how to handle this.
Suggestions?
-Travis
>
> -tim
>
>------------------------------------------------------------------------
>
>
>import imp
>import os
>import sys
>import distutils.sysconfig
>from os.path import join
>from glob import glob
>from distutils.dep_util import newer,newer_group
>
>def configuration(parent_package='',top_path=None):
> from numpy.distutils.misc_util import Configuration,dot_join
> from numpy.distutils.system_info import get_info
>
> config = Configuration('core',parent_package,top_path)
> local_dir = config.local_path
> codegen_dir = join(local_dir,'code_generators')
>
> generate_umath_py = join(codegen_dir,'generate_umath.py')
> n = dot_join(config.name,'generate_umath')
> generate_umath = imp.load_module('_'.join(n.split('.')),
> open(generate_umath_py,'U'),generate_umath_py,
> ('.py','U',1))
>
> header_dir = join(*(config.name.split('.')+['include','numpy']))
>
> def generate_config_h(ext, build_dir):
> target = join(build_dir,'config.h')
> if newer(__file__,target):
> config_cmd = config.get_config_cmd()
> print 'Generating',target
> #
> tc = generate_testcode(target)
> from distutils import sysconfig
> python_include = sysconfig.get_python_inc()
> python_libs = join(distutils.sysconfig.EXEC_PREFIX, 'libs')
> result = config_cmd.try_run(tc,include_dirs=[python_include], library_dirs=[python_libs])
> if not result:
> raise "ERROR: Failed to test configuration"
> moredefs = []
>
> #
> mathlibs = []
> tc = testcode_mathlib()
> mathlibs_choices = [[],['m'],['cpml']]
> mathlib = os.environ.get('MATHLIB')
> if mathlib:
> mathlibs_choices.insert(0,mathlib.split(','))
> for libs in mathlibs_choices:
> if config_cmd.try_run(tc,libraries=libs):
> mathlibs = libs
> break
> else:
> raise "math library missing; rerun setup.py after setting the MATHLIB env variable"
> ext.libraries.extend(mathlibs)
> moredefs.append(('MATHLIB',','.join(mathlibs)))
>
> libs = mathlibs
> kws_args = {'libraries':libs,'decl':0,'headers':['math.h']}
> if config_cmd.check_func('expl', **kws_args):
> moredefs.append('HAVE_LONGDOUBLE_FUNCS')
> if config_cmd.check_func('expf', **kws_args):
> moredefs.append('HAVE_FLOAT_FUNCS')
> if config_cmd.check_func('log1p', **kws_args):
> moredefs.append('HAVE_LOG1P')
> if config_cmd.check_func('expm1', **kws_args):
> moredefs.append('HAVE_EXPM1')
> if config_cmd.check_func('asinh', **kws_args):
> moredefs.append('HAVE_INVERSE_HYPERBOLIC')
> if config_cmd.check_func('atanhf', **kws_args):
> moredefs.append('HAVE_INVERSE_HYPERBOLIC_FLOAT')
> if config_cmd.check_func('atanhl', **kws_args):
> moredefs.append('HAVE_INVERSE_HYPERBOLIC_LONGDOUBLE')
> if config_cmd.check_func('isnan', **kws_args):
> moredefs.append('HAVE_ISNAN')
> if config_cmd.check_func('isinf', **kws_args):
> moredefs.append('HAVE_ISINF')
>
> if sys.version[:3] < '2.4':
> kws_args['headers'].append('stdlib.h')
> if config_cmd.check_func('strtod', **kws_args):
> moredefs.append(('PyOS_ascii_strtod', 'strtod'))
>
> if moredefs:
> target_f = open(target,'a')
> for d in moredefs:
> if isinstance(d,str):
> target_f.write('#define %s\n' % (d))
> else:
> target_f.write('#define %s %s\n' % (d[0],d[1]))
> target_f.close()
> else:
> mathlibs = []
> target_f = open(target)
> for line in target_f.readlines():
> s = '#define MATHLIB'
> if line.startswith(s):
> value = line[len(s):].strip()
> if value:
> mathlibs.extend(value.split(','))
> target_f.close()
>
> ext.libraries.extend(mathlibs)
>
> incl_dir = os.path.dirname(target)
> if incl_dir not in config.numpy_include_dirs:
> config.numpy_include_dirs.append(incl_dir)
>
> config.add_data_files((header_dir,target))
> return target
>
> def generate_api_func(header_file, module_name):
> def generate_api(ext,build_dir):
> target = join(build_dir, header_file)
> script = join(codegen_dir, module_name + '.py')
> if newer(script, target):
> sys.path.insert(0, codegen_dir)
> try:
> m = __import__(module_name)
> print 'executing',script
> m.generate_api(build_dir)
> finally:
> del sys.path[0]
> config.add_data_files((header_dir,target))
> return target
> return generate_api
>
> generate_array_api = generate_api_func('__multiarray_api.h',
> 'generate_array_api')
> generate_ufunc_api = generate_api_func('__ufunc_api.h',
> 'generate_ufunc_api')
>
> def generate_umath_c(ext,build_dir):
> target = join(build_dir,'__umath_generated.c')
> script = generate_umath_py
> if newer(script,target):
> f = open(target,'w')
> f.write(generate_umath.make_code(generate_umath.defdict,
> generate_umath.__file__))
> f.close()
> return []
>
> config.add_data_files(join('include','numpy','*.h'))
> config.add_include_dirs('src')
>
> config.numpy_include_dirs.extend(config.paths('include'))
>
> deps = [join('src','arrayobject.c'),
> join('src','arraymethods.c'),
> join('src','scalartypes.inc.src'),
> join('src','arraytypes.inc.src'),
> join('src','_signbit.c'),
> join('src','_isnan.c'),
> join('include','numpy','*object.h'),
> join(codegen_dir,'genapi.py'),
> join(codegen_dir,'*.txt')
> ]
>
> config.add_extension('multiarray',
> sources = [join('src','multiarraymodule.c'),
> generate_config_h,
> generate_array_api,
> join('src','scalartypes.inc.src'),
> join('src','arraytypes.inc.src'),
> join(codegen_dir,'generate_array_api.py'),
> join('*.py')
> ],
> depends = deps,
> )
>
> config.add_extension('umath',
> sources = [generate_config_h,
> join('src','umathmodule.c.src'),
> generate_umath_c,
> generate_ufunc_api,
> join('src','scalartypes.inc.src'),
> join('src','arraytypes.inc.src'),
> ],
> depends = [join('src','ufuncobject.c'),
> generate_umath_py,
> join(codegen_dir,'generate_ufunc_api.py'),
> ]+deps,
> )
>
> config.add_extension('_sort',
> sources=[join('src','_sortmodule.c.src'),
> generate_config_h,
> generate_array_api,
> ],
> )
>
> # Configure blasdot
> blas_info = get_info('blas_opt',0)
> #blas_info = {}
> def get_dotblas_sources(ext, build_dir):
> if blas_info:
> return ext.depends[:1]
> return None # no extension module will be built
>
> config.add_extension('_dotblas',
> sources = [get_dotblas_sources],
> depends=[join('blasdot','_dotblas.c'),
> join('blasdot','cblas.h'),
> ],
> include_dirs = ['blasdot'],
> extra_info = blas_info
> )
>
>
> config.add_data_dir('tests')
> config.make_svn_version_py()
>
> return config
>
>def testcode_mathlib():
> return """\
>/* check whether libm is broken */
>#include <math.h>
>int main(int argc, char *argv[])
>{
> return exp(-720.) > 1.0; /* typically an IEEE denormal */
>}
>"""
>
>import sys
>def generate_testcode(target):
> if sys.platform == 'win32':
> target = target.replace('\\','\\\\')
> testcode = [r'''
>#include <Python.h>
>#include <limits.h>
>#include <stdio.h>
>
>int main(int argc, char **argv)
>{
>
> FILE *fp;
>
> fp = fopen("'''+target+'''","w");
> ''']
>
> c_size_test = r'''
>#ifndef %(sz)s
> fprintf(fp,"#define %(sz)s %%d\n", sizeof(%(type)s));
>#else
> fprintf(fp,"/* #define %(sz)s %%d */\n", %(sz)s);
>#endif
>'''
> for sz, t in [('SIZEOF_SHORT', 'short'),
> ('SIZEOF_INT', 'int'),
> ('SIZEOF_LONG', 'long'),
> ('SIZEOF_FLOAT', 'float'),
> ('SIZEOF_DOUBLE', 'double'),
> ('SIZEOF_LONG_DOUBLE', 'long double'),
> ('SIZEOF_PY_INTPTR_T', 'Py_intptr_t'),
> ]:
> testcode.append(c_size_test % {'sz' : sz, 'type' : t})
>
> testcode.append('#ifdef PY_LONG_LONG')
> testcode.append(c_size_test % {'sz' : 'SIZEOF_LONG_LONG',
> 'type' : 'PY_LONG_LONG'})
> testcode.append(c_size_test % {'sz' : 'SIZEOF_PY_LONG_LONG',
> 'type' : 'PY_LONG_LONG'})
>
>
> testcode.append(r'''
>#else
> fprintf(fp, "/* PY_LONG_LONG not defined */\n");
>#endif
>#ifndef CHAR_BIT
> {
> unsigned char var = 2;
> int i=0;
> while (var >= 2) {
> var = var << 1;
> i++;
> }
> fprintf(fp,"#define CHAR_BIT %d\n", i+1);
> }
>#else
> fprintf(fp, "/* #define CHAR_BIT %d */\n", CHAR_BIT);
>#endif
> fclose(fp);
> return 0;
>}
>''')
> testcode = '\n'.join(testcode)
> return testcode
>
>if __name__=='__main__':
> from numpy.distutils.core import setup
> setup(**configuration(top_path='').todict())
>
>
>------------------------------------------------------------------------
>
>import sys
>from os.path import join
>
>def configuration(parent_package='',top_path=None):
> from numpy.distutils.misc_util import Configuration
> config = Configuration('random',parent_package,top_path)
>
> # Configure mtrand
> # Note that I'm mimicking the original behaviour of always using 'm' for
> # the math library. This should probably use the logic from numpy/core/setup.py
> # to chose the math libraries, but I'm going for minimal changes -- TAH
> if sys.platform == "win32":
> libraries = ['Advapi32']
> else:
> libraries = ['m']
> config.add_extension('mtrand',
> sources=[join('mtrand', x) for x in
> ['mtrand.c', 'randomkit.c', 'initarray.c',
> 'distributions.c']],
> libraries=libraries,
> depends = [join('mtrand','*.h'),
> join('mtrand','*.pyx'),
> join('mtrand','*.pxi'),
> ]
> )
>
> return config
>
>if __name__ == '__main__':
> from numpy.distutils.core import setup
> setup(**configuration(top_path='').todict())
>
>
|
|
From: Tim H. <tim...@co...> - 2006-02-09 16:29:57
|
Travis Oliphant wrote:
> Tim Hochberg wrote:
>
>> I'm attaching the two modified setup files. The first is
>> numpy/core/setup.py and the second is numpy/random/setup.py. I tried
>> to keep the modifications as minimal as possible. With these two
>> setup files, and adding M_PI to numpy\random\mtrand\distributions.c,
>> numpy compiles fine and passes all tests except for the
>> test_minrelpath path I mentioned in my last message.
>
>
>
> I'm trying to incorporate your changes.
Great.
> 1) M_PI was easy to fix.
>
> 2) In the core/setup.py file you sent you add the line:
>
> python_libs = join(distutils.sysconfig.EXEC_PREFIX, 'libs')
>
> I'm not sure what this is supposed to do. What problem does it fix on
> your system? It makes no sence on mine as this becomes
>
> python_libs = '/usr/libs'
>
> which is not a directory.
OK, we'll have to work out something that works for both. The issue here
on windows is that compiling the testcode requires python.lib, and it
doesn't get found unless that directory is specified. The problem is
perhaps related to the following comment in system_info.py
if sys.platform == 'win32': # line 116
default_lib_dirs = ['C:\\'] # probably not very helpful...
In any event, it does seem like there should be a better way to find
where python.lib lives, but I couldn't find it in my perusal of the
distutils docs.
>
> 3) For the setup.py file in random you are using Advapi for all win32
> platforms. But, this seems to be a windows NT file
I'm compiling on XP FWIW.
> or at least only needed when compiling with certain compilers.
> Mingw32 built just fine without it. So, I'm not sure how to handle
> this.
My guess, and it's only a gues because I use neither mingw or the
windows crypto stuff, is that defines are set differently by mingw so
that the parts that need that library are not being compiled when you
use mingw. The code in question is all gaurded by:
#ifdef _WIN32
#ifndef RK_NO_WINCRYPT
As far as I can tell, RK_NO_WINCRYPT never gets defined anywhere, so the
important test is for _WIN32. So, does mingw define _WIN32? If it does
not, then that's what's going on. In that case, the proper test is
probably to check if _WIN32 is defined by the compiler in question and
include Advapi only then. If it does define _WIN32, then I dunno!
-tim
|
|
From: Travis O. <oli...@ie...> - 2006-02-09 17:29:14
|
Tim Hochberg wrote: >> >> >> I'm trying to incorporate your changes. > > > > Great. > > > OK, we'll have to work out something that works for both. The issue > here on windows is that compiling the testcode requires python.lib, > and it doesn't get found unless that directory is specified. The > problem is perhaps related to the following comment in system_info.py > > if sys.platform == 'win32': # line 116 > default_lib_dirs = ['C:\\'] # probably not very helpful... I added the change you made in setup.py to default_lib_dirs, here. See if this fixes it. >> >> 3) For the setup.py file in random you are using Advapi for all win32 >> platforms. But, this seems to be a windows NT file > > > I'm compiling on XP FWIW. > >> or at least only needed when compiling with certain compilers. >> Mingw32 built just fine without it. So, I'm not sure how to handle >> this. > I see now. On _WIN32 platforms it's using the registry instead of the file system to store things. I modified the random/setup.py script to test for _WIN32 in the compiler and add the dll to the list of libraries if it is found. I'm also reading the configuration file to determine MATHLIB. Can you try out the new SVN and see if it builds for you without modification. -Travis |
|
From: Tim H. <tim...@co...> - 2006-02-09 18:33:52
|
Travis Oliphant wrote:
> Tim Hochberg wrote:
>
>>>
>>>
>>> I'm trying to incorporate your changes.
>>
>>
>>
>>
>> Great.
>>
>>
>> OK, we'll have to work out something that works for both. The issue
>> here on windows is that compiling the testcode requires python.lib,
>> and it doesn't get found unless that directory is specified. The
>> problem is perhaps related to the following comment in system_info.py
>>
>> if sys.platform == 'win32': # line 116
>> default_lib_dirs = ['C:\\'] # probably not very helpful...
>
>
>
> I added the change you made in setup.py to default_lib_dirs, here.
> See if this fixes it.
>
>>>
>>> 3) For the setup.py file in random you are using Advapi for all
>>> win32 platforms. But, this seems to be a windows NT file
>>
>>
>>
>> I'm compiling on XP FWIW.
>>
>>> or at least only needed when compiling with certain compilers.
>>> Mingw32 built just fine without it. So, I'm not sure how to handle
>>> this.
>>
>>
> I see now. On _WIN32 platforms it's using the registry instead of the
> file system to store things. I modified the random/setup.py script to
> test for _WIN32 in the compiler and add the dll to the list of
> libraries if it is found. I'm also reading the configuration file to
> determine MATHLIB.
>
> Can you try out the new SVN and see if it builds for you without
> modification.
There's a shallow error in system_info.py
File "C:\Documents and
Settings\End-user\Desktop\numpy\svn\numpy\numpy\distutils\system_info.py",
line 118, in ?
default_lib_dirs = ['C:\\',
NameError: name 'join' is not defined
Just replacing join with os.path.join fixed that. However, it didn't
help. I had this fantasy that default_lib_dirs would get picked up
automagically; however that does not happen. I still ended up putting:
from numpy.distutils import system_info
library_dirs = system_info.default_lib_dirs
result =
config_cmd.try_run(tc,include_dirs=[python_include],
library_dirs=library_dirs)
into setup.py. Is that acceptable? It's not very elegant.
The changes to setup.py in random and the M_PI, seem to have worked
since with the changes above it compiles and passes all of the tests
except for the previously mentioned test_minrelpath.
-tim
|
|
From: Travis O. <oli...@ie...> - 2006-02-09 20:32:27
|
Tim Hochberg wrote: > > > There's a shallow error in system_info.py > > File "C:\Documents and > Settings\End-user\Desktop\numpy\svn\numpy\numpy\distutils\system_info.py", > > line 118, in ? > default_lib_dirs = ['C:\\', > NameError: name 'join' is not defined > > Just replacing join with os.path.join fixed that. However, it didn't > help. I had this fantasy that default_lib_dirs would get picked up > automagically; however that does not happen. I still ended up putting: > > from numpy.distutils import system_info > library_dirs = system_info.default_lib_dirs > result = > config_cmd.try_run(tc,include_dirs=[python_include], > library_dirs=library_dirs) > > into setup.py. Is that acceptable? It's not very elegant. I think it's probably O.K. as long as it doesn't produce errors on other systems (and it doesn't on mine). > > The changes to setup.py in random and the M_PI, seem to have worked > since with the changes above it compiles and passes all of the tests > except for the previously mentioned test_minrelpath. > I thought I fixed minrelpath too by doing a search and replace. Perhaps this did not help. -Travis |
|
From: Pearu P. <pe...@sc...> - 2006-02-09 22:34:16
|
On Thu, 9 Feb 2006, Tim Hochberg wrote: > I had this fantasy that default_lib_dirs would get picked up > automagically; however that does not happen. I still ended up putting: > > from numpy.distutils import system_info > library_dirs = system_info.default_lib_dirs > result = config_cmd.try_run(tc,include_dirs=[python_include], > library_dirs=library_dirs) > > into setup.py. Is that acceptable? It's not very elegant. No, don't use system_info.default_lib_dirs. Use distutils.sysconfig.get_python_lib() to get the directory that contains Python library. Pearu |
|
From: Tim H. <tim...@co...> - 2006-02-09 22:45:12
|
Pearu Peterson wrote: > > > On Thu, 9 Feb 2006, Tim Hochberg wrote: > >> I had this fantasy that default_lib_dirs would get picked up >> automagically; however that does not happen. I still ended up putting: >> >> from numpy.distutils import system_info >> library_dirs = system_info.default_lib_dirs >> result = >> config_cmd.try_run(tc,include_dirs=[python_include], >> library_dirs=library_dirs) >> >> into setup.py. Is that acceptable? It's not very elegant. > > > No, don't use system_info.default_lib_dirs. > > Use distutils.sysconfig.get_python_lib() to get the directory that > contains Python library. That's the wrong library. Get_python_lib gives you the location of the python standard library, not the location of python24.lib <cid:par...@co...>. The former being python24/Lib (or python24/Lib/site-packages depending what options you feed get_python_lib) 'and the latter being python24/libs on my box. -tim |
|
From: Tim H. <tim...@co...> - 2006-02-10 01:06:54
|
Tim Hochberg wrote:
> Pearu Peterson wrote:
>
>>
>>
>> On Thu, 9 Feb 2006, Tim Hochberg wrote:
>>
>>> I had this fantasy that default_lib_dirs would get picked up
>>> automagically; however that does not happen. I still ended up putting:
>>>
>>> from numpy.distutils import system_info
>>> library_dirs = system_info.default_lib_dirs
>>> result =
>>> config_cmd.try_run(tc,include_dirs=[python_include],
>>> library_dirs=library_dirs)
>>>
>>> into setup.py. Is that acceptable? It's not very elegant.
>>
>>
>>
>> No, don't use system_info.default_lib_dirs.
>>
>> Use distutils.sysconfig.get_python_lib() to get the directory that
>> contains Python library.
>
>
> That's the wrong library. Get_python_lib gives you the location of the
> python standard library, not the location of python24.lib. The former
> being python24/Lib (or python24/Lib/site-packages depending what
> options you feed get_python_lib) 'and the latter being python24/libs
> on my box.
To follow up on this a little bit, I investigated how distutils itself
finds python24.lib. It turns out that it is in build_ext.py, near line
168. The relevant code is:
# also Python's library directory must be appended to library_dirs
if os.name == 'nt':
self.library_dirs.append(os.path.join(sys.exec_prefix, 'libs'))
Unfortunately, there's no obvious, clean way to extract the library
information from there. You can grab it using the following magic formula:
from distutils.core import Distribution
from distutils.command import build_ext
be = build_ext.build_ext(Distribution())
be.finalize_options()
librarys_dirs = be.library_dirs
However, that seems worse than what we're doing now. I haven't actually
tried this in the code either -- for all I know instantiating an extra
Distribution may have some horrible side effect that I don't know about.
If someone can come up with a cleaner way to get to this info, that'd be
great, otherwise I'd say we might as well just keep things as they are
for the time being.
Regards,
-tim
|
|
From: Pearu P. <pe...@sc...> - 2006-02-10 07:14:59
|
On Thu, 9 Feb 2006, Tim Hochberg wrote: > Tim Hochberg wrote: > >> Pearu Peterson wrote: >> >>> >>> >>> On Thu, 9 Feb 2006, Tim Hochberg wrote: >>> >>>> I had this fantasy that default_lib_dirs would get picked up >>>> automagically; however that does not happen. I still ended up putting: >>>> >>>> from numpy.distutils import system_info >>>> library_dirs = system_info.default_lib_dirs >>>> result = config_cmd.try_run(tc,include_dirs=[python_include], >>>> library_dirs=library_dirs) >>>> >>>> into setup.py. Is that acceptable? It's not very elegant. >>> >>> >>> >>> No, don't use system_info.default_lib_dirs. >>> >>> Use distutils.sysconfig.get_python_lib() to get the directory that >>> contains Python library. >> >> >> That's the wrong library. Get_python_lib gives you the location of the >> python standard library, not the location of python24.lib. The former being >> python24/Lib (or python24/Lib/site-packages depending what options you feed >> get_python_lib) 'and the latter being python24/libs on my box. Ok, but using system_info.default_lib_dirs is still wrong, this list is not designed for this purpose.. > To follow up on this a little bit, I investigated how distutils itself finds > python24.lib. It turns out that it is in build_ext.py, near line 168. The > relevant code is: > > # also Python's library directory must be appended to library_dirs > if os.name == 'nt': > self.library_dirs.append(os.path.join(sys.exec_prefix, 'libs')) Hmm, this should be effective also for numpy.distutils. self.library_dirs and other such attributes are used in distutils.command.build_ext.run() method while our numpy.distutils.command.build_ext.run() doesn't. So, I we have to do is to update numpy.distutils.command.build_ext.run() method to resolve this issue. This should fix also rpath issues that was reported on this list for certain platforms. I'll look fixing it today.. Pearu |
|
From: Tim H. <tim...@co...> - 2006-02-10 17:40:32
|
Pearu Peterson wrote:
>
>
> On Thu, 9 Feb 2006, Tim Hochberg wrote:
>
>> Tim Hochberg wrote:
>>
>>> Pearu Peterson wrote:
>>>
>>>>
>>>>
>>>> On Thu, 9 Feb 2006, Tim Hochberg wrote:
>>>>
>>>>> I had this fantasy that default_lib_dirs would get picked up
>>>>> automagically; however that does not happen. I still ended up
>>>>> putting:
>>>>>
>>>>> from numpy.distutils import system_info
>>>>> library_dirs = system_info.default_lib_dirs
>>>>> result =
>>>>> config_cmd.try_run(tc,include_dirs=[python_include],
>>>>> library_dirs=library_dirs)
>>>>>
>>>>> into setup.py. Is that acceptable? It's not very elegant.
>>>>
>>>>
>>>>
>>>>
>>>> No, don't use system_info.default_lib_dirs.
>>>>
>>>> Use distutils.sysconfig.get_python_lib() to get the directory that
>>>> contains Python library.
>>>
>>>
>>>
>>> That's the wrong library. Get_python_lib gives you the location of
>>> the python standard library, not the location of python24.lib. The
>>> former being python24/Lib (or python24/Lib/site-packages depending
>>> what options you feed get_python_lib) 'and the latter being
>>> python24/libs on my box.
>>
>
> Ok, but using system_info.default_lib_dirs is still wrong, this list
> is not designed for this purpose..
OK.
>
>> To follow up on this a little bit, I investigated how distutils
>> itself finds python24.lib. It turns out that it is in build_ext.py,
>> near line 168. The relevant code is:
>>
>> # also Python's library directory must be appended to library_dirs
>> if os.name == 'nt':
>> self.library_dirs.append(os.path.join(sys.exec_prefix,
>> 'libs'))
>
>
> Hmm, this should be effective also for numpy.distutils.
> self.library_dirs and other such attributes are used in
> distutils.command.build_ext.run() method while our
> numpy.distutils.command.build_ext.run() doesn't. So, I we have to do
> is to update numpy.distutils.command.build_ext.run() method to resolve
> this issue. This should fix also rpath issues that was reported on
> this list for certain platforms. I'll look fixing it today..
While your looking at it, keep in mind that the original failure that I
was trying to fix occurs when numpy/core/setup.py calls
config_cmd.try_run. I'm not certain, but I suspect that this isn't
going to got through numpy.distutils.command.build_ext. One strategy
would be to put a functions somewhere that returns these extra libray
directories somewhere appropriate and call it from both
numpy.distutils.command.build_ext and numpy/core/setup.py. It could look
like:
def get_extra_library_dirs():
if os.name == 'nt':
return [os.path.join(sys.exec_prefix, 'libs')]
else:
return []
I'm not sure what would be an appropriate place for it though.
-tim
>
> Pearu
>
>
|