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.
I guess compiling package modules is just an overall badly supported
feature in CPython...
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)
When disabling
test_slice_assignment, runtests.py completes with many failures.
The results of `runtests.py -v -v` are at
<http://www.lfd.uci.edu/~gohlke/pythonlibs/tests/cython/>.
The 64bit output looks so broken that I wonder what went wrong here. I
mean, most of the problems look like this:
"""
Expected:
Traceback (most recent call last):
TypeError: m() takes at most 2 positional arguments (3 given)
Got:
Traceback (most recent call last):
TypeError: m() takes at most %Id positional argument%s (%Id given)
"""
I have no idea how that can happen.
I can see two other problems, one is the linker warning about the module
init function in Py3:
"""
bufaccess.obj : warning LNK4197: export 'PyInit_bufaccess' specified
multiple times; using first specification
"""
This is "normal".
The other one is about mixing Py_ssize_t and int (and some other) types
all
over the place:
"""
bufaccess.c(3033) : warning C4244: '=' : conversion from 'Py_ssize_t' to
'int', possible loss of data
"""
Some of them look like we'd need an explicit cast in the C code somewhere,
others might hint at lax type usage in tests.
There's also this:
"""
C:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\INCLUDE\xlocale(323)
: warning C4530: C++ exception handler used, but unwind semantics are not
enabled. Specify /EHsc
"""
Stefan
Thanks,
Christoph
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
