-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Unable to cross compile due to cffi (from pyopenssl) #1325
Comments
The issue is with how cffi works (see the bold part in this comment). The issue with cryptography importing itself to trigger compilation of ifs extensions through cffi. This is a major design flaw IMO. |
We've had some discussions in the past about the way we currently use cffi, but I believe we've mostly been in a holding pattern waiting on cffi 1.0 (which has the removal of compile on import as a design goal). /cc @dstufft |
It's not a requirement that importing triggers the compilation, but you have to be very careful not to trigger it. Cryptography could do what I've done in my own projects and disable the implicit compile all together and only allow compiling via |
I'm not strictly against this, but I want to make sure we integrate it into On Thu, Sep 25, 2014 at 1:19 PM, Donald Stufft notifications@github.com
"I disapprove of what you say, but I will defend to the death your right to |
Please tell me when I can test against master |
@dstufft Can you point me to one of your projects that disable the implicit compile step? I'll see what I can do with this. |
https://github.com/dstufft/http11/blob/master/src/http11/c/__init__.py#L102-L156 The important part here is that by constucting a Verifier manually we skip the implicit compile that the verify call does. The Library class just acts like a lazy proxy that will ensure that the library is loaded (and that using the Verifier's compile method raises an error) but will only load it once an attribute is accessed instead of on import. Then the important thing to do is make sure that importing never accessing one of those attributes. |
I believe this is fixed now; going to close the issue, if there's any new issues let's file a new issue. |
Is this in a release already or do I need to use master? |
No, it's not in a release yet; it'll be in the next one. On Sat Nov 15 2014 at 10:06:24 AM Antoine Bertin notifications@github.com
|
I still have problems cross-compiling cryptography in Buildroot. I've tried both 0.7.2 release and master branch, but I always get the issue with _cffi_backend.so:
|
Hello, Has this been resolved yet? It still fails in Buildroot during cross-compilation. Tried version cryptography 0.9.1 and cffi 1.1.2. Traceback (most recent call last): Any help would be appreciated! |
I've got the same error when cross-compiling using OpenEmbedded build system: |
This also affects my project while trying to cross-compile
|
@alexykot what happens if you use the master branch rather than 0.9.3? |
Just tried that, same thing happens.
Do you need full traceback? |
No, this looks like it might be something cffi has to handle. This is outside my experience so I'm not sure how to go about debugging it though. |
Bummer. OK, I'll try to get to cffi about this. Thanks for swift reply.
|
@reaperhulk @alexykot I don't think it's a cffi issue. I tried to cross compile for a 32 bit system from a 64 bit system. cffi module _cffi_backend.so compiled OK for the target (that is 32 bit). The problem is that when cryptography tries to pre-cross compile (for 32 bit) cffi modules (Cryptography_cffi*.so), it uses (host) 64 bit compiler flags and tries to load the 32 bit cross compiled _cffi_backend.so. This is why you get "wrong ELF class: ELFCLASS32". There needs to be some way to configure the C compiler flags from within the cryptography package while cross compiling the cffi modules. You can see how cffi module itself is allowing that in its setup.py file. Another python package I was able to configure the target c flags is python readline. I got around this problem (dirty hack) by skipping the cffi modules pre-cross compilation process (Cryptography_cffi*.so) and copying (during the build time) those modules I compiled on the target system. |
This sounds like the sort of thing that should be possible via setuptools magic. @dstufft? |
Well I could get it working myself by following midicase comment on vincentbernat/snimpy.
|
Cool, I'll try this workaround asap and see if it would work. |
@vtmram FYI: python-cryptography and python-pyopenssl were both taken into Buildroot's next branch (https://git.busybox.net/buildroot/commit/?h=next&id=fbeeb4c8cb4e44c654ca27db9ae05a83202f4104) As @AndreMiras pointed the trick was to install both host and target versions of CFFI. See python-cryptography for details. |
More information here: pyca/pyopenssl#157
Le me kow if we should continue the discussion here or in the pyopenssl issue.
The text was updated successfully, but these errors were encountered: