[Scons-dev] Versioned libraries: non-standard sonames

[David García Garzón]

El 08/01/14 20:03, Gary Oberbrunner ha escrit:

> On Wed, Jan 8, 2014 at 9:52 AM, David García Garzón <david.garcia at upf.edu>wrote:

>

>> Yep, i am doing such a suggestion. Well documented should not be a big

>> issue.

>>

>> But the variable i am refering to, SOVERSION is one that i introduced in

>> a previous mail. I was proposing to rename it as ABIVERSION because the

>> SOVERSION refers to ELF platform, while ABIVERSION refers to the more

>> wide concept of ABI compatibility.

>>

>> So, repeating again, we should add this flag:

>>

>>     -Wl,-soname="$SONAME"

>>

>> And then defining SONAME by default as something like:

>>

>> env["SONAME"]="$SHLIBPREFIX$TARGET$SHLIBSUFFIX.$ABIVERSION"

>> env["ABIVERSION"]="${'.'.join(SHLIBVERSION.split('.')[:ABIVERSIONLEVELS])}"

>>     env["ABIVERSIONLEVELS"]=1

>>

>>

> This is generally good.  We're already generating the -Wl,-soname arg in

> VersionedSharedLibrary (except for OpenBSD), so this just gives an escape

> hatch for users to set it to something else.


I didn't know that OpenBSD deals with libraries in a different way, But
if it still deals with ABI versioning differently, that's a point for
what i explain bellow.


> Actually I'm not sure ABIVERSION and ABIVERSIONLEVELS are really needed;

> the default value for SONAME can just contain the ${...} expression

> directly.  If users want to override SONAME they can set that to whatever

> they want, e.g. "$SHLIBPREFIX$TARGET$SHLIBSUFFIX.99".  What do you think

> about that?  It seems simpler to me.


SONAME (libyourname.so.1.2) is a platform specific concept. ABIVERSION
(1.2) is useful to bring the concept of abi compatibility to other
platforms which don't use sonames. You can generate the soname from the
ABIVERSION and you can generate whatever means other platforms need to
define ABI compatibility as well.

For example, in windows you could decide to generate the dll's with
diferent names for different ABIs (yourname1_2.dll) and inserting the
full version on the dll metadata. Similarly to how M$ does with their
runtime libraries.

In macosx, we could set the library metadata and links accordingly.
"compatibility_version", "installed_name" and so on. That was what i was
still trying to understand.

So, in summary, ABIVERSION enables dealing with platform dependant
behaviours regarding ABI compatibility without tainting the user SCons
files with platform dependant code, which is one of SCons goals. SONAME
is useless for that purpose (and still useful if soname based platforms
have to behave differently).



On the other hand, ABIVERSIONLEVELS is not a such hard requirement to
me, but a "don't repeat yourself" goodie.

If you want a two levels scheme for the ABI without ABIVERSIONLEVELS you
write:

env.SharedLibrary(....
    SHLIBVERSION="1.2.3",
    ABIVERSION="1.2",
)

And you have to update the version twice (or use some code similar to
what i proposed, but in the user SCons file).

A use case we are dealing with in our project makes it more useful: If
you generate multiple libraries with different versions, but all using
the same soname schema, say two first levels. In this case you can just
define once:

env['ABIVERSIONLEVELS']=2

And then just define for each library:
env.SharedLibrary("clam_core", ...
    SHLIBVERSION="1.2.3",
env.SharedLibrary("clam_spatialaudio", ...
    SHLIBVERSION="4.5.6",
or whichever version individual libraries have.

Moreover, by defining by default ABIVERSIONLEVELS=1, you get the current
SCons behaviour.

Buy them?



>> I am still scratching at the mac osx documentation to understand how ABI

>> compatibility works in that platform because for what i read, neither

>> the actual SCons code nor the one i had in my project handle that right.

> OK, that sounds like a different patch perhaps, but a welcome one.


Well, here a MacOSX expert would be nice to come into the discussion
because i just can figure out how could it be but not how it  is
actually used.

The same goes for OpenBSD, which i just noticed by you it is not using
sonames. I am sure not having sonames, they still have other means to
ensure abi compatibility.


David.