apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <p...@betaversion.org>
Subject Re: library versioning name
Date Mon, 16 Sep 2002 23:46:19 GMT
On 17/9/02 0:13, "Greg Stein" <gstein@lyra.org> wrote:

> On Mon, Sep 16, 2002 at 06:00:20PM -0500, Ben Collins-Sussman wrote:
>> rbb@apache.org writes:
>> 
>>> Why did we choose libapr-#.so?  Most other libraries use libapr.so.#,
>>> which allows you to continue to do -lapr.  Is there a reason we chose to
>>> do something different???
>> 
>> Subversion switched to naming our many libraries "libsvn_foo-1.so"
>> last June, based on this rationale:
>> 
>>     http://www106.pair.com/rhp/parallel.html
>> 
>> I suspect that gstein may have spread the same gospel to APR
>> recently.  :-)
> 
> Yes. APR is all about being a library, so supporting parallel installations
> is practically mandatory. Take a look at Berkeley DB as a great example. I
> have db1, db2, db-3.1, db-3.2, and db-4.0 on my machine. My applications can
> choose the particular version that they require. The .so.# does not provide
> for that.
> 
> Similar issues arise for selecting the header files.
> 
> I've got a sneaky feeling we may need to do more with the *-config scripts,
> but I'm not yet sure there. May need to write Havoc to get his feedback.

I'm slightly against this approach for the OSes I use (Solaris and MacOS/X,
dunno if it's possible to do on others) because, for instance, both ELF and
Mach-O binaries "remember" the name of the library I linked against when
properly versioned (and that is _not_ what libtool does, that's why I hate
that .... thing)...

Basically, on my system, I have this setup (for example with libdb):

/usr/lib/libdb.so -> libdb.so.4.0.14
/usr/lib/libdb.so.4.0 -> libdb.so.4.0.14
/usr/lib/libdb.so.4.0.14
/usr/lib/libdb.so.3.3 -> libdb.so.3.3.11
/usr/lib/libdb.so.3.3.11

Now, I have few binaries that I still didn't recompile that are using DB-3.3
(I just brought them over from an old system) but when I ldd them:

[pier@pulse] ~ $ uname -srn
SunOS pulse.betaversion.org 5.8
[pier@pulse] ~ $ ldd /opt/cyrus/bin/imapd | grep libdb
        libdb.so.3.3 => /usr/lib/libdb.so.3.3.11
[pier@pulse] ~ $ ldd /opt/subversion/bin/svnadmin  | grep libdb
        libdb.so.4.0 => /usr/lib/libdb.so.4.0.14
[pier@pulse] ~ $

So, although I linked it against -ldb, it finds the correct version of the
library because:

[pier@pulse] ~ $ elfdump /usr/lib/libdb.so.4.0.14 | grep SONAME
       [1]  SONAME   libdb.so.3.3
[pier@pulse] ~ $ elfdump /usr/lib/libdb.so.3.3.11 | grep SONAME
       [1]  SONAME   libdb.so.4.0
[pier@pulse] ~ $

... Linking preserves the name in my libraries, and puts it's SONAME in the
binary linked against it, so no problems there...

Regarding headers, seriously, if I compile something today, I want it to
link against the very latest version of the library, because I want all
possible patches and updates, so I don't really see that problem...

This document <http://www106.pair.com/rhp/parallel.html> only talks about
Linux, which is a platform I luckily don't use nor know, but AFAICS, it
should work on all of them: works on FreeBSD/NetBSD, and on NetBSD it's how
EVERYTHING is compiled... For instance:

[pier@dodo] ~ $ uname -srn
NetBSD dodo.betaversion.org 1.6E
[pier@dodo] ~ $ readelf --all  /usr/lib/libcurses.so | grep -i SONAME
 0x0000000e (SONAME)                     Library soname: [libcurses.so.5]
[pier@dodo] ~ $ 

So, I seriously don't see why one should "encode" the version number in the
name of the library, SONAME does the trick so nicely... (I actually
recompile everything to follow SONAME, otherwise I get confused! :)

    Pier


Mime
View raw message