search

ElementsProject / libwally-core

Useful primitives for wallets
Other
282 stars 135 forks source link

add `-version-info` to `LDFLAGS` in shared library builds #415

Closed whitslack closed 1 year ago

whitslack commented 1 year ago

version-info is what determines the dotted triplet of numbers trailing the shared library filename. Meticulous maintenance of version-info allows multiple ABI versions of the library to be installed on a system concurrently and also makes obvious when library clients need to be recompiled for a newer ABI (and when no recompilation is necessary).

See: https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html

jgriffiths commented 1 year ago

I am willing to apply this patch and attempt to follow the given rules for updating the version numbers, which should hopefully be enough for packagers to update dependent packages when the ABI is changed.

However the extra work to properly support multiple library versions in a shared install is not going to be feasible I think. AFAICS this would require including the semver in the so file name (to fix static linking) and version-namespacing the header installs.

whitslack commented 1 year ago

However the extra work to properly support multiple library versions in a shared install is not going to be feasible I think. AFAICS this would require including the semver in the so file name (to fix static linking) and version-namespacing the header installs.

@jgriffiths: It's not something that you would need to concern yourself with. If you adopt sanitary library version-info, then downstream package maintainers can shard installations of your library at various ABI levels. Even on Gentoo it's very rare for library packages with multiple slots to support building against any slot other than slot 0, which is typically reserved for whichever slot installs the singular copy of the header files and claims the unversioned shared object name (.so with no numeric suffix). Nevertheless, it's possible for downstream packagers to tweak the install paths and .pc files so as to have installed multiple sets of headers (and static libraries if one insists on such anachronism) in parallel on the same system. Many times I have considered doing just that for libwally-core because Core Lightning is very slow about adapting to API changes in libwally-core, such that any Gentoo system with Core Lightning installed is perpetually unable to keep up with the latest libwally-core, as the Core Lightning installation always pins an outdated libwally-core version. But again, that's nothing that you should concern yourself with.

jgriffiths commented 1 year ago

If there is no further work required on my end then this sounds great. I think in the near future it would be good to split out the docs and to provide some documentation on good practices for packaging. I believe you are the first to do so but there will be others in due course no doubt.