Closed th0ma7 closed 2 years ago
This is a cross-compile error with cffi
, which pyNaCl does depend on, but is not something we control.
I was able to found the reason why: crossenv
Our build framework starts by building a minimal python38
and includes the necessary wheels, including crossenv
.
It happens that all version >=1.0 of crossenv
makes PyNaCl to fail to build in our cross-compiling environment, only for x86_64
architecture.
I presume that crossenv
has a bug that gets triggered in cross-compiling environment where if the target is of the same arch of the host it goes outside of its boundary instead of using the passed library paths of our toolchain.
While preparing an update for our python-3.8 package for Synology NAS (uses linux called DSM), the CI was able to cross-compile all packages and dependencies with the only exception, cross-compiling x86_64 (all builds are done from a x86_64 host docker image). My initial thoughts are that it somehow loose track of the library path, hence trying to find
libffi.so
from the host default path (but I may well be wrong).PR is https://github.com/SynoCommunity/spksrc/pull/4902 and last CI run is https://github.com/SynoCommunity/spksrc/pull/4902/checks?check_run_id=3858396685 where it failed only on x64 arch for DSM version 6.1 and 7.0. All packages are built using Synology toolchain for each associated architectures.
Using version 1.4.0 from https://pypi.org/project/PyNaCl/ or latest snapshot from github gets to the exact same error.
Cross-compiling using following versions:
python
: 3.8.12libffi
: 3.4.2cffi
(pip/wheel): 1.14.6, 1.14.5PyNaCl
: 1.3.0, 1.4.0, github-masterEnd of the build error:
While the libraries are available:
And the
work-x64-<DSM-version>/install/var/packages/homeassistant/target/lib
is part of the library path.