On Wed, 26 Jan 2022 22:08:43 -0300
"Pedro Lucas Porcellis" <porcellis_AT_eletrotupi.com> wrote:
Dear Pedro,
> While packaging libgrapheme for Alpine, it was pointed out that the
> generated .so file isn't versioned, which apparently it is not bad,
> but it was questioned why. I don't know if it's a slip or if it's a
> deliberated choice.
>
> If the latter, I would like to know it's reasoning, so I can justify
> that to the Alpine Linux developers and possible get the library
> merged soon.
this is a deliberate choice, here's why: I take great care to keep the
API stable and only add new functionality, which means that you can
rely on a given function to exist in later versions.
Say you develop your program against libgrapheme-1 and libgrapheme-2 is
released, the package manager replaces the .so but all the symbols you
were using are still present. So the only thing you need to specify is
which minimum version you need (the one where the function you were
using appeared first).
I actually see little reason to have versioned .so-files (unless I
misunderstand something). This pretty much kills any advantage they
have over static linking, and I very often encounter issues with binary
packages not working on my system because they rely on
libsomething.so.4 while I have libsomething.5. This might all have a
certain purpose for large projects where the ABI changed a lot across a
major version, but libgrapheme is not a major multi-million-dollar
project and I'll approach it in a "Kelvin" way where the API cools down
over time.
All in all, I generally also see it as the package manager program's
responsibility to make sure dependencies are met. While I do understand
the notion that you can "prevent" silent ABI breaks with
.so-versioning, this, to me, more shows the fundamental problem with
dynamic linking.
With best regards
Laslo
Received on Fri Jan 28 2022 - 10:12:08 CET