Missing working example for ctypes dll building #20
Comments
|
Have you seen my example? https://github.com/mdavidsaver/setuptools_dso/tree/master/example Your stackoverflow post looks like Windows, but I don't see any dllimport/export in your code. cf. the usage of https://github.com/mdavidsaver/setuptools_dso/blob/master/example/src/mylib.h |
|
Thanks for your quick response! I have seen your example, but in my use case, I am trying to include c-code which is not written for the Python package, i.e. I cannot add includes in the header file. I would like it to work on both linux and windows, as it's a shared package. |
dllimport/export are not specific to Python or setuptools_dso. This is the MS recommended way to define the external interface of a DLL.
Fair enough, this is a common constrain when packaging.
I think the place for you to start is understanding what the Makefile is doing. It is likely passing some extra flags to the compiler and/or linker. Or perhaps a .def file is used for the DLL build? Once these additional inputs are defined, they can be passed to eg. for GCC/mingw you might look for |
|
Thanks for the helpful reply! I've worked a bit to find out what I'm missing. I've made a reference Makefile that can produce the desired shared library. However, while I with the Makefile using minGW can make libraries for Windows, but when using Microsoft Build Tools (called via setup.py / setuptools_dso), I have found out that the shared argument is not support by this compiler, so the dll generated when calling from Windows does not work. During build, I get: |
|
Oh dear, Cygwin... I should have asked explicitly about your environment. I don't test with cygwin, so I'm not surprised that you are encountering problems. I should warn you up front that adding support for cygwin would likely to be an involved process, and might not even be possible. Some of the tricks I play may conflict with what Cygwin does to partially emulate ELF loader behavior on Windows. Would you be able to switch to native mingw or MSVC, or WSL, or really anything else? I think you will have a happier life in general without cygwin (I have ;) ). fyi. If you want to pursue cygwin further, please attach the full output of eg. |
|
You're right! I must just not have tested it cleanly in linux. Okay, so my current issue is, that it works without any compile-flags at all when installing the package using setup.py in linux, however, I get the following error when installing in windows (compiled with setuptools_dso, i.e. MSVC): So something is not working with the MSVC compiler. I do try to minimise my use of cygwin, which is some of the reason making this work would be great - I then won't have to add another dependency to the team needing the package(s). Would it help if I add the DSO to an Extension instead? What would be required then? |
|
@mdavidsaver, any idea as to what is missing for getting the MSVC compiler to work? |
|
I think I might be running into the issue discussed here (or at least related to it): https://stackoverflow.com/questions/225432/export-all-symbols-when-creating-a-dll/32284832#32284832 Currently, I have difficulties seeing a way to have an automated way of building this using the setuptools_dso (and MSVC in general), unless setuptools_dso could help automatically generating a .def file for the linker to export all symbols or something like that. |
|
I agree that what you, and that stackoverflow chain, describe is what happens when a symbol is not exported (by dllexport decoration, .def file, or |
Hello
I am trying to make a minimum working example of automatic building of a standard c-code library for import with ctypes, as per this post stack-overflow post: https://stackoverflow.com/questions/62388018/installing-pure-c-library-for-python-package
Someone suggested this package, and I have been trying to make it work, as per this branch: https://github.com/mkielg11/ctypes_distribution/tree/fix-using-setuptoolsdso
However, I have two issues:
I though maybe you could help making a viable example of how to use your package?
The text was updated successfully, but these errors were encountered: