I've noticed a rather annoy behavior when I link to .so files. It always links to the specific version. e.g. libxerces-c.so.24 So if I have libxerces-c.so.25 installed, the program fails to run. Shouldn't it link to libxerces-c.so? What's the standing practice with .so files?

Create a symbolic link that points to the "current" lib file, then link to the symbolic link.

Quote: Original post by rypyr
Create a symbolic link that points to the "current" lib file, then link to the symbolic link.

I believe the common practice is to link a major version library name, like "somelibv2.so" and then create a symbolic link from that to the specific library, which may be called something like "somelibv2.24.so".

That way all you have to do when you upgrade the library is move the symbolic link and all the apps that link to the library will switch over without problems.

EDIT: Corrected grammar error

Quote: Original post by MonkeyCookie

Quote: Original post by rypyr
Create a symbolic link that points to the "current" lib file, then link to the symbolic link.

I believe the common practice is to link a major version library name, like "somelibv2.so" and then create a symbolic link from that to the specific library, which may be called something like "somelibv2.24.so".

That way all you have to do when you upgrade the library is move the symbolic link and all the apps that link to the library will switch over without problems.

That's exactly what I meant, but I realize we're using "link" in two senses here...

Let's say you install blah version 1.0 and it comes with file libblah-1.0.so. Do the following in /usr/lib:

$ ln -s libblah-1.0.so libblah.so

This creates a symbolic link in the directory structure. You have a "logical" file called "libblah.so" that actually points to the real file "libblah-1.0.so".

Now in your makefile (or in the command-line for the linker, ld), you specify to link to libblah.so with the following option (that's a lower-case ell below):

-l blah

Next you upgrade to Blah version 1.1 adn it comes with file libBlah-1.1.so. Do the following in /usr/lib:

$ rm libblah.so$ ln -s libBlah-1.1.so libblah.so

And then you're good to go. Upon next invocation of your application the new library should be linked in.

Regards,
Jeff

Linux (among others) shared objects are named with libNAME.so.MAJOR.MINOR.MICRO. Traditionally, the "major" version number is only changed when binary compatibility is broken or some other large change is made. Libraries that include the version number in the shared object's name (e.g., glib-2.0) often leave the "major" version number at 0 or 1. A library that commonly breaks binary compatibility (there's a couple out there) or changes the "major" version number often for no good reason is making its users go through unnecessary trouble.

Quote: Original post by rypyr

Quote: Original post by MonkeyCookie

Quote: Original post by rypyr
Create a symbolic link that points to the "current" lib file, then link to the symbolic link.

I believe the common practice is to link a major version library name, like "somelibv2.so" and then create a symbolic link from that to the specific library, which may be called something like "somelibv2.24.so".

That way all you have to do when you upgrade the library is move the symbolic link and all the apps that link to the library will switch over without problems.

That's exactly what I meant, but I realize we're using "link" in two senses here...

Let's say you install blah version 1.0 and it comes with file libblah-1.0.so. Do the following in /usr/lib:

$ ln -s libblah-1.0.so libblah.so

This creates a symbolic link in the directory structure. You have a "logical" file called "libblah.so" that actually points to the real file "libblah-1.0.so".

Now in your makefile (or in the command-line for the linker, ld), you specify to link to libblah.so with the following option (that's a lower-case ell below):

-l blah

Next you upgrade to Blah version 1.1 adn it comes with file libBlah-1.1.so. Do the following in /usr/lib:

$ rm libblah.so$ ln -s libBlah-1.1.so libblah.so

And then you're good to go. Upon next invocation of your application the new library should be linked in.

Regards,
Jeff

This is what I expect, but not the behavior I observe. If I link to a symlink, it links to the hard-file, not the symlink name.
In your example the program would fail to start-up without libblah-1.0.so, even if libBlah-1.1.so is installed and symlinked to libblah.so (which is what the elf was linked to).

I'll run some trials later and see what I have wrong ;)

Linker option -soname (on the gcc command line specify it as -Wl,-soname)

Quote:
-soname=name
When creating an ELF shared object, set the internal DT_SONAME field to the specified name. When an executable is linked with a shared object which has a DT_SONAME field, then when the executable is run the dynamic linker will attempt to load the shared object specified by the DT_SONAME field rather than the using the file name given to the linker.

If you do give a soname to your library when you build it, it ought to go an try to find the 'right' version. I hope it helps. :)