Issues with getting fastecdsa working in Windows #11
Comments
|
Yes, I suppose it's not explicitly stated in the README (which it probably should be), but the package isn't written with Windows in mind as one of the target OSes. This is precisely because compiling the C extensions on Windows is a major pain, the main issues which you've touched on already (installing GMP on Windows is a nightmare and the C compiler for Python isn't anything to write home about either). Does MPIR expose the same functions / interface that GMP does or did you have to rewrite all the GMP library calls to MPIR calls? |
|
MPIR was basically a drop-in replacement - just have to rename |
|
Understood. I can try to see if I can make the configuration / setup process play nice with Windows, but I can't promise any results. Ideally it would be nice to be able to just |
|
I try this steps:
Well, first part done as ymgve say,
after this process |
|
Here is pre compiled versions for Windows https://github.com/ChillMagic/MPIR-Binary |
|
Able to build and install but something is still going wrong - $ python setup.py build
$ python setup.py install
$ python setup.py test
running test
Traceback (most recent call last):
File "C:\Python27\lib\runpy.py", line 174, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "C:\Python27\lib\runpy.py", line 72, in _run_code
exec code in run_globals
File "C:\Users\A\Desktop\fastecdsa\fastecdsa\test.py", line 13, in <module>
from .ecdsa import sign, verify
File "fastecdsa\ecdsa.py", line 4, in <module>
from fastecdsa import _ecdsa
ImportError: DLL load failed: The specified module could not be found.Continuing to investigate... (as you can probably tell I don't do much development on the Windows platform so if I'm missing something obvious please let me know) |
|
Probably, "setup.py install" doesn't pack _ecdsa.pyd to egg file or egg file not yet in Lib\site-packages\ |
|
I'm getting the |
|
As I checkout my working machine, _ecdsa.dll not used at all. I have this file only at build dir and after removing this folder, scripts works as usual. |
|
I had the same error. To fix it, just put |
|
Here is somthing interesting - I have not directory of package, .\Lib\site-packages\fastecdsa just egg file in .\Lib\site-packages |
You can just copy |
|
Hello, I encountered same problem, but solved. |
|
You need to have an microsoft visual 2019 and Microsoft c++ in visual studio
|
|
Per @naphy0's suggestion, i've (probably) gotten a build fully working by doing the following steps:
And all of that resulted into a successful test. |
|
I pushed a commit to my fork that has the prerequisites all ready for a windows build, the only thing that needs to be installed is buildtools from here, under "Tools for Visual Studio 2019". (plus the C++ build tools) If any contributor from here can please pull on a windows machine, build, and confirm the library works as intended, please let me know. This library is required in libp2p, and currently any windows build will fail because of a |
|
Im currently on travel but will verify on my Windows VM as soon as I am able. Thanks for your work toward getting this package building on Windows! |
|
I've also been poking around looking at automated wheel builds for windows in general, this setup has worked on my normal desktop computer (due to some other options not wanting to work before), so I am not 100% sure either about this configuration working all the time, nor if the produced library is stable enough for use.
No problem! |
|
I've confirmed that building it like this only works with 32-bits python installs, anything 64-bit ( (this is after adding extra libraries under |
|
I changed all libraries from 32-bit and 64-bit compile now (on two windows machines), the 64-bit one spits many warnings that're probably interesting to look at, but other than that, tests for both succeed. (side-note, just changing the |
|
Was able to get your branch to build locally (only with python3, the compiler python2 wants is quite old). Since python2 is EOL in less than a month I will fold this into the Thanks for everyone's efforts towards getting this working on Windows, it took some time but we're almost there. |
|
All of my efforts are in https://github.com/ShadowJonathan/fastecdsa-any/tree/win32 and instructions on how to make it work are this and this comment (disregard the commit link in the last comment) I've only bundled MPIR with that branch to quickly test it on multiple machines, the exact instructions on where which files come from are in my previous comments, the actual repository where the binary files are stored is https://github.com/ChillMagic/MPIR-Binary I've managed to build this on 3.7-32-bit, 3.8-32-bit, and 3.8-64-bit, altough all builds worked and tested (successfully), the last build gave a few warnings. I've not been able to discern any stability issues whatsoever, but that doesn't mean they cannot be there, I've never tested the builds beyond the default test suite. |
|
(oh whoops, did not read message in its entirety) |
|
Yeah I think the way forward is to update the documentation to state which steps need to be taken if you wish to build from source on Windows rather than via a wheel. The test suite has pretty good coverage so I'm not too worried about stability issues (beyond the known issues in the tracker here) but I suppose as more people use it on Windows things will be reported if they're there. I should also clarify that I can't speak to 32 bit machines as I only have a 64 bit machine available to test with currently. |
I had to do an additional step: It was looking for gmp.lib there, not in C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.21.27702\lib\x64 |
|
I hope it will be helpful for those who build with github actions. |
|
Compilation of [gmp] is now very easy, and [mingw64 + msys2 + vcpkg] can be mixed with future tool chains. But [fastecdsa] still can't compile, very distressed |
|
Tbh at this point in time I would just recommend getting it working in GHA with cibuildwheel and call it a day |
|
Building a wheel vi cibuildwheel for windows is non trivial because of the third party native libs that need to be set up. We can't use e.g. I did manually build a wheel for tag Steps I used are what @naphy0 recommended above -
|
|
The trickiest part about building locally IMO is getting GMP into a directory that the C compiler / linker has on its path when it builds the project. I don't know enough about windows wheels to be able to say if wheels solve this problem by normalizing the path for the native third party libs. If someone who is not able to build the project from source could check if the wheel solves their issues that would be appreciated. It seems like adding additional |
...why is that a problem? You can use choco / winget if it's stored there, or manually download and run the installer from the command line (yes, it's possible if it's based off of installshield and the likes), or just hack around and store files in the correct locations. It only needs to be reproducible once for it to be reproducible forever after, I highly recommend looking into it. |
|
Are any of those tools available on the build hosts that cibuildwheel uses? Feel free to create a PR to update the existing build config to do what you recommended above. Again, Windows isn't my standard development OS, and while I do want to support Windows developers in this package I'm not the best person to implement the tooling. |
|
I might make a PR, I'll add it to my todo list |
|
Update: I've taken a look at the package manager options, and so far only vcpkg seems to support a simple install, according to this SO answer |
|
|
I've come basically as far as this CI run, with this workfile, but it gets stuck on some building error/problems wrt it not finding if anyone can take a look that'd be amazing |
|
Taking a look, it seems like it's able to find the GMP headers but not the library. The output is showing that the object files are being created, but it appears linking is failing when it tries to resolve the GMP symbols. |
There are some issues getting the module working in Windows - I found fixes, but they aren't very elegant:
Microsoft Visual C++ Compiler for Python 2.7package doesn't seem to support C99 style variables, so I had to move all variable declarations to the start of functions.free()ing the buffer returned frommpz_get_str()- seems to be because memory allocators in different VC runtimes are sometimes incompatible. Changing thefreeto__gmp_default_freefixed this issue.The text was updated successfully, but these errors were encountered: