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

[David García Garzón]

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


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.




El 01/01/14 23:17, Gary Oberbrunner ha escrit:

> Hi David; the variable in question is SHLIBVERSION I think.  Are you

> suggesting changing the logic in Tool/__init__.py where it splits that

into

> major, age, revision and uses major in the soname (-Wl,-soname=%s) so that

> a different version number can be used in the soname, different from the

> major version in SHLIBVERSION?  That seems like a reasonable type of

> flexibility, though it could be confusing if misused of course (as you

> point out).

>

>

> On Wed, Jan 1, 2014 at 11:32 AM, David García Garzón

> <david.garcia at upf.edu>wrote:

>

>>

> El 01/01/14 00:30, William Deegan ha escrit:

> >>> David,

> >>>

> >>>

> >>> On Dec 31, 2013, at 10:12 AM, David García Garzón

> <david.garcia at upf.edu> wrote:

> >>>

> >>>> I've been trying out the versioned libraries feature. As I said i do

> >>>> like the nice interface you guys finally got. But i would like to

> >>>> comment two issues i found. I open this thread about the first one:

> >>>> Non-standard Sonames

> >>>>

> >>>> Current implementation forces you to set the major version number

as the

> >>>> soname suffix for your library. This is convenient in many cases, but

> >>>> this doesn't cover the undesiderable but real cases in which the

soname

> >>>> must be changed more than once between major versions.

> >>>

> >>>

> >>>>

> >>>> Indeed in our project we left the first version for API changes,

and the

> >>>> second version for ABI changes and the last one for ABI safe

changes. So

> >>>> our soname has two version numbers and i think we are not a rare

case.

> >>>> Indeed some projects have unrelated sonames and library names,

that is

> >>>> far from ideal but real. So in general, i see convenient to be

able to

> >>>> explicitly set the soversion for the library.

> >>>>

> >>>> The solution i am thinkin on, in pseudo-python, would be:

> >>>>

> >>>> soname = (

> >>>>  $SONAME if $SONAME else

> >>>>  libname+$SOVERSION if $SOVERSION else

> >>>>  libname+majorversion($SHLIBVERSION) if $SHLIBVERSION

> >>>> )

> >>>>

> >>>> So, how do you feel about this feature? I feel bold to implement it

> >>>> myself, so give me a bless and i'll go for it.

> >>>

> >>> So what would a linker command line look like for your use model?

> >>> -Bill

>

> Structurally the command line does not change. At some point we add the

> "-Wl,-soname=%s" flag in gcc tool chain specifying the soname and then

> we create the symlink with the same name specified at the flag. I am

> just arguing about how to compute such soname.

>

> My suggestion would be adding the following flag instead:

>

>     -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

>

> I just renamed previous SOVERSION as ABIVERSION because SONAME is

> posix/linux centric and ABI compatibility version is a crossplatform

> concept. I am opening a different discussion thread on this because i

> think we are using it badly in Darwin and not using it at all in windows

> platforms (cygwin, msvc and mingw).

>

> David.

>

>>

>> _______________________________________________

>> Scons-dev mailing list

>> Scons-dev at scons.org

>> http://two.pairlist.net/mailman/listinfo/scons-dev

>>

>

>

>

>

>

> _______________________________________________

> Scons-dev mailing list

> Scons-dev at scons.org

> http://two.pairlist.net/mailman/listinfo/scons-dev