On Tue, Sep 17, 2002 at 12:46:19AM +0100, Pier Fumagalli wrote: > On 17/9/02 0:13, "Greg Stein" <[EMAIL PROTECTED]> 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 against? 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 interface. (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. Cheers, -g -- Greg Stein, http://www.lyra.org/
