New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does not compile under MS Visual C #447
Comments
MSVC v10 (that is for py < 35) reports a failure to find complex.h |
It would seem to sense to look into how other packages that have C extension (e.g. numpy) deal with these issues. |
I have looked into this a bit. Everything compiles fine except the things that require complex.h. VS 15 has this library, and MS even highlights their compatibility with C99. However, others have found that the MS complex type is not compatible with C99. Therefore, one gets a typedef conversion error. Therefore we would have to write a conversion function. Another possibility is to use the Intel compilers. I believe one can get them for free if in academics. |
Thanks for pointing this out. I did not know that this was the case. Ironically the complex numbers are done this way to support compilers (VS in particular) that do not obey C99. The suggested patch is a bit difficult to implement as the runtime generated Cython code is compiled via pyximport and getting in there to change the c files would be a bit tricky. However, I know that the Intel compiler has no problem with the Cython code (at least on Linux). So perhaps that is the way to go for Python 3.5. |
I thought that it was highly recommended to use the same compiler for Also, it would be ideal to try and use a compiler that is available on the On 28 May 2016 at 04:54, Paul Nation notifications@github.com wrote:
|
Well, we have been using mingw for qutip, while the Win Python has always been compiled with VS. while I agree with your statement, using VS seems not to be an option for us. I haven't had any problems in mu minimal testing. |
I agree, I have also not had any problems with mingw. On 31 May 2016 at 21:10, Paul Nation notifications@github.com wrote:
|
According to this thread mingw32 is not going to happen for Py35: But supposedly mingw64 will. The current solution is VS 15 or Intel. I will try to get something cooking with Intel tonight. I will try Anaconda and the Intel Python distro. The later is compiled with the Intel compilers, so hopefully things will work more or less straight forward. |
Actually, it seems that now the Intel distro is built with VS15, and distutils does not know how to handle Intel compilers. However, I am sure that the earlier tech preview was all Intel, and I even had to install the Intel compilers to get anything to build. Regardless, it seems that we need to wait until mingw is supported on Py35. |
The issue is that we need to compile at runtime in Cython using pyximport. I do not know a way to get pyximport to use numpy distutils. |
This is closed. |
Not really expecting anyone to fix this urgently, I am just recording some ideas, as I have spent a lot of time looking into this recently while try to build a conda package
Currently on Windows we compile under mingw. This is sub-optimal, according to various sources, including:
https://wiki.python.org/moin/WindowsCompilers
Python C extensions should be compiled using the same compiler that was used to compile the Python distro that is being used. Failing to do so can result in some strange behaviour. I have experienced issues with qutip tests hanging on Windows. Therefore it would clearly be beneficial if we could build qutip under MSVC. It is of particular interest now that we have a conda recipe that autobuilds for all the version, platform variations.
The text was updated successfully, but these errors were encountered: