Discussion:
[Numpy-discussion] NumPy + Python 3.5 + Windows + VS2015
Jaime Fernández del Río
2015-06-08 22:11:47 UTC
Permalink
I have just unsuccessfully tried to build numpy under Windows for Python
3.5, using the latest release candidate for Visual Studio 2015.

A very early failure with a:

RuntimeError: Broken toolchain: cannot link a simple C program

even though repeating the sequence of commands that lead to the failure
manually seems to work.

Anyway, before diving deeper into this, has anyone tried this out already
and have some success or failure stories to share?

Thanks,

Jaime
--
(\__/)
( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
de dominación mundial.
Jaime Fernández del Río
2015-06-09 23:12:10 UTC
Permalink
On Mon, Jun 8, 2015 at 3:11 PM, Jaime Fernández del Río <
Post by Jaime Fernández del Río
I have just unsuccessfully tried to build numpy under Windows for Python
3.5, using the latest release candidate for Visual Studio 2015.
RuntimeError: Broken toolchain: cannot link a simple C program
even though repeating the sequence of commands that lead to the failure
manually seems to work.
Anyway, before diving deeper into this, has anyone tried this out already
and have some success or failure stories to share?
I have finally managed to get this to compile. There are two places at
which things go wrong:

1. The call to check_long_double_representation in numpy/core/setup.py.
This tries to figure out the representation used by the compiler for long
double by compiling C code declaring a struct with a char array, a long
double, and another char array, initializing them to specific values, then
parsing the obj file byte by byte to detect the sequence in the first and
second char array, The sequences are there, but not in contiguous bytes,
for some reason the compiler is adding 3 bytes between each of the bytes in
the sequence. I bypassed this hardcoding the long double representation to
IEEE_DOUBLE_LE.
2. The call to generate_libraries in numpy/random/setup.py. This is
supposed to compile and run a small c program to check if _WIN32 is defined
by the compiler, in which case the 'Advapi32' library is linked. Haven't
gone into the details, but that compile and run also fails, so the library
was never getting added. I simply unconditionally added the library to get
it working.

Once compiled there is something like 20 or 30 test failures, which I
haven't looked into in any detail. I was also getting a handful of
segfaults while running the tests, but it has stopped segfaulting now, even
though I have run the tests in a loop 100 times.

Not sure if we want to try to fix any of this for 1.10. It will probably be
the first release that people try to make work with Python 3.5 when the
final release comes out in September. But it is also hard to figure out how
many of these problems are caused by Python 3.5 itself, or by MSVC 2015,
which is still in RC phase.

Jaime
--
(\__/)
( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
de dominación mundial.
Charles R Harris
2015-06-09 23:48:19 UTC
Permalink
On Tue, Jun 9, 2015 at 5:12 PM, Jaime Fernández del Río <
Post by Jaime Fernández del Río
On Mon, Jun 8, 2015 at 3:11 PM, Jaime Fernández del Río <
Post by Jaime Fernández del Río
I have just unsuccessfully tried to build numpy under Windows for Python
3.5, using the latest release candidate for Visual Studio 2015.
RuntimeError: Broken toolchain: cannot link a simple C program
even though repeating the sequence of commands that lead to the failure
manually seems to work.
Anyway, before diving deeper into this, has anyone tried this out already
and have some success or failure stories to share?
I have finally managed to get this to compile. There are two places at
1. The call to check_long_double_representation in
numpy/core/setup.py. This tries to figure out the representation used by
the compiler for long double by compiling C code declaring a struct with a
char array, a long double, and another char array, initializing them to
specific values, then parsing the obj file byte by byte to detect the
sequence in the first and second char array, The sequences are there, but
not in contiguous bytes, for some reason the compiler is adding 3 bytes
between each of the bytes in the sequence. I bypassed this hardcoding the
long double representation to IEEE_DOUBLE_LE.
2. The call to generate_libraries in numpy/random/setup.py. This is
supposed to compile and run a small c program to check if _WIN32 is defined
by the compiler, in which case the 'Advapi32' library is linked. Haven't
gone into the details, but that compile and run also fails, so the library
was never getting added. I simply unconditionally added the library to get
it working.
Once compiled there is something like 20 or 30 test failures, which I
haven't looked into in any detail. I was also getting a handful of
segfaults while running the tests, but it has stopped segfaulting now, even
though I have run the tests in a loop 100 times.
Not sure if we want to try to fix any of this for 1.10. It will probably
be the first release that people try to make work with Python 3.5 when the
final release comes out in September. But it is also hard to figure out how
many of these problems are caused by Python 3.5 itself, or by MSVC 2015,
which is still in RC phase.
Thanks for looking into this. It is depressing that Windows is so difficult
to support. There might be some Microsoft pragmas/flags that will help.

Chuck
Chris Barker
2015-06-10 17:24:25 UTC
Permalink
Post by Charles R Harris
Thanks for looking into this. It is depressing that Windows is so
difficult to support.
yes, thanks!

You might try posting on python-dev -- there is at least one person on that
list trying to help get Windows builds working better!

It seems to me that these are general compiler issues, not numpy-specific
ones -- though numpy clearly stresses the system!

-Chris
--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

***@noaa.gov
Loading...