apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garrett Rooney <roo...@electricjellyfish.net>
Subject Re: library versioning name
Date Tue, 17 Sep 2002 14:50:35 GMT
James Cox wrote:
>>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


Mime
View raw message