search

ofek / coincurve

Cross-platform Python bindings for libsecp256k1
https://ofek.dev/coincurve/
Apache License 2.0
151 stars 47 forks source link

import error on RasberryPi 4B #71

Open muexxl opened 3 years ago

muexxl commented 3 years ago

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 flawless pip install coincurve --no-binary :all:

But when opening a python interpreter and trying to import the module I get an ImportError:


import coincurve

ImportError: /home/bit/joinmarket-clientserver/jmvenv/lib/python3.8/site-packages/coincurve/_libsecp256k1.cpython-38-arm-linux-gnueabihf.so: undefined symbol: secp256k1_ecdh

System information:

python --version:

Python 3.8.2

/etc/os-release:

NAME="Ubuntu" VERSION="20.04.1 LTS (Focal Fossa)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 20.04.1 LTS"

sudo sdhw --short:

H/W path Device Class Description

                             system     Raspberry Pi 4 Model B Rev 1.1

/0 bus Motherboard /0/1 processor cpu /0/2 processor cpu /0/3 processor cpu /0/4 processor cpu /0/5 memory 1863MiB System memory /0/0 bridge Broadcom Inc. and subsidiaries /0/0/0 bus VL805 USB 3.0 Host Controller /0/0/0/0 usb1 bus xHCI Host Controller /0/0/0/0/1 bus USB2.0 Hub /0/0/0/0/1/2 scsi0 storage External /0/0/0/0/1/2/0.0.0 /dev/sda disk 500GB External /0/0/0/0/1/2/0.0.0/1 /dev/sda1 volume 465GiB EXT4 volume /0/0/0/1 usb2 bus xHCI Host Controller /1 eth0 network Ethernet interface /2 wlan0 network Wireless interface

ofek commented 3 years ago

Can you try this? https://www.piwheels.org/project/coincurve/

muexxl commented 3 years ago

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.

BitcoinTsunami commented 3 years ago

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)

BitcoinTsunami commented 3 years ago

The problem is present with 'pip install' but not with 'python setup.py install' on master branch.

Dzianissmit commented 3 years ago

Same problem, Mac os Big sur 11.1, macbook pro M1

xloem commented 2 years ago

[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.

ofek commented 2 years ago

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?

xloem commented 2 years ago

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.

MementoRC commented 5 months ago

@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)

ofek commented 5 months ago

I think we should prevent this for the default static builds yes, if possible!

MementoRC commented 5 months ago

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