cURL / Mailing Lists / curl-library / Single Mail


Re: [RFC PATCH] symbols versioning

From: Alessandro Ghedini <>
Date: Mon, 19 Dec 2011 11:21:53 +0100

On Mon, Dec 19, 2011 at 09:57:23AM +0100, Daniel Stenberg wrote:
> On Sun, 18 Dec 2011, Alessandro Ghedini wrote:
> >Attached is the (hopefully) final version of the patch :)
> Thanks!
> >A little note: currently the major soname version ("4") is
> >hardcoded in the lib/ file, so that it will need to
> >be manually changed when the soname will be bumped. AFAICT,
> >currently the version info to pass to ld is only set in
> >lib/ so that there is no easy way to make this process
> >automatic.
> That's very unfortunate and it feels like something that we'll
> forget to update the distant day in the future when we bump the
> major SONAMe number. Possibly it'll be so rare that it won't be a
> big deal.
> There's not even any 4 in lib/ as the current version
> info is actually 6:0:2 which happens to get translated to major
> number 4 on most systems.

The 4 represents the first interface compatible with the current one. You
have 6 as the current interface version, and 2 as the age, which means that
the library can be linked with executables that were built using up to two
of the previous library interfaces (which means from 4 to 6).

> But it also made me think more. What exactly is that number in the
> version-script supposed to be used for? If we add functions to the
> API shouldn't, we then (if we want to be technically correct) add a
> new "label" in the version-script for that? If so, shouldn't then
> the label either match the full SONAME number or perhaps even the
> libcurl version string when the symbol is introduced to make it
> clearer to those who'd see an error message?

To do that we should manually track each symbol exported by libcurl to the
version it was introduced or modified the last time and build the versioning
script accordingly, which could become quite cumbersome (take for example
one of the versioning script of the glibc [0]) and it wouldn't be that
helpful given that interface changes do not happen that often in libcurl.
Also, if you were afraid of missing to update the script for a major soname
bump, it would become more likely to forget something, since you would have
to update the script for every interface change. Not that it is impossible
or anything, it would just require more work in the future.

As they are now, the versioned symbols make clear what are the compatible
interfaces with a given executable, and what SSL implementation that
executable was meant to use (I think this is what the original author of the
patch meant to do).



perl -E'$_=q;$/= @{[@_]};and s;\S+;<inidehG ordnasselA>;eg;say~~reverse'
List admin:
Received on 2011-12-19