Skip to content

Conversation

ehaupt
Copy link
Contributor

@ehaupt ehaupt commented Apr 20, 2023

FreeBSD installs libsecp256k1 as:

/usr/local/lib/libsecp256k1.so.2.0.1
/usr/local/lib/libsecp256k1.so -> libsecp256k1.so.2.0.1
/usr/local/lib/libsecp256k1.so.2 -> libsecp256k1.so.2.0.1

FreeBSD installs libsecp256k1 as:

```
/usr/local/lib/libsecp256k1.so.2.0.1
/usr/local/lib/libsecp256k1.so -> libsecp256k1.so.2.0.1
/usr/local/lib/libsecp256k1.so.2 -> libsecp256k1.so.2.0.1
```
@accumulator
Copy link
Member

LGTM

@accumulator accumulator merged commit fd6e34b into spesmilo:master Apr 20, 2023
@ehaupt ehaupt deleted the fixfreebsdsecp256k1loader branch April 20, 2023 08:54
@SomberNight
Copy link
Member

I think this might be the wrong approach. I am not sure the root cause has anything to do with freebsd.
Looks like secp256k1 released/tagged 0.3.0 and 0.3.1 recently. I think your freebsd install simply updated to 0.3.1 super fast: when I try building tag 0.3.1, I get library_names='libsecp256k1.so.2.0.1 libsecp256k1.so.2 libsecp256k1.so' (in dist/lib/libsecp256k1.la).
Our dynamic loading of this library was last updated when they released/tagged 0.2.0 in December, where I saw library_names='libsecp256k1.so.1.0.0 libsecp256k1.so.1 libsecp256k1.so'.
Based on the changelog, tags 0.2.0 and 0.3.x are not ABI compatible.

SomberNight added a commit that referenced this pull request Apr 21, 2023
this replaces #8320

see https://github.com/bitcoin-core/secp256k1/blob/f6bef03c0a2c826227708dbeaecf1dbc702a2567/CHANGELOG.md

I am not yet sure how this will look like going forward, but unless there will
be lots of libsecp256k1 releases with ~invisible harmless ABI changes, I think
conceptually this is the right approach.
@SomberNight
Copy link
Member

pushed a follow-up in 784fc27

@SomberNight SomberNight added this to the 4.4.1 milestone Apr 21, 2023
SomberNight added a commit to SomberNight/electrum that referenced this pull request Apr 21, 2023
We don't actually need the development headers, instead using this as
a hack to be agnostic to the version scheme and pull in the latest.

related:
spesmilo#8185
spesmilo#8320
spesmilo#8328 (comment)

debian 11 (stable) only has libsecp256k1-0
debian 12 (testing) atm only has libsecp256k1-1
ubuntu 23.04 only has libsecp256k1-1
I expect libsecp256k1-2 might soon get packaged too, now that upstream secp released v0.3.0.
So what do tell users to install? well, turns out most distros have libsecp256k1-dev, which
just pull in the latest secp.
Caveat: if there is a new secp release that actually gets packaged on a distro before we can react,
then this new instruction will not work.
SomberNight added a commit to SomberNight/electrum that referenced this pull request Apr 21, 2023
We don't actually need the development headers, instead using this as
a hack to be agnostic to the version scheme and pull in the latest.

related:
spesmilo#8185
spesmilo#8320
spesmilo#8328 (comment)

debian 11 (stable) only has libsecp256k1-0
debian 12 (testing) atm only has libsecp256k1-1
ubuntu 23.04 only has libsecp256k1-1
I expect libsecp256k1-2 might soon get packaged too, now that upstream secp released v0.3.0.
So what do we tell users to install? well, turns out most distros have libsecp256k1-dev, which
just pulls in the latest secp.
Caveat: if there is a new secp release that actually gets packaged on a distro before we can react,
then this new instruction will not work.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants