On Wed, 26 Jan 2022 22:08:43 -0300 "Pedro Lucas Porcellis" <porcel...@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
