[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gnutls-dev] Re: gnutls's sonames
From: |
Tim Ringenbach |
Subject: |
[gnutls-dev] Re: gnutls's sonames |
Date: |
Thu, 10 Mar 2005 18:29:28 -0600 |
User-agent: |
Mozilla Thunderbird 0.8 (X11/20041020) |
Simon Josefsson wrote:
Tim Ringenbach <address@hidden> 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