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.
The problem with that is that people will more than likely be building against apr, rather than a specific apr version, as the API has nearly solidified, etc. (i'm assuming we're not too far away from bugfix/new feature mode).
So this parallel install stuff is only for those who've been using APR as it's been developing. I imagine some will port their apps to the release release version of apr. Of course some won't too.
it's also for later down the road when we release apr 2.0.
the point is that we still need the -lapr convention to work, to grab the latest version. Is there any way we can do both? eg, on a linux system:
/usr/lib/libapr-#.so... (specific version) /usr/lib/libapr.so ... (latest)
or something similar....
can't apr-config handle this issue? as long as people are using it to generate their makefiles, then they're all set. of course, down the road when there are multiple incompatable versions of apr lying around (i don't count the ones we have now, since they're pre 1.0, and it's expected that they will break), apr-config will have to get smarter about it...
-garrett
