Re: Better soname linking

[Ralf Wildenhues]

Hi Jan,

* Jan Engelhardt wrote on Sun, Oct 25, 2009 at 03:00:27PM CET:
> just today I stumbled over an issue where I think that the way 
> -version-info is encoded into the library and/or filename is not that 
> perfect after all.
> 
> ---8<---
> parent 741a9867eb71eb258ca1ed5b85bc7f03ce864195 (v2.2.6-150-g741a986)
> commit 34a9ed656c08625f975913b74bdc995ff2d18610
> Author: Jan Engelhardt <address@hidden>
> Date:   Sun Oct 25 13:26:58 2009 +0100
> 
> Create symlinks to all API versions and set soname to highest
> 
> -version-info 23:0:1 will create a libfoo.so.22.1.0 and there is a
> symlink libfoo.so.22 to it, so that programs originally linked for
> v22 continue to work with a v23 that implements APIs 22–23.
> 
> However, a program that uses functions from API 23 is still linked
> against libfoo.so.22. In other words, you could deploy this program
> on a system which only has libfoo.so.22.0.0 — and package managers
> will happily do that without upgrading libfoo to so.22.1.0 —, thus
> potentially rendering essential system services unusable without a
> warning until it is too late:
> 
>  program: unknown symbol api23_function in libfoo.so.22
>  (or similar wording)
> 
> This proposed solution includes changing the encode the highest
> version as the soname, so that new programs always link against the
> latest one. Appropriate symlinks for all API verisons will then be
> provided so that programs previously linked continue to work.

Wow.  This would be a heavy change.  Basically any change that causes
different sonames on a widely used platforms will cause so much churn
downstream, and effectively an ABI flag day, that I am very to go this
way unless there is really no other way; and even then only with very
good preparation and lots of positive feedback from distributions.

Can't we use some other method to make it obvious to the distributor
that libfoo has gone from 22.0.0 to 22.1.0?  Automatic shared library
checkers are common in distributions, it should be possible to amend
them for this kind of issue, even if they need to look at the .la file
for such a thing.

Thanks,
Ralf