|
Home > Archive > Unix Programming > January 2004 > What is a (shared) object?
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 |
What is a (shared) object?
|
|
|
| Hi there!
I'm a newby in Unix-programming and I know libs and dlls, but I know
nothing or less about shared objects on Unix.
What is the difference between a *.o and a *.so?
And how do I tell the Compiler, which one I want?
I have about 40 source files which compiled to 2 DLLs on Win32. What
will that be on Unix?
Thanks and bye, Micha
| |
| Ulrich Eckhardt 2004-01-26, 9:34 pm |
| Micha wrote:quote:
> I'm a newby in Unix-programming and I know libs and dlls, but I know
> nothing or less about shared objects on Unix.
A shared object (.so) resembles the win32 DLL, simple as that.
quote:
> What is the difference between a *.o and a *.so?
One is the raw output of the assembler, the other bundles several such
files with some framework into an .so.
quote:
> And how do I tell the Compiler, which one I want?
You might mant to take a look at the autotools (automake, autoconf, and -
especially - libtool).
Uli
--
Questions ?
see C++-FAQ Lite: http://parashift.com/c++-faq-lite/ first !
| |
| Robert Harris 2004-01-27, 1:34 am |
| Well, you don't need autotools. A .o is what you get when you compile a
..c file (if writing in C). A .so file is a shared library object:
generally a combination of .o files that your executable can link to.
The alternative to a .so file is a .a file (archive) which also contains
a combination of .o files but, if a .a file is selected, those .o
modules within it that satisfy external references will be included in
your executable.
To include a .o file in your executable, just add its file name to the
gcc command line. To include a .so file, you generally add -lXX to your
command line which results in the file libXX.so being linked against.
The -L file adds directories in which to search for .so files.
-lXX will include file livXX.a if it can't find libXX.so
Robert
Ulrich Eckhardt wrote:[QUOTE][color=darkred]
> Micha wrote:
>
| |
| Rich Teer 2004-01-27, 3:34 am |
| On Tue, 27 Jan 2004, Robert Harris wrote:
quote:
> To include a .o file in your executable, just add its file name to the
> gcc command line. To include a .so file, you generally add -lXX to your
> command line which results in the file libXX.so being linked against.
> The -L file adds directories in which to search for .so files.
And -R adds the directories to the run-time search path, thus
avoiding the LD_LIBRARY_PATH nonsense.
--
Rich Teer, SCNA, SCSA
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
| |
| Bjorn Reese 2004-01-27, 4:35 am |
| On Tue, 27 Jan 2004 11:27:02 +0100, Ulrich Eckhardt wrote:
quote:
> You might mant to take a look at the autotools (automake, autoconf, and -
> especially - libtool).
Or read section 6.3 in our fine FAQ
http://www.erlenstar.demon.co.uk/unix/faq_7.html#SEC79
--
mail1dotstofanetdotdk
| |
| =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= 2004-01-27, 4:35 am |
| Rich Teer <rich.teer@rite-group.com> writes:
quote:
> On Tue, 27 Jan 2004, Robert Harris wrote:
>
>
> And -R adds the directories to the run-time search path, thus
> avoiding the LD_LIBRARY_PATH nonsense.
Never, ever use that. The user might very well want to override the
default search path, but if rpath is set he can't.
--
Måns Rullgård
mru@kth.se
| |
| Victor Wagner 2004-01-27, 5:35 am |
| M?ns Rullg?rd <mru@kth.se> wrote:
:>
:> And -R adds the directories to the run-time search path, thus
:> avoiding the LD_LIBRARY_PATH nonsense.
: Never, ever use that. The user might very well want to override the
: default search path, but if rpath is set he can't.
I can see only two reason for user to override default search path
of BINARY program
- to bypass some license management software by LD_PRELOAD-ing
some hack which does intercept system or library calls.
- to install illegally copied binaries on machine where he doesn't have
rights to install them.
If program is opensource, user have better to rebuild it from sources if
he want to install it into nonstandard location, becouse nobody
guarantees that rpath is only prefix-dependent thing compiled in.
If he has legitimately purcashed commercial program, he probably have root access on the machine he is going to install it, and may well install it in
the standard place.
--
This life is a test. It is only a test. Had this been an actual life, you
would have received further instructions as to what to do and where to go.
| |
| =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= 2004-01-27, 5:35 am |
| vitus@45.free.net (Victor Wagner) writes:
quote:
> M?ns Rullg?rd <mru@kth.se> wrote:
> :>
> :> And -R adds the directories to the run-time search path, thus
> :> avoiding the LD_LIBRARY_PATH nonsense.
>
> : Never, ever use that. The user might very well want to override the
> : default search path, but if rpath is set he can't.
>
> I can see only two reason for user to override default search path
> of BINARY program
> - to bypass some license management software by LD_PRELOAD-ing
> some hack which does intercept system or library calls.
> - to install illegally copied binaries on machine where he doesn't have
> rights to install them.
Are you somehow representing the BSA?
quote:
> If program is opensource, user have better to rebuild it from sources if
> he want to install it into nonstandard location, becouse nobody
> guarantees that rpath is only prefix-dependent thing compiled in.
What if the shared library moves? I always install each version of
everything in a different place, so I can easily select which version
to use by simply changing PATH and LD_LIBRARY_PATH. Imagine a
program, foo, that is linked to libbar.so. At the time foo was
compiled libbar.so was in /mpkg/libbar/1.0/lib/libbar.so. A new
(binary compatible) version of libbar is installed, this time in
/mpkg/libbar/1.1/lib/libbar.so. Now, if foo uses rpath it will still
pick up the old libbar.so, unless it is removed. I usually leave the
old versions around for a while, just in case there is some problem
with the new version.
You say I should recompile every program that is linked with libbar.
Fine, that'll work. The problem is that identifying and recompiling
them all can take days.
quote:
> If he has legitimately purcashed commercial program, he probably
> have root access on the machine he is going to install it, and may
> well install it in the standard place.
These commercial programs very often like to install themselves in
/usr. I don't want them there. It makes it too messy to figure out
which files belong to which programs etc. This is not a major
problem, however, since there won't be a different library by the same
name in the rpath of the program.
--
Måns Rullgård
mru@kth.se
| |
| joe@invalid.address 2004-01-27, 5:35 am |
| mru@kth.se (Måns Rullgård) writes:
quote:
> Rich Teer <rich.teer@rite-group.com> writes:
>
>
> Never, ever use that. The user might very well want to override the
> default search path, but if rpath is set he can't.
LD_LIBRARY_PATH, if set, will be searched before the builtin rpath, so
the user can indeed override it. From
http://docs.sun.com/db/doc/816-0559/6m71o2aet?a=view
"The recommended way to indicate additional search paths to the
runtime linker is to record a runpath during the link-edit of the
dynamic executable or shared object (see "Directories Searched by the
Runtime Linker" for details on recording this information).
Any runpath recording can be displayed using dump(1) and referring to
the entry that has the RPATH tag. For example:
$ dump -Lvp prog
prog:
[INDEX] Tag Value
[1] NEEDED libfoo.so.1
[2] NEEDED libc.so.1
[3] RPATH /home/me/lib:/home/you/lib
.........
Here, prog has a dependency on libfoo.so.1 and requires the runtime
linker to search directories /home/me/lib and /home/you/lib before it
looks in the default location /usr/lib.
Another way to add to the runtime linker's search path is to set the
environment variable LD_LIBRARY_PATH. This environment variable
(which is analyzed once at process start-up) can be set to a
colon-separated list of directories, and these directories will be
searched by the runtime linker before any runpath specification or
default directory.
..."
Joe
--
I think people should be able to make up their own minds for me
- Monty Python
| |
| joe@invalid.address 2004-01-27, 5:35 am |
| vitus@45.free.net (Victor Wagner) writes:
quote:
> M?ns Rullg?rd <mru@kth.se> wrote:
> :>
> :> And -R adds the directories to the run-time search path, thus
> :> avoiding the LD_LIBRARY_PATH nonsense.
>
> : Never, ever use that. The user might very well want to override the
> : default search path, but if rpath is set he can't.
>
> I can see only two reason for user to override default search path
> of BINARY program
> - to bypass some license management software by LD_PRELOAD-ing
> some hack which does intercept system or library calls.
> - to install illegally copied binaries on machine where he doesn't have
> rights to install them.
Another reason would be during testing, to try out a new version of a
library. In that case LD_LIBRARY_PATH can override the runpath and use
the new version without changing the library for other users on the
machine.
Joe
--
I think people should be able to make up their own minds for me
- Monty Python
| |
| =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= 2004-01-27, 5:35 am |
| joe@invalid.address writes:
quote:
> mru@kth.se (Måns Rullgård) writes:
>
>
> LD_LIBRARY_PATH, if set, will be searched before the builtin rpath, so
> the user can indeed override it. From
> http://docs.sun.com/db/doc/816-0559/6m71o2aet?a=view
It looks like the GNU glibc dynamic linker searches rpath first.
Maybe I'll just hack mine to do what I want it to.
--
Måns Rullgård
mru@kth.se
| |
| joe@invalid.address 2004-01-27, 5:35 am |
| joe@invalid.address writes:
[QUOTE][color=darkred]
> mru@kth.se (Måns Rullgård) writes:
>
Sorry, forgot which group I was in again. Whenever I see "Rich Teer" I
think I'm in comp.unix.solaris. Here's a more general statement of why
LD_LIBRARY_PATH should at least be considered suspicious.
http://www.visi.com/~barr/ldpath.html
I can say that it's caused me problems in the past. I recall one
incident where I had to popen() another program. That program failed
because LD_LIBRARY_PATH was set in the calling program's environment,
and caused the spawned program to load the wrong version of a library.
Joe
--
I think people should be able to make up their own minds for me
- Monty Python
| |
| joe@invalid.address 2004-01-27, 5:35 am |
| mru@kth.se (Måns Rullgård) writes:
quote:
> joe@invalid.address writes:
>
>
> It looks like the GNU glibc dynamic linker searches rpath first.
> Maybe I'll just hack mine to do what I want it to.
Hmm, that's interesting. I don't normally use GNU stuff to build
things, but I will be in the future, so that's good to know.
Joe
--
I think people should be able to make up their own minds for me
- Monty Python
| |
| =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= 2004-01-27, 6:35 am |
| joe@invalid.address writes:
quote:
> joe@invalid.address writes:
>
>
> Sorry, forgot which group I was in again. Whenever I see "Rich Teer" I
> think I'm in comp.unix.solaris. Here's a more general statement of why
> LD_LIBRARY_PATH should at least be considered suspicious.
>
> http://www.visi.com/~barr/ldpath.html
That's just someone's personal opinions. Used correctly,
LD_LIBRARY_PATH is better than a hardcoded rpath. If there is a
problem the user can easily modify LD_LIBRARY_PATH as he sees fit,
whereas the rpath is set in stone. I use LD_LIBRARY_PATH to choose a
bunch of directories to search, each one containing exactly one
version of one library (some packages might have several related
libraries). This way, the problems described on that web page will
never happen.
As for linking (at build time), the GNU linker doesn't use
LD_LIBRARY_PATH but rather LIBRARY_PATH.
quote:
> I can say that it's caused me problems in the past. I recall one
> incident where I had to popen() another program. That program failed
> because LD_LIBRARY_PATH was set in the calling program's environment,
> and caused the spawned program to load the wrong version of a library.
If some particular program requires an obscure version of a library,
it can easily be fixed with a wrapper script that adjusts
LD_LIBARARY_PATH.
--
Måns Rullgård
mru@kth.se
| |
| =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= 2004-01-27, 6:35 am |
| joe@invalid.address writes:
quote:
> mru@kth.se (Måns Rullgård) writes:
>
>
> Hmm, that's interesting. I don't normally use GNU stuff to build
> things, but I will be in the future, so that's good to know.
Good? It's cost me a lot of time trying to figure out why my bugfix
didn't fix anything, only to realize that the program had an rpath
pointing at the old library all the time.
--
Måns Rullgård
mru@kth.se
| |
| Rich Teer 2004-01-27, 6:35 am |
| On Tue, 27 Jan 2004, Måns Rullgård wrote:
quote:
> What if the shared library moves? I always install each version of
Who moves installed libraries?!
quote:
> everything in a different place, so I can easily select which version
> to use by simply changing PATH and LD_LIBRARY_PATH. Imagine a
I'm not arguing against the use of LD_LIBRARY_PATH for a developer.
It can be very useful it testing new versions of libraries. But I
AM arguing against its use for production, non-development software.
quote:
> program, foo, that is linked to libbar.so. At the time foo was
> compiled libbar.so was in /mpkg/libbar/1.0/lib/libbar.so. A new
> (binary compatible) version of libbar is installed, this time in
> /mpkg/libbar/1.1/lib/libbar.so. Now, if foo uses rpath it will still
> pick up the old libbar.so, unless it is removed. I usually leave the
> old versions around for a while, just in case there is some problem
> with the new version.
That's what version libraries are for. You link against libfoo.so,
which is a link to libfoo.so.version.
quote:
> You say I should recompile every program that is linked with libbar.
Recompilation is not necessary - not even relinking.
quote:
> These commercial programs very often like to install themselves in
> /usr. I don't want them there. It makes it too messy to figure out
Commercial software should be using /opt, not /usr (unless it is
part of the OS).
Note that I'm thikning from the perspective of a Solaris developer;
other OSes might have their own idea of what constitutes "correct"
behaviour...
--
Rich Teer, SCNA, SCSA
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
| |
| Victor Wagner 2004-01-27, 6:35 am |
| M?ns Rullg?rd <mru@kth.se> wrote:
:>
:> I can see only two reason for user to override default search path
:> of BINARY program
:> - to bypass some license management software by LD_PRELOAD-ing
:> some hack which does intercept system or library calls.
:> - to install illegally copied binaries on machine where he doesn't have
:> rights to install them.
: Are you somehow representing the BSA?
Now, rather opposite side. But if someone got binary program anywhere
but his operating system distribution, BSA or something alike is surely
involved.
And if you got program from your distribution, probably your package
manager, be it even Solaris's pkgadd, probably knows where its libraries
should go, better than yourself.
:> If program is opensource, user have better to rebuild it from sources if
:> he want to install it into nonstandard location, becouse nobody
:> guarantees that rpath is only prefix-dependent thing compiled in.
: What if the shared library moves? I always install each version of
I know only one situation when shared library can move - when it moves
from test location into production one. In the test location
LD_LIBRARY_PATH can indeed be used. Just to run regression tests
after rebuilding program with correct --prefix.
: everything in a different place, so I can easily select which version
I prefer to use good package manager.
: to use by simply changing PATH and LD_LIBRARY_PATH. Imagine a
And then you try to run your program from CGI script, and
find out that it just doesn't work, becouse you forget to set
environment for user your httpd runs under.
: program, foo, that is linked to libbar.so. At the time foo was
: compiled libbar.so was in /mpkg/libbar/1.0/lib/libbar.so. A new
: (binary compatible) version of libbar is installed, this time in
: /mpkg/libbar/1.1/lib/libbar.so. Now, if foo uses rpath it will still
: pick up the old libbar.so, unless it is removed. I usually leave the
And it probably would be correct. There are too much chances that
newer libbar has incompatible interface changes.
But there is also a convention to append version number after so
extension and make bunch of symlinks libbar.so.1 libbar.so.1.1 and just
libbar.so.
Thus all versions can be installed in one directory, and program which
doesn't care which version of libbar it have, would use libbar.so,
program which requires major version 1 would use libbar.so.1,
and program which uses undocumented hacks which were silently removed
in 1.2, can point directly to libbar.so.1.1
(of course one shouldn't write programs which use undocumented hacks,
but live is harsh).
: These commercial programs very often like to install themselves in
: /usr. I don't want them there. It makes it too messy to figure out
Of course. /opt is where they should go.
--
'Mounting' is used for three things: climbing on a horse, linking in a
hard disk unit in data systems, and, well, mounting during sex.
-- Christa Keil
| |
| joe@invalid.address 2004-01-27, 6:35 am |
| mru@kth.se (Måns Rullgård) writes:
quote:
> joe@invalid.address writes:
>
>
> That's just someone's personal opinions. Used correctly,
> LD_LIBRARY_PATH is better than a hardcoded rpath.
Isn't that a personal opinion? :-)
quote:
> If there is a problem the user can easily modify LD_LIBRARY_PATH as
> he sees fit, whereas the rpath is set in stone.
Apparently only with the GNU linker. At least, I'm not aware of any
others that have that problem.
quote:
>
> If some particular program requires an obscure version of a library,
> it can easily be fixed with a wrapper script that adjusts
> LD_LIBARARY_PATH.
Not if you don't have permission to alter the other program. And it
wasn't an obscure version, just a different (relatively recent) one.
Joe
--
I think people should be able to make up their own minds for me
- Monty Python
| |
| =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= 2004-01-27, 6:35 am |
| Rich Teer <rich.teer@rite-group.com> writes:
quote:
>
> I'm not arguing against the use of LD_LIBRARY_PATH for a developer.
> It can be very useful it testing new versions of libraries. But I
> AM arguing against its use for production, non-development software.
The use of LD_LIBRARY_PATH is not so much connected to a particular
program as to the setup of the system as a whole. On my systems, I
like to use LD_LIBRARY_PATH to control which libraries get used.
quote:
>
> That's what version libraries are for. You link against libfoo.so,
> which is a link to libfoo.so.version.
Yes, but how do I easily get rid of the old version if there are lots
of new files in the same directory? Keeping versions in separate
directories makes it as simple as rm -r.
quote:
>
> Recompilation is not necessary - not even relinking.
To change the rpath relinking is necessary.
quote:
>
> Commercial software should be using /opt, not /usr (unless it is
> part of the OS).
Well, whatever. I still might want to move it to make it fit the
conventions of my system.
--
Måns Rullgård
mru@kth.se
| |
| joe@invalid.address 2004-01-27, 6:35 am |
| mru@kth.se (Måns Rullgård) writes:
quote:
> joe@invalid.address writes:
>
[QUOTE][color=darkred]
>
> Good? It's cost me a lot of time trying to figure out why my bugfix
> didn't fix anything, only to realize that the program had an rpath
> pointing at the old library all the time.
Well, that's what's good about finding this out before I have to do
the same :-)
Joe
--
I think people should be able to make up their own minds for me
- Monty Python
| |
| =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= 2004-01-27, 6:35 am |
| vitus@45.free.net (Victor Wagner) writes:
quote:
> M?ns Rullg?rd <mru@kth.se> wrote:
> :>
> :> I can see only two reason for user to override default search path
> :> of BINARY program
> :> - to bypass some license management software by LD_PRELOAD-ing
> :> some hack which does intercept system or library calls.
> :> - to install illegally copied binaries on machine where he doesn't have
> :> rights to install them.
>
> : Are you somehow representing the BSA?
>
> Now, rather opposite side. But if someone got binary program anywhere
> but his operating system distribution, BSA or something alike is surely
> involved.
Never make assumptions about where programs come from. There are
hundreds of good binary-only programs not included in any operating
system.
quote:
> And if you got program from your distribution, probably your package
> manager, be it even Solaris's pkgadd, probably knows where its libraries
> should go, better than yourself.
By definition, I know best where I want things. Where I want them is
where they should go.
quote:
> :> If program is opensource, user have better to rebuild it from sources if
> :> he want to install it into nonstandard location, becouse nobody
> :> guarantees that rpath is only prefix-dependent thing compiled in.
>
> : What if the shared library moves? I always install each version of
>
> I know only one situation when shared library can move - when it moves
> from test location into production one. In the test location
> LD_LIBRARY_PATH can indeed be used. Just to run regression tests
> after rebuilding program with correct --prefix.
>
> : everything in a different place, so I can easily select which version
>
> I prefer to use good package manager.
Show me one. I prefer to keep things simple.
quote:
> : to use by simply changing PATH and LD_LIBRARY_PATH. Imagine a
>
> And then you try to run your program from CGI script, and
> find out that it just doesn't work, becouse you forget to set
> environment for user your httpd runs under.
I can handle that.
quote:
> : program, foo, that is linked to libbar.so. At the time foo was
> : compiled libbar.so was in /mpkg/libbar/1.0/lib/libbar.so. A new
> : (binary compatible) version of libbar is installed, this time in
> : /mpkg/libbar/1.1/lib/libbar.so. Now, if foo uses rpath it will still
> : pick up the old libbar.so, unless it is removed. I usually leave the
>
> And it probably would be correct. There are too much chances that
> newer libbar has incompatible interface changes.
Did you miss the part about the new version being compatible?
quote:
> But there is also a convention to append version number after so
> extension and make bunch of symlinks libbar.so.1 libbar.so.1.1 and just
> libbar.so.
Being compatible, the new version would use the same library version
as the old one. Installing it in the same directory would thus
overwrite the old version, which I might want to keep for some time.
quote:
> Thus all versions can be installed in one directory, and program which
Suppose you want to get rid of the old version. Then you have to sort
through a whole bunch of files and try to determine which files belong
to which package/version.
quote:
> : These commercial programs very often like to install themselves in
> : /usr. I don't want them there. It makes it too messy to figure out
>
> Of course. /opt is where they should go.
/opt/what? I usually put things in /opt/package/version (feel free to
ridicule me and point me to silly pseudo-standards). The installer
might use some other convention.
--
Måns Rullgård
mru@kth.se
| |
| Victor Wagner 2004-01-27, 6:35 am |
| M?ns Rullg?rd <mru@kth.se> wrote:
: Yes, but how do I easily get rid of the old version if there are lots
: of new files in the same directory? Keeping versions in separate
: directories makes it as simple as rm -r.
using apt-get remove or pkgrm is MUCH simplier.
--
Debian is like Suse with yast turned off, just better. 
-- Goswin Brederlow
| |
| =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= 2004-01-27, 6:35 am |
| joe@invalid.address writes:
quote:
>
> Isn't that a personal opinion? :-)
Perhaps, but neither is more correct than the other, in that case.
quote:
>
> Apparently only with the GNU linker. At least, I'm not aware of any
> others that have that problem.
Good for users of other systems. I'll have to dig into the GNU
dynamic linker and see what it's up to.
quote:
>
> Not if you don't have permission to alter the other program. And it
> wasn't an obscure version, just a different (relatively recent) one.
Why wouldn't you be allowed to run the program through a wrapper
script? I can't see how any license could restrict that. In fact,
Swedish copyright law explicitly allows modifications necessary to use
the product, whatever the license may say.
--
Måns Rullgård
mru@kth.se
| |
| =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= 2004-01-27, 6:35 am |
| vitus@45.free.net (Victor Wagner) writes:
quote:
> M?ns Rullg?rd <mru@kth.se> wrote:
>
> : Yes, but how do I easily get rid of the old version if there are lots
> : of new files in the same directory? Keeping versions in separate
> : directories makes it as simple as rm -r.
>
> using apt-get remove or pkgrm is MUCH simplier.
How can anything be much simpler than "rm -r /opt/program/version"?
Those fancy package manager like to make a big fuss about dependencies
they really know nothing about, and that's just the beginning of the
troubles.
--
Måns Rullgård
mru@kth.se
| |
| Rich Teer 2004-01-27, 7:36 am |
| On Tue, 27 Jan 2004, Måns Rullgård wrote:
quote:
> Being compatible, the new version would use the same library version
Bad software engineering. If it's a new version of the library,
it should have a new version number. Unless the "new" version
just has bug fixes and does not introduce new interfaces or remove
old ones.
quote:
> as the old one. Installing it in the same directory would thus
> overwrite the old version, which I might want to keep for some time.
No, the old one should be called (for example), /usr/lib/libfoo.so.1,
and the new one should be called /usr/lib/libfoo.so.2. (Or .so.1.1,
depending on your numbering scheme).
quote:
> Suppose you want to get rid of the old version. Then you have to sort
> through a whole bunch of files and try to determine which files belong
> to which package/version.
That's what package managers are for. :-)
It almost sounds like you're a fan of the DLL-hell that Windoze
lusers have to put up with... :-)
--
Rich Teer, SCNA, SCSA
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
| |
| Jerry Feldman 2004-01-27, 7:36 am |
| On Tue, 27 Jan 2004 20:50:00 GMT
Rich Teer <rich.teer@rite-group.com> wrote:
quote:
> That's what package managers are for. :-)
>
> It almost sounds like you're a fan of the DLL-hell that Windoze
> lusers have to put up with... :-)
Rich,
Even with the smileys, you are correct. On Unix/Linux systems, it is
easier to maintain libraries of different versions. And, WRT: Windoze,
DLLs have been released without any version change making the only way
to identify them is by a size difference and maybe the date. Also, Unix
and Linux allow you to install a new shared library even if the old one
is currently in use (although appropriate care should be taken).
--
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
| |
| =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= 2004-01-27, 8:35 am |
| Rich Teer <rich.teer@rite-group.com> writes:
quote:
> On Tue, 27 Jan 2004, Måns Rullgård wrote:
>
>
> Bad software engineering. If it's a new version of the library,
> it should have a new version number. Unless the "new" version
> just has bug fixes and does not introduce new interfaces or remove
> old ones.
Go read the libtool manual. It has a rather good explanation of how
to do things properly.
quote:
>
> No, the old one should be called (for example), /usr/lib/libfoo.so.1,
> and the new one should be called /usr/lib/libfoo.so.2. (Or .so.1.1,
> depending on your numbering scheme).
That would depend on what sort of changes were done between the
versions. If the new version is backward compatible with the old one
it should be named in a way that allows programs to use it without
relinking.
quote:
>
> That's what package managers are for. :-)
Yes, and rm is my package manager.
quote:
> It almost sounds like you're a fan of the DLL-hell that Windoze
> lusers have to put up with... :-)
Not at all. If I include all versions in my LD_LIBRARY_PATH I get the
same behavior as if all files were in the same directory, in the
absence of rpath, that is. Splitting them into directories gives more
control, not less.
--
Måns Rullgård
mru@kth.se
| |
| Rich Teer 2004-01-27, 9:35 am |
| On Tue, 27 Jan 2004, Måns Rullgård wrote:
quote:
> Go read the libtool manual. It has a rather good explanation of how
> to do things properly.
I don't use libtool to create libraries.
quote:
> That would depend on what sort of changes were done between the
> versions. If the new version is backward compatible with the old one
> it should be named in a way that allows programs to use it without
> relinking.
Agreed; that's why you'd link against (say) libfoo.so or libfoo.so.1.
In the later case, libfoo.so.1 might be a link to libfoo.so.1.1.4,
which was the last version to be released before the incompatible
libfoo.so.2 came out.
quote:
> Yes, and rm is my package manager.
Hmm...
quote:
> Not at all. If I include all versions in my LD_LIBRARY_PATH I get the
> same behavior as if all files were in the same directory, in the
> absence of rpath, that is. Splitting them into directories gives more
> control, not less.
Why on Earth would you want N (not necessarily unique) versions of a
library installed, where N is the number of applications that use it?
One of the great advantages of dynamic libraries over static
linking is the fact that when you update the shared library,
everything that depends on that library automagically gets
the new version, without relinking or recompiling.
Granted this requires a certain amount of discipline from
application AND library writers, but it's not called
software ENGINEERING for nothing.
With the scheme you propose, you'd have to update N copies
of that library and/or change LD_LIBRARY_PATH in N wrapper
scripts. Both of those are tedious and error prone.
--
Rich Teer, SCNA, SCSA
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
| |
| =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= 2004-01-27, 10:35 am |
| Rich Teer <rich.teer@rite-group.com> writes:
quote:
> On Tue, 27 Jan 2004, Måns Rullgård wrote:
>
>
> I don't use libtool to create libraries.
Maybe not, but the chapter on versioning is good nonetheless.
quote:
>
> Agreed; that's why you'd link against (say) libfoo.so or libfoo.so.1.
> In the later case, libfoo.so.1 might be a link to libfoo.so.1.1.4,
> which was the last version to be released before the incompatible
> libfoo.so.2 came out.
>
>
> Hmm...
>
>
> Why on Earth would you want N (not necessarily unique) versions of a
> library installed, where N is the number of applications that use it?
I don't. I have exactly one copy of each version I might want to use.
quote:
> One of the great advantages of dynamic libraries over static
> linking is the fact that when you update the shared library,
> everything that depends on that library automagically gets
> the new version, without relinking or recompiling.
Exactly. Except if you install the new version in a different place,
the stupid rpath causes the old to be used anyway.
quote:
> Granted this requires a certain amount of discipline from
> application AND library writers, but it's not called
> software ENGINEERING for nothing.
>
> With the scheme you propose, you'd have to update N copies
> of that library and/or change LD_LIBRARY_PATH in N wrapper
> scripts. Both of those are tedious and error prone.
Not at all. I have a very simple script that sets up the environment
to use the desired versions of things, or the latest version if none
is specified.
--
Måns Rullgård
mru@kth.se
| |
| James Antill 2004-01-29, 6:34 pm |
| On Tue, 27 Jan 2004 19:35:58 +0100, Måns Rullgård wrote:
quote:
> joe@invalid.address writes:
>
>
> It looks like the GNU glibc dynamic linker searches rpath first. Maybe
> I'll just hack mine to do what I want it to.
It was hard to work out which post to reply to, but anyway, rpath is not
that evil...
-rpath on Linux (and Solaris) can do both what you want and what you don't
want. On Linux ld currently requires...
--enable-new-dtags -rpath <dir>
....to enable the rpath to use the DT_RUNPATH instead of DT_RPATH types
(which means it'll search the directory after LD_LIBRARY_PATH, and not
before as happens with DT_RPATH), Solaris (and AIUI future Linux ld's)
use DT_RUNPATH by default and can be configured to use DT_RPATH (to get
the non-override behaviour).
For more info. See "man ld" and...
http://mail.gnu.org/archive/html/bu...0/msg00192.html
--
James Antill -- james@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/
| |
| =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= 2004-01-29, 8:34 pm |
| James Antill <james-netnews@and.org> writes:
quote:
> It was hard to work out which post to reply to, but anyway, rpath is not
> that evil...
>
> -rpath on Linux (and Solaris) can do both what you want and what you don't
> want. On Linux ld currently requires...
>
> --enable-new-dtags -rpath <dir>
>
> ...to enable the rpath to use the DT_RUNPATH instead of DT_RPATH types
> (which means it'll search the directory after LD_LIBRARY_PATH, and not
> before as happens with DT_RPATH), Solaris (and AIUI future Linux ld's)
> use DT_RUNPATH by default and can be configured to use DT_RPATH (to get
> the non-override behaviour).
Thanks for the information. I'll see if I can do something evil to my
ld so it uses DT_RUNPATH by default.
--
Måns Rullgård
mru@kth.se
|
|
|
|
|