Re: obsoleting shlibs - what's the plan

[Havard Eidnes <he%netbsd.org@localhost>]

> In practice, you can in some circumstances end up with multiple major
> versions of the same lib loaded at once, and with standard ELF that
> pretty much inevitably results in nasal demons.
>
> This is what can happen:
>
> Starting point:
>
>    app uses libwowiezowie.so.1
>    app uses libkrb5.so.20
>    libwowiezowie.so.1 uses libkrb5.so.20
>
> This works. But now suppose I recompile libwowiezowie:
>
>    app uses libwowiezowie.so.1
>    app uses libkrb5.so.20
>    libwowiezowie.so.1 uses libkrb5.so.21
>
> Running the app will now load both kerberos libraries. This probably
> won't work [...]

Yep, this will in all probability be a problem.

However, as has been pointed out, with proper version number
hygiene for the shared libraries, at least the worst effects of
this can probably be avoided.  What should happen when you bump
the major of libkrb5 is that any other library which uses libkrb5
*also* needs to have it's major number bumped, and it needs to be
recompiled and installed, of course together with any headers
which define the new interface.  Yes, this is true both for
shared libraries in the base operating system, as well as any
third-party libraries, be they out of pkgsrc or from somewhere
else!

This is why I raised the hand in warning what we need to prepare
for if we are going to bump the major of libc as a consequence of
changing the size of time_t to be 64 bits, because which shared
library *doesn't* use libc?  Doing the version handling dance
properly to preserve backwards binary compatibility as good as
possible (given what we have to work with) and at the same time
avoiding the version clash described above requires a *lot* of
effort and coordination!

Regards,

- Håvard