|
Home > Archive > Unix Programming > November 2006 > shared library - why 3 files are needed for a shared library. ?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
shared library - why 3 files are needed for a shared library. ?
|
|
|
| Hi,
I build xerces to get a shared library. But in the lib folder
there are 3 files [ libxerces-c.so,libxerces-c.so.27.0,
libxerces-c.so.27] of which 2 are shortcuts. Why is this kind of a
file system required.
I googled and got 2 references
1) http://tldp.org/HOWTO/Program-Libra...-libraries.html
2)http://users.actcom.co.il/~choo/lup...-libraries.html
But they only gave info about what the 3 files are and not about why 3
files are required for a shared library. Why this kind of an
architecture is needed ? Why can't we have a single file as in case of
a static library? Could any one tell why or get me some useful
references on the topic?
Thanks in advance
Kiran Pradeep.
| |
| Casper H.S. Dik 2006-11-28, 7:30 am |
| "jithu" <kiran.happy@gmail.com> writes:
> I build xerces to get a shared library. But in the lib folder
>there are 3 files [ libxerces-c.so,libxerces-c.so.27.0,
>libxerces-c.so.27] of which 2 are shortcuts. Why is this kind of a
>file system required.
>I googled and got 2 references
>1) http://tldp.org/HOWTO/Program-Libra...-libraries.html
>2)http://users.actcom.co.il/~choo/lup...-libraries.html
>But they only gave info about what the 3 files are and not about why 3
>files are required for a shared library. Why this kind of an
>architecture is needed ? Why can't we have a single file as in case of
>a static library? Could any one tell why or get me some useful
>references on the topic?
In principle, you only need two:
libname.so
-> symlink to the current version; this is needed so the
*compile time* linker can find the library; the llibrary has
an ELF "SONAME" entry which returns the actual name,
e.g., "libname.so.2"
libname.so.<version>
The actual library; it is used by the runtime linker and is
different from library.so to allow major version changes
in libraries.
This name should not change unless an *incompatible* change
is made to the library.
The fact that the version is generally a number is misleading; ELF
libraries have names, not numbers. The SONAME can just as well
be "libname.so.fatbastard" or even "libthatothername.so.3.1415".
The 3rd link, the major.minor link can only serve one purpose;
to document exactly which version of the library is installed.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
| |
|
|
Casper H.S. Dik wrote:
> "jithu" <kiran.happy@gmail.com> writes:
>
>
>
>
>
> In principle, you only need two:
>
> libname.so
>
> -> symlink to the current version; this is needed so the
> *compile time* linker can find the library; the llibrary has
> an ELF "SONAME" entry which returns the actual name,
> e.g., "libname.so.2"
>
>
> libname.so.<version>
>
> The actual library; it is used by the runtime linker and is
> different from library.so to allow major version changes
> in libraries.
>
> This name should not change unless an *incompatible* change
> is made to the library.
>
> The fact that the version is generally a number is misleading; ELF
> libraries have names, not numbers. The SONAME can just as well
> be "libname.so.fatbastard" or even "libthatothername.so.3.1415".
>
> The 3rd link, the major.minor link can only serve one purpose;
> to document exactly which version of the library is installed.
>
> Casper
> --
> Expressed in this posting are my opinions. They are in no way related
> to opinions held by my employer, Sun Microsystems.
> Statements on Sun products included here are not gospel and may
> be fiction rather than truth.
Hi All,
Thanks for all your replies. Can i some way use just 1 file
(" libname.so.<version> " ) and ask the linker to use it instead of "
libname.so ". ?
| |
|
| Casper H.S. Dik wrote:
> "jithu" <kiran.happy@gmail.com> writes:
>
>
>
>
>
> In principle, you only need two:
>
> libname.so
>
> -> symlink to the current version; this is needed so the
> *compile time* linker can find the library; the llibrary has
> an ELF "SONAME" entry which returns the actual name,
> e.g., "libname.so.2"
>
>
> libname.so.<version>
>
> The actual library; it is used by the runtime linker and is
> different from library.so to allow major version changes
> in libraries.
>
> This name should not change unless an *incompatible* change
> is made to the library.
>
> The fact that the version is generally a number is misleading; ELF
> libraries have names, not numbers. The SONAME can just as well
> be "libname.so.fatbastard" or even "libthatothername.so.3.1415".
>
> The 3rd link, the major.minor link can only serve one purpose;
> to document exactly which version of the library is installed.
>
> Casper
> --
> Expressed in this posting are my opinions. They are in no way related
> to opinions held by my employer, Sun Microsystems.
> Statements on Sun products included here are not gospel and may
> be fiction rather than truth.
Hi All,
Thanks for all your replies. Can i some way use just 1 file
("libname.so.<version>") and ask the linker to use it instead of "
libname.so" ?
| |
| Casper H.S. Dik 2006-11-28, 7:30 am |
| "jithu" <kiran.happy@gmail.com> writes:
>Hi All,
> Thanks for all your replies. Can i some way use just 1 file
>(" libname.so.<version> " ) and ask the linker to use it instead of "
>libname.so ". ?
Yes, but that will be fairly awkward; you cannot use the -l option to
find libraries in that case.
But if it is just for installing, not compiling, then the compilation
symlink is not needed.
Casper
| |
| James Carlson 2006-11-28, 1:18 pm |
| "jithu" <kiran.happy@gmail.com> writes:
> I build xerces to get a shared library. But in the lib folder
> there are 3 files [ libxerces-c.so,libxerces-c.so.27.0,
> libxerces-c.so.27] of which 2 are shortcuts. Why is this kind of a
> file system required.
This is done so that applications can link against just "-lxerces-c"
without having to worry about version numbers.
Once linked, the binary produced will have a reference to the complete
version number (...so.27.0), so that the right one will be picked up
on a system with multiple versions installed.
(The extra one in that list -- libxerces-c.so.27 -- is a mystery. It
looks like the author expects the user to depend on a major version
number somehow without needing the minor, but it's unclear how he
expects that to work. You should ask the author of the library in
question what the expected usage case would be.)
> But they only gave info about what the 3 files are and not about why 3
> files are required for a shared library. Why this kind of an
> architecture is needed ? Why can't we have a single file as in case of
> a static library? Could any one tell why or get me some useful
> references on the topic?
It's for versioning. It's just a common usage convention -- you
needn't actually do this for your own libraries, if you think it's a
problem or a bother.
--
James Carlson, KISS Network <james.d.carlson@sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
| |
|
| Casper H.S. Dik wrote:
> "jithu" <kiran.happy@gmail.com> writes:
>
>
>
>
> Yes, but that will be fairly awkward; you cannot use the -l option to
> find libraries in that case.
>
> But if it is just for installing, not compiling, then the compilation
> symlink is not needed.
>
> Casper
I tried renaming libxerces-c.so.27.0 to libxerces-c.so. The code
compiled and I got an exe which will ask for libxerces-c.so.27 during
run time. May be i misunderstood what you said. Could you be a bit more
clear. ?
| |
|
| James Carlson wrote:
> "jithu" <kiran.happy@gmail.com> writes:
>
> This is done so that applications can link against just "-lxerces-c"
> without having to worry about version numbers.
>
> Once linked, the binary produced will have a reference to the complete
> version number (...so.27.0), so that the right one will be picked up
> on a system with multiple versions installed.
I doubt you got it wrong there (i am a novice in this. i am not sure).
The binary is looking for libxerces-c.so.27 and not for "...so.27.o".
For a clear picture, you can give a look into above post by Capser
(http://groups.google.com/group/comp...24?dmode=source)
>
> (The extra one in that list -- libxerces-c.so.27 -- is a mystery. It
> looks like the author expects the user to depend on a major version
> number somehow without needing the minor, but it's unclear how he
> expects that to work. You should ask the author of the library in
> question what the expected usage case would be.)
>
I dont think this has anything to do with author of library. If you
look into section 3.1.1 of this reference (
http://tldp.org/HOWTO/Program-Libra...-libraries.html ) you
can see 3 different names for shared libraries ("soname", "real name",
"linker name")
>
> It's for versioning. It's just a common usage convention -- you
> needn't actually do this for your own libraries, if you think it's a
> problem or a bother.
>
> --
> James Carlson, KISS Network <james.d.carlson@sun.com>
> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
| |
| Casper H.S. Dik 2006-11-28, 1:18 pm |
| "jithu" <kiran.happy@gmail.com> writes:
>I tried renaming libxerces-c.so.27.0 to libxerces-c.so. The code
>compiled and I got an exe which will ask for libxerces-c.so.27 during
>run time. May be i misunderstood what you said. Could you be a bit more
>clear. ?
The .so file is not needed except when linking; the "name" registered
in the binary when it is created is taken from the "SONAME" attribute
in the library; it is not taken from the filename.
What you see is what I expected to happen.
Casper
| |
|
| Casper H.S. Dik wrote:
> "jithu" <kiran.happy@gmail.com> writes:
>
>
> The .so file is not needed except when linking; the "name" registered
> in the binary when it is created is taken from the "SONAME" attribute
> in the library; it is not taken from the filename.
>
> What you see is what I expected to happen.
>
> Casper
Sorry to repeatedly disturb you. Being a novice i am not understanding
the ways you guys speak. So what i am understanding is while linking we
should be having libxerces.so and while executing the code we should be
renaming it to libxerces.so.27. Am i wrong ?
| |
| Ralf Fassel 2006-11-29, 7:28 am |
| * "jithu" <kiran.happy@gmail.com>
| So what i am understanding is while linking we should be having
| libxerces.so and while executing the code we should be renaming it
| to libxerces.so.27.
You should have the 'real' library under the name of libxerces.so.27
(for runtime) *and* a symbolic link libxerces.so pointing to
libxerces.so.27 (for compile/link time). No renaming. If you don't
compile/link, you don't need the symbolic link. If you don't run the
program, you don't need any of the two ;-)
Why do we have the 'full' library name in the executable? Well, the
exceutable was linked against a particular library version, so it
should run with exactly that library version, even if the symbolic
link in the meantime points to a newer (probably binary incompatible)
version of the library.
R'
| |
|
| Ralf Fassel wrote:
> * "jithu" <kiran.happy@gmail.com>
> | So what i am understanding is while linking we should be having
> | libxerces.so and while executing the code we should be renaming it
> | to libxerces.so.27.
>
> You should have the 'real' library under the name of libxerces.so.27
> (for runtime) *and* a symbolic link libxerces.so pointing to
> libxerces.so.27 (for compile/link time). No renaming. If you don't
> compile/link, you don't need the symbolic link. If you don't run the
> program, you don't need any of the two ;-)
>
> Why do we have the 'full' library name in the executable? Well, the
> exceutable was linked against a particular library version, so it
> should run with exactly that library version, even if the symbolic
> link in the meantime points to a newer (probably binary incompatible)
> version of the library.
>
> R'
THANKS A LOT. When posting the question, i thought i would get a
partial answer.But now i understood why we have 3 files for a shared
library. Long Live comp.unix.programmer. This group will certainly help
in making better unix programmers
| |
|
| Ralf Fassel wrote:
> * "jithu" <kiran.happy@gmail.com>
> | So what i am understanding is while linking we should be having
> | libxerces.so and while executing the code we should be renaming it
> | to libxerces.so.27.
>
> You should have the 'real' library under the name of libxerces.so.27
> (for runtime) *and* a symbolic link libxerces.so pointing to
> libxerces.so.27 (for compile/link time). No renaming. If you don't
> compile/link, you don't need the symbolic link. If you don't run the
> program, you don't need any of the two ;-)
>
> Why do we have the 'full' library name in the executable? Well, the
> exceutable was linked against a particular library version, so it
> should run with exactly that library version, even if the symbolic
> link in the meantime points to a newer (probably binary incompatible)
> version of the library.
>
> R'
Thanks for the answer. That solved one of my doubts which was why there
is 'full' library name in the executable. But still the first question
remains. why 3 files for shared library.
Any way all info provided by all the members have been very useful and
i think this group(comp.unix.programmer) will certainly help in making
better unix programmers.
|
|
|
|
|