Re: Lib Version

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Uttered Alexander Dalloz <alexander.dalloz@xxxxxxxxxxxxxxxx>, spake thus:

> Am Fr, den 30.04.2004 schrieb Tim Clarke um 17:20:
> > Alex, pardon my ignorance but how does glibc-*2.3.2 work out to be
> > libc6?!?
> So libc.so.6 means libc6 means glibc version 6 and is packaged in the
> glibc-2.3.2-101.4 RPM. Someone else may give you a more precise and
> better informed answer than me.

The intent of the whole setup is to allow multiple versions of shared
libraries because an application gets built expecting a particular
version of the library, perhaps because of ABI issues.

To that end, each library includes its name builtin to the shared
library itself.  So when a program is linked against a library
(-lfoo), the linker looks into the shared library and adds its
"internal" name into the executables list of shared libraries.  If
you look, you will usually see a series of symbolic links pointing to
the actual shared library itself:

	glibc.so --> glibc-6.so
	glibc-6.1 --> glibc-6.1.2.so

It is the use of these intermediate symbolic links that makes this
work.  The "glibc-6.1.2.so" library indentifies itself as "glibc-6.so",
by means of that "internal" name I mentioned.  So when the program
linker binds "glibc.so", it actually finds the library file
"glibc-6.1.2.so" whose internal name is "glibc-6.so" and that's the
library name placed in the executables list of necessary shared
libraries.

Now when the application gets executed, the system first runs a
shared-program loader that ensures that all prerequisite shared
libraries are in memory.  The shared program loader (ld.so) looks in
the executables shared library table, finds "glibc-6.so" and then
links the executable to that file.

When a new version of the shared library becomes available, say
"glibc-6.1.3.so", all that is necessary is to install the new file
and change the symbolic links:

	glibc.so   --> glibc-6.so
	glibc-6.so --> glibc-6.1.3.so

and when the executable program is loaded again, the ld.so looks for
shared library file "glibc-6.so" and automatically gets the newer
version of the library.

When an interface is changed in the shared library, the new release
has a different minor number (the "1" in "glibc-6.1.3.so") the new
version is installed and the directory listing looks a bit like this:

	glibc.so   --> glibc-6.so
	glibc-6.so --> glibc-6.2.0.so
	glibc-6.1.3.so
	glibc-6.2.0.so

It's all a bit confusing but just remember there are _two_ linking
times when a shared library is used: 1) when "ld" binds the shared
library to the executable and; 2) when "ld.so" attaches the shared
library to the executable at run time.

Cheers!

Attachment: pgpevhGIcCD3n.pgp
Description: PGP signature


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux