Open muexxl opened 3 years ago
Can you try this? https://www.piwheels.org/project/coincurve/
Hi, the link does not provide a specific file. So I tried the following two files:
wget ../coincurve-13.0.0-cp37-cp37m-linux_armv7l.whl
pip install coincurve-13.0.0-cp37-cp37m-linux_armv7l.whl
Produces: ERROR: coincurve-13.0.0-cp37-cp37m-linux_armv7l.whl is not a supported wheel on this platform.
wget ../coincurve-13.0.0-0rc1p37-cp37m-linux_armv7l.whl
pip install coincurve-13.0.0rc1-cp37-cp37m-linux_armv7l.whl
Produces: ERROR: coincurve-13.0.0rc1-cp37-cp37m-linux_armv7l.whl is not a supported wheel on this platform.
I also tried renaming the files to ..cp38.. because of Python 3.8. but this didnt change anything.
Hi, same problem here :_libsecp256k1.cpython-38-arm-linux-gnueabihf.so: undefined symbol: secp256k1_ecdh Same OS (fully updated) : Ubuntu 20.04.1 LTS Python : 3.8.5 ARM architecture : armv7l (Odroid-HC2 board)
The problem is present with 'pip install' but not with 'python setup.py install' on master branch.
Same problem, Mac os Big sur 11.1, macbook pro M1
[EDIT: old version visible in edit history]
On my system, this was because I had a system-wide version of libsecp256k1 installed which was not built with --enable-module-ecdh
, that was getting pulled in during build by distutils' linker flags. Unsure what should happen here, but it's good to identify as the issue. One solution might be to build the coincurve library with a unique name so the system library doesn't get pulled in.
Thanks!
One solution might be to build the coincurve library with a unique name so the system library doesn't get pulled in.
Interesting, can you explain a bit what that might entail?
For example, there could be a build a step after configure is run in build_clib
in setup.py, that renames, copies, or symlinks the "libsecp256k1.a" to e.g. "libcoincurvesecp256k1.a", and then the new name would be passed to cffi at the bottom of _cffi_build/build.py
.
Somebody more familiar with part of this infrastructure than I am might know a cleaner solution. Sorry if my spazzy pursuit of a ghost issue in distutils spammed you guys while I was figuring the build error out.
@ofek I suspect that this originates from the way build_ext pulls-in the build_clib output. The extra_linker_args appends to the predefined linker command. With the latest revisions we've made to facilitate running within conda, this is likely to occur again.
Is this something we want to safeguard against with the static builds? We could simply force-feed the library when we link (instead of letting the linker pick a possible wrong one)
I think we should prevent this for the default static builds yes, if possible!
Ok, I will look into it and implement it in the CMake PR. My thoughts are to use the COINCURVE_IGNORE_SYSTEM_LIB
to force linking of the "just compiled" llibsecp256k1 rather than any installed one, but testing it might be a bit tricky to implement
Dear all, I would like to use coincurve on my Raspberry Pi4 Model B.
Installation works flawless via
pip install coincurve
I also tried not using wheels: Installation works flawlesspip install coincurve --no-binary :all:
But when opening a python interpreter and trying to import the module I get an ImportError:
System information:
python --version:
/etc/os-release:
sudo sdhw --short: