httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: apr-related ABI issues for apreq2 packagers
Date Sat, 22 Jan 2005 16:11:24 GMT
Joe Schaefer wrote:
> 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".

in which case the versioning you have suggested:

 >>>    libapreq2.so.0.0.24 (ABI-compat with apr-0)
 >>>    libapreq2.so.1.0.24 (ABI-compat with apr-1)

contradicts with your own words above. if both libs above are the same, 
why would you introduce a different version number?

Notice that the only difference in my suggestion compared to yours was to 
move the part that's not related to libapreq out of the version part, 
exactly to avoid the confusion. In other words, I've suggested:

 >>>    libapreq2-0.so.0.24 (ABI-compat with apr-0)
 >>>    libapreq2-1.so.0.24 (ABI-compat with apr-1)

but I understand that changing the name of the lib might be a problem.

Looking at my /usr/lib I see examples like:

libbfd-2.15.90.0.3.so
libdirectfb-0.9.so.20.0.0
libwx_gtk2u_xrc-2.5.so.3.0.0

where if I'm not mistaken the first group of numbers stand for the ABI, 
and the second the actual version number.

> 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.

Sure, that's fine with me.


-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Mime
View raw message