<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 9, 2015 at 5:12 PM, Jaime Fernández del Río <span dir="ltr"><<a href="mailto:jaime.frio@gmail.com" target="_blank">jaime.frio@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Mon, Jun 8, 2015 at 3:11 PM, Jaime Fernández del Río <span dir="ltr"><<a href="mailto:jaime.frio@gmail.com" target="_blank">jaime.frio@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">I have just unsuccessfully tried to build numpy under Windows for Python 3.5, using the latest release candidate for Visual Studio 2015.<div><br></div><div>A very early failure with a:</div><div><br></div><div>RuntimeError: Broken toolchain: cannot link a simple C program</div><div><br></div><div>even though repeating the sequence of commands that lead to the failure manually seems to work.<br><div><br></div><div>Anyway, before diving deeper into this, has anyone tried this out already and have some success or failure stories to share?</div></div></div></blockquote><div><br></div></span><div>I have finally managed to get this to compile. There are two places at which things go wrong:</div><div><ol><li>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.</li><li>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.<br></li></ol><div>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.</div></div><div><br></div><div>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.</div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span></div></div></div></blockquote><div><br></div><div>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.<br><br></div><div>Chuck <br></div></div></div></div>