On 4/7/06, Philip Martin <philip@codematters.co.uk> wrote:
> As I understand it, the reason APR 0.9 doesn't have LFS is that it
> would be an ABI change. I find it odd that the same ABI change is
> perfectly acceptable in Subversion.
No. It was because APR 0.9.x has pooched LFS autoconf detection on
Linux. LFS on Solaris and other platforms works fine in 0.9.x for
some cases - with the proper incantations APR 0.9.x will do LFS too on
Linux. APR 1.0.0 was the first release that has reliable autoconf LFS
checks that work on Linux and everywhere else we care about out of the
box.
Even then, it's still very possible for LFS to be toggled on or off
even in the same 'library' version of APR/APR-util. Same goes for
threading, mmap, etc.
> I don't understand why that matters, a third party object using the
> Subversion ABI won't usually use Subversion's libtool. I accept that
> if such an object is linked explicitly with libapr as well as libsvn
> then changing the SONAME won't solve the problem, but for the objects
> that are not linked explicitly against libapr the SONAME is a
> solution.
Those apps *should* be linking with libtool. If not, it's very likely
that it may not compile or link appropriately. At a minimum, it needs
to use APR's compiler and link options or bad things may occur.
> Is that sufficient reason to do nothing? Changing the SONAME might
> not be a perfect solution, but it handles the common case of
> http-2.0/apr-0.9 and http-2.2/apr-1.2.
My opinion is that it won't really help. The only real way to do it
is to enforce run-time APR version checks - like we do with BDB. We'd
call apr_version/apu_version; but Subversion has never required any
initialization calls - other than apr_initialize(). So, again, this
is a problem that only downstream devs can deal with. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 7 22:22:56 2006