Christoph Gohlke, 25.08.2012 04:07: > On 8/24/2012 12:43 PM, Stefan Behnel wrote: >> Christoph Gohlke, 24.08.2012 07:20: >>> I tested Cython-0.17b3 on Windows 7 with Visual Studio compilers. >>> >>> 32 bit Python 2.7 works well, only 4 test failures. >> >> Three of those errors are in OpenMP tests - is OpenMP supported in your >> build environment? > > OpenMP is available on my system, and parallel.pyd is linked to the openmp > library. The prange tests fail only sometimes. On my system, the prange > index is sometimes left at the start (zero) of the range, while the tests > expect the index to be left at the stop of the range. According to the > Cython prange enhancements webpage "the iterations of the loop body can be > executed in any order" <http://wiki.cython.org/enhancements/prange>. Where > does that leave the loop index?
Mark should know best. I agree that this seems a bit smelly. >> The other one is the new "initial_file_path" test that fails with this >> linker error: >> >> """ >> C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\link.exe /DLL >> /nologo /INCREMENTAL:NO /INCREMENTAL:YES /DEBUG /LIBPATH:X:\Python27\libs >> /LIBPATH:X:\Python27\PCbuild /EXPORT:init__init__ >> build\temp.win32-2.7\Release\my_test_package\__init__.obj >> /OUT:\Cython-0.17b3\BUILD\run\initial_file_path\my_test_package\__init__.pyd >> /IMPLIB:build\temp.win32-2.7\Release\my_test_package\__init__.lib >> /MANIFESTFILE:build\temp.win32-2.7\Release\my_test_package\__init__.pyd.manifest >> >> >> LINK : error LNK2001: unresolved external symbol init__init__ >> """ >> >> Maybe the Windows build of distutils is broken here - it seems to assume >> the wrong module name for the package module. > > I think this is an issue with the test. The extension does compile and link > outside of the tests. Hmm, did you run the setup.py script? It compiles the "__init__.py" file as well, which is the problem above. Could you check if that's properly being imported as a shared library? (The way "somefile.srctree" tests work is that they explode into a directory structure and then just run the commands in the first lines.) >>> On 64 bit Python 2.7 and 3.2 with msvc9 compiler, python.exe crashes during >>> `test_slice_assignment (memslice.__test__)`. I tested two computers. The >>> Windows executive can not identify in which specific module it crashes, and >>> neither enabling faulthandler nor building with debug symbols gives any >>> useful information. Can anyone reproduce this? It seems compiler specific >>> since Python 3.3, which is using msvc10, does not crash. >> >> Hmm, yes, sounds like a problem with the compiler. Would be good to get >> this sorted out, but it's almost impossible to debug something like this >> from a distance. > > Maybe the following simple example is related. It fails (not crash) when > compiled with 64 bit msvc9, but does work with 32 bit msvc9 and msvc10 (32 > and 64 bit): > > ``` > from cython.view cimport array as cvarray > import numpy as np > > narr = np.arange(8 * 14 * 11).reshape((8, 14, 11)) > > cdef int[:, :, ::1] a = narr > cdef int[:, :, :] b = a[2:8:2, -4:1:-1, 1:3] > > print narr[2:8:2, -4:1:-1, 1:3].shape > print b.shape[0], b.shape[1], b.shape[2] > ``` > > On win-amd64-py2.x the shape of b is (3, 9, 3) but it should be (3, 9, 2) I'll leave that for the others to comment. >> """ >> bufaccess.obj : warning LNK4197: export 'PyInit_bufaccess' specified >> multiple times; using first specification >> """ > > This is "normal". So you have an idea why this happens? Is it because of that explicit /EXPORT command line switch for the module init function name? Stefan _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
