import error on RasberryPi 4B

[muexxl]

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]

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

[muexxl]

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]

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]

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

[Dzianissmit]

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

[xloem]

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

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]

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]

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

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

[MementoRC]

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