Skip to content
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

Closed
ajgpitch opened this issue Mar 4, 2016 · 11 comments
Closed

Does not compile under MS Visual C #447

ajgpitch opened this issue Mar 4, 2016 · 11 comments
Labels

Comments

@ajgpitch
Copy link
Member

ajgpitch commented Mar 4, 2016

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.

@ajgpitch ajgpitch added this to the qutip-3.3.0 milestone Mar 4, 2016
@ajgpitch
Copy link
Member Author

ajgpitch commented Mar 4, 2016

MSVC v10 (that is for py < 35) reports a failure to find complex.h
MSVC v14 (for py35) reports issues with pyx_build (can't remember exactly)

@ajgpitch
Copy link
Member Author

ajgpitch commented Mar 4, 2016

It would seem to sense to look into how other packages that have C extension (e.g. numpy) deal with these issues.

@nonhermitian
Copy link
Member

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.

@nonhermitian
Copy link
Member

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.

@ajgpitch
Copy link
Member Author

I thought that it was highly recommended to use the same compiler for
extensions that is used for python itself? Is this just an ideal rather
than a necessity?

Also, it would be ideal to try and use a compiler that is available on the
conda-forge. Not sure whether the Intel one is or not.

On 28 May 2016 at 04:54, Paul Nation notifications@github.com wrote:

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.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#447 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AIxX7bilAvaPFQKZx8CtnoG8p0DEpaQ_ks5qF7xvgaJpZM4HpJf1
.

@nonhermitian
Copy link
Member

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.

@ajgpitch
Copy link
Member Author

ajgpitch commented Jun 1, 2016

I agree, I have also not had any problems with mingw.
The only issue seems to be that it won't work with python 3.5. Perhaps they
will fix that and solve our problem that way.

On 31 May 2016 at 21:10, 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.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#447 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AIxX7eTvGa_WbL8VzcQgAqIkgCEEI8heks5qHJXGgaJpZM4HpJf1
.

@nonhermitian
Copy link
Member

According to this thread mingw32 is not going to happen for Py35:

statsmodels/statsmodels#2751

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.

@nonhermitian
Copy link
Member

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.

@nonhermitian
Copy link
Member

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.

@nonhermitian nonhermitian removed this from the qutip-3.3.0 milestone Sep 12, 2016
@nonhermitian
Copy link
Member

This is closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants