--- Log opened Fri Apr 21 00:00:38 2023
05:33 -!- preimage [~halosghos@user/halosghost] has joined #secp256k1
06:03 < ghost43> hi! I am looking for some clarification re how the versioning scheme works. In particular, how a user (other software) of this library that dynamically loads secp as a .so is supposed to do so in this era of versioned releases :) when I build from the v0.3.0 (or v0.3.1) tag, the built .so is named .so.2; for v0.2.0 it was .so.1, and in the long-lived pre-releases age it was .so.0. Prior to v0.2.0, we (electrum) were dynamically loading 
06:03 < ghost43> hard-coded .so.0, and then after v0.2.0 changed that to try .so.1 first, then fallback to .so.0. Now with v0.3.x, there is also .so.2 to try. Looking at the release notes, I see v0.3.x is not ABI compatible with v0.2.0, so I guess that explains the autotools .so version bump (?). I've just run our test suite with .so.2 and as expected from the release notes, the ABI changes were invisible to us. but we as downstream user now have to update 
06:03 < ghost43> code to also try loading .so.2, and maybe do a new release (see e.g. https://github.com/spesmilo/electrum/pull/8320 where there is btw some confusion in the first comments/changeset). I suppose we should not try to load .so.*, because that would make the versioning pointless. I don't quite understand the "semantic versioning" claim either, when I look at the version numbers used (maybe that's due to API/ABI distiction?). in part I am just 
06:04 < ghost43> wondering, are .so.x version bumps going to be a "regular" thing?
06:05 < sipa> So file names under linux have their own numbering scheme, which is distinct from the source code versioning we use.
06:09 < sipa> It's determined by the library version we provide to libtool, and I believe that ABI incompatibilities do cause the number after so.x to increase there.
06:11 < ghost43> I assume, putting aside .so.0 that had "no stable api", that if an .so.A is tested and works with a given usage then *any* .so.A should also work. e.g. tags v0.3.0 and v0.3.1 both build .so.2, and from a library user point of view if the first one tests okay, the second one should also be fine to dynamically load. is this correct?
06:11 < hebasto> ghost43: here is an examples how it works -- https://github.com/bitcoin-core/secp256k1/pull/1055#issuecomment-1227505189
06:18 < sipa> @ghost43 I believe that's correct, but as hebasto points out, the conventions for naming/installing dynamic libraries do differ a lot across operating systems.
06:19 < ghost43> hebasto: thank you for taking the time to create that table.  so looking at it, it looks like only "backwards incompatible" changes bump .so.V
06:20 < sipa> Also, the fact that this causes problems for you is useful feedback for us. I don't think we considered the impact of a technically-incompatible-but-not-affecting-most-applications change.
06:20 < ghost43> maybe a better way to phrase my main question: is it possible to build bitcoind so that it dynamically loads secp and if so what .so names does it look for then? or does bitcoind always use the in-tree secp?
06:20 < hebasto> ghost43: that's the rule
06:20 < sipa> In fact, I wasn't even aware that anyone was using libsecp256k1 as a dynamic library at all.
06:20 < sipa> @ghost43 Bitcoin Core uses a pinned statically-compiled verdion of libsecp256k1.
06:21 < ghost43> I see
06:27 < ghost43> as clarification from my side, electrum binaries of course bundle a pinned version of secp and use that (though still via dynamic loading), however when running from source it is up to the user to provide secp (however there is a script for such users, contrib/make_libsecp256k1.sh, which build a pinned version and places the copy inside the git clone)
06:29 < sipa> The situation is also perhaps harder for you as you're manually loading a dynamic library at runtime. If you have a compiled binary doing dynamic linking, the library information is determined by the compiler in a platform-specific way.
06:30 < sipa> So if e.g. Bitcoin Core would be using libsecp256k1 dynamically, nothing in its source code would need to know or care about which versions/files to use; it'd just be linked against whatever version was available at compilation time, and the OS would make sure a version compatible with that one was provided at load time.
06:32 -!- jonatack1 [~jonatack@user/jonatack] has quit [Ping timeout: 246 seconds]
07:05 -!- jonatack1 [~jonatack@user/jonatack] has joined #secp256k1
07:15 -!- jonatack1 [~jonatack@user/jonatack] has quit [Ping timeout: 240 seconds]
07:40 -!- jonatack1 [~jonatack@user/jonatack] has joined #secp256k1
07:40 < real_or_random> sipa: > In fact, I wasn't even aware that anyone was using libsecp256k1 as a dynamic library at all.
07:41 < real_or_random> you are surprised that we have users? ^^
07:41 < sipa> No, but I assumed most were statically compiling.
07:41 < sipa> Especially since it hasn't been all that long that we even have well-defined ABIs.
08:03 -!- jonatack1 [~jonatack@user/jonatack] has quit [Quit: WeeChat 3.8]
08:09 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
08:24 < real_or_random> ok, I was aware of electrum at least. also jami uses it. https://archlinux.org/packages/community/x86_64/libsecp256k1/ 
08:24 < real_or_random> hm that package is really outdated now...
10:34 -!- preimage [~halosghos@user/halosghost] has quit [Quit: WeeChat 3.8]
17:37 -!- preimage [~halosghos@user/halosghost] has joined #secp256k1
20:41 -!- preimage [~halosghos@user/halosghost] has quit [Ping timeout: 250 seconds]
21:05 -!- preimage [~halosghos@user/halosghost] has joined #secp256k1
21:59 -!- preimage [~halosghos@user/halosghost] has quit [Quit: WeeChat 3.8]
--- Log closed Sat Apr 22 00:00:39 2023