apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: library versioning name
Date Tue, 17 Sep 2002 01:00:24 GMT
On Tue, Sep 17, 2002 at 12:46:19AM +0100, Pier Fumagalli wrote:
> On 17/9/02 0:13, "Greg Stein" <gstein@lyra.org> wrote:
> > 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)...

They *remember* yes, but how do you choose *up front* which one to link

With parallel versioning, I can link my "early" APR app with:

$ ld ... -lapr-0

But my newfangled one does:

$ ld ... -lapr-1

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

Yup. But try and build those *today* and have them still link against
DB-3.3. You need the parallel install stuff.

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

That is your choice, but apps are build to specific APIs, and they must
compile against those specific APIs. By definition /include/apr-0/ defines a
*different* interface than /include/apr-1/. Thus, your application will be
designed for one or the other, and needs to compile against the correct

(and yah: it might be possible to build an app that compiles against both,
 but that might not always be the case... could you imagine trying to build
 an app for GTK 1.0 *and* GTK 2.0... screw that. you choose one.)

I was in the same camp for a while, too "soname handles it", then I really
thought more on it. soname only handles runtime linking. It doesn't handle
build selection.


Greg Stein, http://www.lyra.org/

View raw message