README: mention libsodium-dev package

pynacl-1.0.1 has a bug, on systems which have the sodium runtime library
installed (/usr/lib/libsodium.so, as provided by a package like
"libsodium13"), but not the development headers (/usr/include/sodium.h,
as provided by "libsodium-dev"). The pynacl setup.py tries to detect
whether a system libsodium can be used (instead of the bundled copy), by
using cffi to load libsodium.so and check the version strings. However
this test doesn't check that sodium.h is available, which is needed to
build the glue code.

The long-term fix is to change pynacl, either to improve the test (to
look for a header file, which sounds tricky), or to always use the
bundled sodium unless explicitly told otherwise (removing the test
altogether). The short term fix is to tell magic-wormhole builders to
install libsodium-dev if they run into this error, or use the
environment-variable override when installing.

closes #10

refs https://github.com/pyca/pynacl/issues/184
This commit is contained in:
Brian Warner 2016-06-23 11:23:27 -07:00
parent fa29789769
commit f0c32617d0

View File

@ -28,6 +28,12 @@ libffi-dev build-essential`. On Fedora it's `libffi-devel` and
`xcode-select --install` to get GCC. Note: on Windows, only python2 is
currently supported.
If you get errors like `fatal error: sodium.h: No such file or directory` on
Linux, either use `SODIUM_INSTALL=bundled pip install magic-wormhole`, or try
installing the `libsodium-dev` / `libsodium-devel` package. These work around
a bug in pynacl which gets confused when the libsodium runtime is installed
(e.g. `libsodium13`) but not the development package.
Developers can clone the source tree and run `tox` to run the unit tests on
all supported (and installed) versions of python: 2.7, 3.3, 3.4, and 3.5.