Discussion:
Why versioned library names?
(too old to reply)
Florian Weimer
2018-11-23 12:02:53 UTC
Permalink
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
Florian Weimer
2018-12-05 13:17:58 UTC
Permalink
Post by 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
David Newall
2018-12-05 23:50:22 UTC
Permalink
Post by 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?
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.
Florian Weimer
2018-12-06 11:46:53 UTC
Permalink
Post by David Newall
Post by 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?
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”.
Post by David Newall
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

Loading...