Author Topic: SONAME field for shared libraries?  (Read 1604 times)

Lorni

  • Posts: 49
SONAME field for shared libraries?
« on: 1 Jan '13 - 15:06 »
To provide version backwards-compatibility information.
Is it possible to set soname for shared libraries? http://en.wikipedia.org/wiki/Soname

Code: [Select]
# objdump libbass.so -p | grep SONAMEor
Code: [Select]
# readelf -d libbass.so | grep SONAMEshows nothing.

I try to make Debian package lintian clean. http://en.wikipedia.org/wiki/Lintian

lintian reports:
Quote
sharedobject-in-library-directory-missing-soname
http://lintian.debian.org/tags/sharedobject-in-library-directory-missing-soname.html

Quote
A shared object was identified in a library directory (a directory in the standard linker path) which doesn't have a SONAME. This is usually an error.

SONAMEs are set with something like gcc -Wl,-soname,libfoo.so.0, where 0 is the major version of the library. If your package uses libtool, then libtool invoked with the right options should be doing this.

To view the SONAME of a shared library, run readelf -d on the shared library and look for the tag of type SONAME.

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: SONAME field for shared libraries?
« Reply #1 on: 2 Jan '13 - 14:27 »
My understanding is that the purpose of a SONAME is to facilitate installing multiple versions of a library alongside each other, but I'm not sure that's possible with the way that the BASS libraries are named currently, eg. it's always "libbass.so" rather than something like "libbass.so.2.4.9". With all versions having the same filename, that means the libraries should be installed alongside an application (eg. in its own directory) rather than separately to a central location (eg. "/lib" or "/usr/lib"). I think switching to a SONAME system would complicate matters, eg. the libraries would need to be properly installed with symlinks, and couldn't just be placed in the application's directory. Let me know if I've got that wrong.

Lorni

  • Posts: 49
Re: SONAME field for shared libraries?
« Reply #2 on: 2 Jan '13 - 15:59 »
You are absolutely right.
The major point is that the switching to a "SONAME" system would complicate matters.
Lets consider the options:
1) do nothing. The current archives are well organized. Nothing prevents to release new applications (libs are in its own directory).

2a) put additional SONAMed libs into the current archives. Lets developers decide what type of library should be used.
2b) separate SONAMed libs into additional archives.

3) Long way. It takes time. You would need a maintainer for that.
Packetize the libraries. A developer installs eg. libbass-dev_2.4-10_amd64.deb (or i386 etc.) and then does a scenario:
- includes #include <bass.h>
- puts -lbass or 'bass-config --libs' script (it outputs: "-L/usr/local/lib  -lbass")
- puts -I/usr/local/include or 'bass-config --cflags'

I am going to vote for 1+2b+3.
But as I said 1) Current system does not prevent to release new applications.
« Last Edit: 2 Jan '13 - 18:36 by Lorni »

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: SONAME field for shared libraries?
« Reply #3 on: 3 Jan '13 - 15:40 »
2a) put additional SONAMed libs into the current archives. Lets developers decide what type of library should be used.
2b) separate SONAMed libs into additional archives.

I'm not sure about that. With the i386/x86_64/arm-softfp/arm-hardfp architectures, there are already plenty of Linux builds to maintain without doubling it! :)

Perhaps there is a way to add a SONAME to an existing library? That would allow people who would like to use SONAMEs to do so.