httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: apr-related ABI issues for apreq2 packagers
Date Sun, 23 Jan 2005 21:49:10 GMT
Max Kellermann <max@duempel.org> writes:

> On 2005/01/21 18:51, Joe Schaefer <joe+gmane@sunstarsys.com> wrote:
>> One thought that comes to mind is to encourage
>> such people to tweak our major number to suit
>> their needs (but not change the "libapreq2"
>> library name).  In other words, they might
>> choose to reduce our current major number 
>> from 2 to 0 when compiling against libapr-0,
>> from 2 to 1 when compiling against libapr-1,
>> 
>>     libapreq2.so.0.0.24 (ABI-compat with apr-0)
>>     libapreq2.so.1.0.24 (ABI-compat with apr-1)
>
> One general question on this topic... why does libapreq2 have its
> major version 2 both in the library name AND in the library version
> (.so.X)?  If I were to decide, I had never appended the "2" to the
> library name, and just call it libapreq.so.2.

We try to follow the general conventions laid out in 

    http://apr.apache.org/versioning.html

Some cosmetic differences: we set major our number to match
the soname, apr always uses "0". We don't use a dash in the name
either.  I think the concepts there derive from Havoc Pennington's 
article, which explains why a versioned soname and INC path 
makes parallel installations a bit easier for C developers:

    http://www106.pair.com/rhp/parallel.html
       
[...]

> But we shouldn't just make a "recommendation" of this case,
> we should hard code our decision (whatever of the two it may be)
> in our build scripts. Everything else endangers binary
> compatibility between different distributions.

That's the core issue: should *we* tinker with our major number 
based on apr's ABI, or should we always leave it "2"?   IMO
we should always leave ours at "2", no matter which apr version
a user links us against.

-- 
Joe Schaefer


Mime
View raw message