httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: apr-related ABI issues for apreq2 packagers
Date Sun, 23 Jan 2005 21:49:10 GMT
Max Kellermann <> writes:

> On 2005/01/21 18:51, Joe Schaefer <> 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,
>> (ABI-compat with apr-0)
>> (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

We try to follow the general conventions laid out in

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:

> 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

View raw message