On 17/9/02 0:13, "Greg Stein" <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 16, 2002 at 06:00:20PM -0500, Ben Collins-Sussman wrote:
>> [EMAIL PROTECTED] 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:
[EMAIL PROTECTED] ~ $ uname -srn
SunOS pulse.betaversion.org 5.8
[EMAIL PROTECTED] ~ $ ldd /opt/cyrus/bin/imapd | grep libdb
libdb.so.3.3 => /usr/lib/libdb.so.3.3.11
[EMAIL PROTECTED] ~ $ ldd /opt/subversion/bin/svnadmin | grep libdb
libdb.so.4.0 => /usr/lib/libdb.so.4.0.14
[EMAIL PROTECTED] ~ $
So, although I linked it against -ldb, it finds the correct version of the
library because:
[EMAIL PROTECTED] ~ $ elfdump /usr/lib/libdb.so.4.0.14 | grep SONAME
[1] SONAME libdb.so.3.3
[EMAIL PROTECTED] ~ $ elfdump /usr/lib/libdb.so.3.3.11 | grep SONAME
[1] SONAME libdb.so.4.0
[EMAIL PROTECTED] ~ $
... 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:
[EMAIL PROTECTED] ~ $ uname -srn
NetBSD dodo.betaversion.org 1.6E
[EMAIL PROTECTED] ~ $ readelf --all /usr/lib/libcurses.so | grep -i SONAME
0x0000000e (SONAME) Library soname: [libcurses.so.5]
[EMAIL PROTECTED] ~ $
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
