error: sodium.h: No such file or directory #79
Comments
|
I'm seeing this same behavior when installing pynacl via buildout. What's interesting is that I cannot reproduce it by creating a new virtualenv (either pypy 2.3.0 or cpython 2.7). My only conjecture is that in the OP's environment (and under buildout), the cffi bindings are not getting generated at install time. When attempting to build them at run time, it fails because libsodium is no longer available. I would appreciate being able to point pynacl at a different libsodium anyway than the bundled one. This is possible with other cffi-using projects (pyzmq springs to mind). From an audit perspective, it would be much easier to ensure that the library is legitimate independently. I am testing on OSX 10.9.3 using MacPorts. |
|
@davidblewett I'm not sure about why this is failing (and I don't have time right now to hunt down the problem), but you can tell pynacl to use the system's libsodium instead of the bundled one by setting a environmental variable. https://github.com/pyca/pynacl/blob/master/setup.py#L80 |
|
I don't know if this is relevant, but if I run I really appreciate both of you looking at this. If there was some way I could get this working I'd be so grateful. |
|
@fletom I was able to get this working with a non-bundled libsodium by passing C_INCLUDE_PATH and LIBRARY_PATH environment variables pointing to the correct locations the first time I imported an nacl module that uses a C interface (I chose nacl.signing). For an OS-supplied libsodium on Linux, those would probably be /usr/include and /usr/lib respectively. The first time nacl needs to access a C library, cffi will build the shared object, so you won't need to pass the environment variables explicitly after that. What I'm not sure on is why I have to pass them at all the first time. It seems that the cffi shared object should be built at install time, using the environment passed then. When I install the package using buildout, I have the above 2 variables set so it should be able to do so. |
|
@davidblewett That worked! I had to set all four of the following: Each of these environment variables seems to be strictly necessary, as leaving out even one of them before importing something like Anyways, if this gets fixed someday that's great, but for now I'm happy with having this workaround. Hopefully other people with the same problem will see this. Thank you @davidblewett! |
|
Compilation on import itself seem to be bogus - don't think cffi should do that, and it usually can't do that with module installed system-wide (e.g. in /usr), unless you're importing it as root. I've had the same issue installing PyNaCl from PKGBUILD (having simple Not sure if build working without cffi like that is supposed to be a bug or a feature. |
|
@mk-fg Re compilation, I agree. If it's possible not to compile anything at all on import that would be ideal. I notice that PyNaCl takes a few seconds to import (longer than any other packages) because of this. I'm also seeing this error now on my local machine, when I have |
|
I'm actually seeing this same error when trying to install from the git repo using If you have Docker installed, you can reproduce the error using: This is with pynacl v0.2.3-97-g337a955. |
This removes -e (`pip install --editable`) from the pynacl line in
requirements.txt, and uses git+https:// because pip will break if the
URI isn't in the format `vcs+protocol://...`
This may be related to the following pynacl issue:
pyca/pynacl#79
This removes -e (`pip install --editable`) from the pynacl line in
requirements.txt, and uses git+https:// because pip will break if the
URI isn't in the format `vcs+protocol://...`
This may be related to the following pynacl issue:
pyca/pynacl#79
This removes -e (`pip install --editable`) from the pynacl line in
requirements.txt, and uses git+https:// because pip will break if the
URI isn't in the format `vcs+protocol://...`
This may be related to the following pynacl issue:
pyca/pynacl#79
Summary: Workaround for the "error: sodium.h: No such file or directory" bug in pynacl and/or cffi: pyca/pynacl#79 Fixes #95 Test Plan: `vagrant up --provision` from scratch Reviewers: charles Reviewed By: charles Subscribers: mg Differential Revision: https://review.inboxapp.com/D635
Summary: Workaround for the "error: sodium.h: No such file or directory" bug in pynacl and/or cffi: pyca/pynacl#79 Fixes #95 Test Plan: `vagrant up --provision` from scratch Reviewers: charles Reviewed By: charles Subscribers: mg Differential Revision: https://review.inboxapp.com/D635
|
As I'm bumping into this one again, and there doesn't seem to be a link to a related cffi packaging issue, here it is: https://bitbucket.org/cffi/cffi/issue/109/enable-sane-packaging-for-cffi |
|
With the build changes that went into the recent 0.3.0 release, is this still a problem? I know that 0.3.0 fixed bug I was experiencing, in which a different package that had "install_requires=pynacl" could not be pip-installed. Could you check to see if anything's improved in the new version? |
|
Sorry for very delayed response, but latest releases indeed don't seem to have this issue for me - packaging pre-built module works fine and doesn't trigger rebuild on first use. |
|
great, thanks, I'll close this out. |
ghost
mentioned this issue
PyNaCl installs fine using
pip, but when imported it bugs out saying it can't find a file calledsodium.h.From my understanding, PyNaCl includes libsodium and doesn't need it to be pre-installed on the system. I also tried pre-installing it just to make sure, and got the same error. I also verified that
sodium.hwas found in myLD_LIBRARY_PATH, but no matter what I do I seem to get the same error.Has anybody ever seen this before?
If you would like to reproduce it the exact environment (Heroku) you can do so by running:
The full content of the error I get is as follows:
Thanks!
The text was updated successfully, but these errors were encountered: