Re: Lib Version
From: Tommy Reynolds (Tommy.Reynolds_at_MegaCoder.com)
Date: 04/30/04
- Previous message: Henri Girard: "upgrade fed 1 to fed 2"
- In reply to: Alexander Dalloz: "Re: Lib Version"
- Next in thread: William Hooper: "RE: Lib Version"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 30 Apr 2004 11:52:31 -0500 To: For users of Fedora Core releases <fedora-list@redhat.com>
Uttered Alexander Dalloz <alexander.dalloz@uni-bielefeld.de>, 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!
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
- application/pgp-signature attachment: stored
- Previous message: Henri Girard: "upgrade fed 1 to fed 2"
- In reply to: Alexander Dalloz: "Re: Lib Version"
- Next in thread: William Hooper: "RE: Lib Version"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
