[gnutls-dev] Re: gnutls's sonames

[Tim Ringenbach]

Simon Josefsson wrote:
> Tim Ringenbach <tim.ringenbach at comcast.net> writes:
> 
>>Our ssl support is done via plugins, so we have a ssl-nss.so plugin for
>>mozilla nss, and a ssl-gnutls.so for gnutls. The autopackage compiles
>>both, and whatever is available at runtime is used.
>>
>>Currently, the ssl-gnutls plugin depends upon libgnutls.so.11. However,
>>many people have a version of gnutls with a different soname, such as
>>libgnutls.so.10 or libgnutls.so.7, and I hear a libgnutls.so.12 is out
>>now too.
> 
> 
> Yup.
> 
> I think GnuTLS 1.1.x and 1.2.x uses libgnutls.so.12.1, and GnuTLS
> 1.0.x uses libgnutls.so.11.1.
> 
> As such, libgnutls.so.12 is supposed to be ABI compatible with
> libgnutls.so.11, according to GNU ld and the GNU Libtool philosophy,
> if I understand things correctly.  I'm not sure how rigorously this
> has been enforced or checked in GnuTLS though.

I don't think you understand things correctly. I'm not sure I understand 
everything right either, but I'll try my best to explain things as I 
understand them.

A program, (or another .so), links against an .soname. You cannot link 
against libgnutls.so.12 OR libgnutls.so.11, you must link against one, 
or the other, or both (where both means needing both versions or the 
program won't start, which is obviously not what we want).

Maybe you're confusing an soname with what you tell libtool the revision 
is? They are two different things, libtool does some kind of 
transformation before writing the filename.

Using viewcvs, i see you currently have in configure.in:
LT_CURRENT=13
LT_REVISION=25
LT_AGE=1

If I understand things right, that causes you to end up with a filename 
of libgnutls.so.12.1.25 and an soname of libgnutls.so.12
When ldconfig is run, it makes a symlink from the actual filename 
(libgnutls.so.12.1.25) to the soname (libgnutls.so.12).

For example, on my system (fc3), I have:
ls -l /usr/lib/libgnutls.so* -l
lrwxrwxrwx  1 root root     20 Feb 25 16:06 /usr/lib/libgnutls.so -> 
libgnutls.so.11.1.20
lrwxrwxrwx  1 root root     20 Feb 21 00:13 /usr/lib/libgnutls.so.11 -> 
libgnutls.so.11.1.20
-rwxr-xr-x  1 root root 448084 Sep 21 11:29 /usr/lib/libgnutls.so.11.1.20

Now if I do "objdump -p /usr/lib/libgnutls.so.11.1.20 |grep SONAME" I get:
  SONAME      libgnutls.so.11


>>What I'm probably going to do is build multiple versions of the plugin
>>against each version of gnutls. So I'll have a ssl-gnutls10.so and a
>>ssl-gnutsl11.so, etc. I expect setting up the build environment for this
>>will be a bit tricky though.
> 
> 
> Are you sure the libraries aren't sufficiently ABI compatible for your
> needs?

They are for Gaim's purposes. It doesn't use a whole lot of the API, and 
compiles fine with gnutls7 through 11 I know, and probably 12 too. But 
they have different sonames. As for as the runtime linker is concerned, 
they are totally incompatable. If a binary linked against 
libgnutls.so.12 is attempted to be loaded on a system with only 
libgnutls.so.11, it will simply fail. In our case, when we try to dlopen 
our plugin, we'll get an error, and gaim won't have ssl support, won't 
be able to log into msn, etc. If it was the gaim binary linked against 
gnutls12 (instead of just the plugin), then gaim would refuse to start. 
That's why my only options are dlopen or building the plugin multiple times.

>>What is bound to make it even trickier though, is that you don't seem to
>>document when you change your soname. Your version numbers seem to have
>>nothing to do with your so version, and your NEWS doesn't seem to
>>mention anything about such changes. So I have no idea what versions of
>>gnutls I need.
>>
>>So what's up with this? Is this documented somewhere I can't find, or
>>why isn't it documented?
> 
> 
> First, review this link:
> 
> http://www.gnu.org/software/libtool/manual.html#Versioning
> 
> That is the philosophy I will be using for 1.2.x.  I will add a
> API/ABI section in NEWS for every future 1.2.x release.

Thanks, that would be helpful. Of course, breaking abi compatalbity less 
  often would be even better ;)

Mike Hearn wrote an (unfinished) article on writing shared libraries, 
you can find it at: http://navi.cx/~mike/writing-shared-libraries.html
As I recall he wanted to call it "best practices", but no one currently 
follows many of them.

> I can't speak for older releases, perhaps Nikos knows.  If you want to
> do some archeology on the CVS server, and document what you find, that
> would be a useful contribution!  Could be added as a section in the
> manual, for instance.

I asked a friend in #gaim and he was kind enough to look it up for me 
using rpmfind.net or something:
<nosnilmot> gnutls 0.9.91 => libgnutls.so.8
<nosnilmot> gnutls 0.8.10 => libgnutls.so.7
<nosnilmot> gnutls 1.0.8 => libgnutls.so.10

I think those are just random versions with those sonames though, not 
the first, nor the latest.



Thanks for your help and the friendly reply,

--Tim