Why versioned library names?

Why versioned library names?

[Florian Weimer]

Why does the default “make install” command install the library files
with versions in their names and relies on symbolic links to provide the
official names?

Is this so that a previous version of glibc can be restored by using
sln?  If this is the only reason, is it worth keeping this feature?

I'm asking about this because RPM has some peculiarities related to file
removals and symbolic link updates during packages updates.  These
changes can happen very late, and scriptlets can run while the old files
and symbolic link targets are still present.

Thanks,
Florian

Re: Why versioned library names?

[Florian Weimer]

* Florian Weimer:

> Why does the default “make install” command install the library files
> with versions in their names and relies on symbolic links to provide the
> official names?
>
> Is this so that a previous version of glibc can be restored by using
> sln?  If this is the only reason, is it worth keeping this feature?
>
> I'm asking about this because RPM has some peculiarities related to file
> removals and symbolic link updates during packages updates.  These
> changes can happen very late, and scriptlets can run while the old files
> and symbolic link targets are still present.

Any ideas?

If we can't think of a reason why this is needed, should we simplify the
installation procedure and avoid the symbolic links?

Thanks,
Florian

Re: Why versioned library names?

[David Newall]

On 5/12/18 11:47 pm, Florian Weimer wrote:
> Why does the default “make install” command install the library files
> with versions in their names and relies on symbolic links to provide the
> official names?
>
> Is this so that a previous version of glibc can be restored by using
> sln?  If this is the only reason, is it worth keeping this feature?

It's been a long time since shared libraries became a thing, but, I seem 
to recall that one of the design goals was that you could keep multiple 
versions, and programs would load against the particular version that 
they needed.  That is, each program would specify not just the name of 
the various shared libraries, but the names and versions.  I think this 
is still done with the major version number, but I guess you are asking 
about minor version numbers.

Having the version number in the name of each library allowed symbolic 
links to be used to point each version to a newer compatible version, 
thus saving disk space while still allowing old binaries to run.

Re: Why versioned library names?

[Florian Weimer]

* David Newall:

> On 5/12/18 11:47 pm, Florian Weimer wrote:
>> Why does the default “make install” command install the library files
>> with versions in their names and relies on symbolic links to provide the
>> official names?
>>
>> Is this so that a previous version of glibc can be restored by using
>> sln?  If this is the only reason, is it worth keeping this feature?
>
> It's been a long time since shared libraries became a thing, but, I
> seem to recall that one of the design goals was that you could keep
> multiple versions, and programs would load against the particular
> version that they needed.  That is, each program would specify not
> just the name of the various shared libraries, but the names and
> versions.  I think this is still done with the major version number,
> but I guess you are asking about minor version numbers.

That's why we have “libc.so.6” (on most architectures).  “6” is that
version.  But the installed library is called (e.g.) “libc-2.28.so”.

> Having the version number in the name of each library allowed symbolic
> links to be used to point each version to a newer compatible version,
> thus saving disk space while still allowing old binaries to run.

The soname in the library is still “libc.so.6”, so this is what the link
editor will use (even if you link using something like “-lc-2.28”).  The
dynamic linker will never open /lib64/libc-2.28.so directly.

It's true that some symbolic links have been used in this context, but
these would point to libc.so.6 (from, say, libc.so.6.0.1).  None of this
explains why libc.so.6 itself is a symbolic link.

Thanks,
Florian

Re: Why versioned library names?

[Siddhesh Poyarekar]

On 23/11/18 5:32 PM, Florian Weimer wrote:
> Why does the default “make install” command install the library files
> with versions in their names and relies on symbolic links to provide the
> official names?
> 
> Is this so that a previous version of glibc can be restored by using
> sln?  If this is the only reason, is it worth keeping this feature?

That has been my understanding as well; I'm not old enough to 
definitively claim that it is.

As for removing this feature, on the contrary I feel like it's not 
sufficient and that we need to strengthen this to make recoveries from 
botched updates more solid, similar to the kernel.  Right now a botched 
glibc update means that you have to go looking for your rescue disc to 
recover.  An ideal set up would be:

1. Versioned (e.g. ld-2.25-200.fc29.so) glibc libraries

2. glibc symlinks set using sln at every boot by the kernel based on a 
configuration file.  A glibc update then only updates that configuration 
file and a subsequent reboot picks up the correct glibc.  This solves 
the race conditions that occur with updates of different library files.

3. A kernel boot option glibcver=2.25-200.fc29 to override the 
configuration file.

Siddhesh

PS: I won't call the config file a systemwide tunable file, but you 
could call it that if you want ;)