-
Notifications
You must be signed in to change notification settings - Fork 71
Windows Support #12
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
Comments
Hi, yes, at the moment it's globally linked, and was easier from the POV of Cython; and while it does make things like supporting multiple drivers more difficult, there's already other multiplexers in existence, in P11Kit, etc. I did consider just using P11Kit's loader, which would remove all need for custom You're right it loads the functions into the global symbol space. I don't know if there an equivalent for
|
dlfcn-win32 supports Otherwise what I think we should do is rewrite loader to produce a struct with all of the functions we need iterated onto it, which could easily use either |
I think a full rewrite may be unnecessary, as dlfcn-win32 looks fully featured enough to be a dropin replacement (I didn't know it existed). Making a struct of functions seems closer to re-implementing P11Kit anyway. |
Are you comfortable enough to give it a go for the Windows Cython build? I've not tried to build Cython on Windows before and I don't have a Windows development env to try it on. |
The build itself "works", just missing dlfcn.h ;) I'll see what I can do - might get some ugly pxds out of it, but it should work. |
Turns out, no dice. I got about as far as my own (separate) pure C implementation, only to be hit by the linker wondering where all the functions were actually implemented. I got around that in pure C by generating a .lib for my driver dll, but that kills cross compatibility, as expected. It seems the only way to be crossplatform is to use some sort of LoadLibrary call or similar. For the moment I'll move back to PyKCS11 - it has a bug that is preventing me from upgrading to Python 3, but 2 isn't so bad :) Thanks for the assistance! I'll close this, since "fixing" the import situation is more trouble than it's worth. |
I'd like to keep it open, since it's a big missing part, and this is a useful record of what we've tried so far. The first thing I would try is linker flags to delay resolving the symbols. Then we can change to accessing the symbols through a handle. For reference: https://joscor.com/blog/load-pkcs11-library-dll-in-c-c/ |
Ok, sounds good! It may be worth noting that the PKCS library has its own function pointer table (at least it seemed that way) which might make assembling all the functions simpler. |
You can create a build package for windows using dlfcn-win32, without need to include as dependency with something like |
Hi, I continue trying to support windows, so I include dlfcn-win32 and try to compile and works to build _loader.pyx, but I have other problem building 'pkcs11._pkcs11' extension My changes are here master...luisza:winbuild
Looking about this error I saw that some errors are for MS Visual Studio 14.0 (python 3.6 is build with this ) Any idea how to solve this ? |
My guess is the problem is here: master...luisza:winbuild#diff-2eeaed663bd0d25b7e608891384b7298L26 There's a bunch of |
Fixed in #33 |
I am using python-pkcs11 in one of my python project which is throwing is throwing error in windows however the same works fine in Linux and OSX. Appreciate if anyone can help me here. |
@jankiraoupada dlfcn should only be imported on Posix. Are you trying to build in Cygwin? That will lead to whacky type sizes and likely a broken result. |
|
0.5.0 does not support Windows. You will need to upgrade.
…On 17 Nov 2020, 10:47 PM +1100, jankiraoupada ***@***.***>, wrote:
> > @jankiraoupada dlfcn should only be imported on Posix. Are you trying to build in Cygwin? That will lead to whacky type sizes and likely a broken result.
I am trying to install a python project (which uses python-pkcs11 -- 0.5.0 ) in my windows 10, which is developed and tested in OSX and linux. I am simply using python virtual environment to setup execution environment, however getting the above error while installing packages.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Thanks Danny, worked after upgrade. |
It would be lovely if I could use this library on Windows, as my driver only comes in dll form.
I'm comfortable with the WinAPI and C, but cython is doing my head in.
Would a potential "easy" fix be using
ctypes.dll.LoadLibrary
, since that's cross-platform? It seems like there might be some boilerplate behind the scenes to cast function types.From what I can tell, the current method loads the symbols globally, which makes it "just work". I can't see any reference to the dll itself past the
load
method.The text was updated successfully, but these errors were encountered: