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 Sat, 22 Jan 2005 08:03:02 GMT
Stas Bekman <stas@stason.org> writes:

> Joe Schaefer wrote:

[...]

>> 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)
>> But as far as we're concerned, we don't specify
>> which apr ABI they should choose, and the libapreq2.so
>> we produce will always have major-number 2. We offer
>> source code, and so long as we play by the normal
>> versioning rules, I think that's  good enough for us here.
>> What do you think of this?
>
> I think it's a good idea to have:
>
> libapreq2-apr0_9.so.x.xx
> libapreq2-apr1_0.so.x.xx
> libapreq2-apr2_0.so.x.xx
>
> where x.xx is the current apreq version. well,
> pretty similar to your suggestion, but moving the apr
> generation part out of the module version, so it's not 
> confusing the people.

I think that idea (modifying the soname) goes way too 
far.  No matter how someone selects the ABI, the libapreq2 
source is always the same.  The soname always shows up in 
the linker flag (-lapreq2), but your idea basically assigns 
three different sonames to the same source code (and eventual
release tarball).  That's *very* confusing to me; it may force 
us to support that concept in our eventual release (multiple 
apreq2-config scripts also?), and it's not something I've seen 
any other C library do before.

The's a good collection of relevant discussions in the 
subversion-dev archives, where these ABI issues are 
discussed in detail (they face the same type of ABI 
problems we do here).  If you're interested, a search 
on "httpd apr abi" in marc's subversion-dev archive 
will locate lots of well-considered threads on the subject.
FWIW, I totally agree with the folks there who suggested
that the choice of apr ABI is a platform-specific issue
that properly belongs in the package manager's domain,
not one that developers should try to arbitrarily impose.

All I suggest in this thread is that apreq2 package 
managers may choose to adjust our shared library's major 
number, if that helps them cope with the new httpd 2.2 ABI.
Doing so will never conflict with any of our own source 
releases, so long as they choose major numbers other 
than "2".

If we offer them much more rope than this, I think it'll 
come back to bite us (their bugs becoming our bugs, etc).
In fact, even this idea may be too much, and it might
be better for us to say nothing at all on the subject.

-- 
Joe Schaefer


Mime
View raw message