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

Gary Oberbrunner garyo at oberbrunner.com
Wed Jan 1 17:17:01 EST 2014


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:


>

> -----BEGIN PGP SIGNED MESSAGE-----

> Hash: SHA1

>

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

>

> -----BEGIN PGP SIGNATURE-----

> Version: GnuPG v1.4.14 (GNU/Linux)

> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

>

> iQIcBAEBAgAGBQJSxEMjAAoJEGmqNTFmabRELl0P/2gOTRIr4Cmtj2ivynvlDH27

> JijbWRRoQT2K4VYtFwoId3pIaZrgTky76z5jTNq9bwkHTb/l7HtQkWpmdDqwdEZe

> Vx5gx0It0OByQi8PkSqW7zOjgm59yezIFfCHS6J6HrsZIxXNUsujjaQ0xvhI7C/u

> Tv9BFT+pTz/D34UBlbMM5vakmUWQyQP0Bx2yl/GOYoxtmjxUJRpSSO3lIAoUqpMW

> L66BDycrZgHaesCsxvKR6tIy9yOUOcqPHtU+7AmqkUfeXV8FfomduOJSscaAf9y9

> OuRCDWV+6vb6E+hriFcxo+veUU79xBla7ZIsZ28U+sBdHxygMxRh1Hi6+M6XeQHy

> YBwXj9mbk6M8qnZoiiIAZpfcegXC2IJO5vX748XOITq0tsGLi2gKft92dcMkH0If

> Ad37SnpOiMwk1EhfHdtIYSiFB8yXjbDk6WBhtl/+Z05jGOtIifzWUYEjUm2F1N+A

> iKkNJEXxtIqcxhtTHvNb/ocWV9/7HoKX5FfOp/VhvvmrrKgSAZzHPJ2LvOP6dcOz

> aK8A4LSfi9cGevApkutFxVusZSyL4wC8aoOSwVZmpp16ScuVqXxjE2WmcLlx27Xa

> tMdhsD66M/Gy+xTSxFNt0xu5dKC5mJQ+j8RrkTC/0EuacLiI+aQEpqSo0cdRVVHl

> EqT6uaHpCASXn+5Z5xMh

> =QlVK

> -----END PGP SIGNATURE-----

>

> _______________________________________________

> Scons-dev mailing list

> Scons-dev at scons.org

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

>




--
Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20140101/7895d419/attachment.htm>


More information about the Scons-dev mailing list