"Justin Erenkrantz" <justin@erenkrantz.com> writes:
> 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.
That doesn't really address my point. You probably know more than me,
but as I understand it backporting full LFS to APR 0.9.x is simple
except that it would be an unacceptable ABI change. Nothing you have
written explains why you are happy to make the same ABI change in
Subversion.
> 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'm not really interested in corner cases, although I suspect that
threading is handled by 'apr-config --cflags' and that mmap doesn't
change the ABI.
>> 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.
I disagree, libtool is optional.
> At a minimum, it needs
> to use APR's compiler and link options or bad things may occur.
Agreed, but using libtool does not guarantee that the correct compiler
flags get used.
>> 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.
Care to explain why not? Note, I said it helps with the common case
of http-2.0/apr-0.9 and http-2.2/apr-1.2. I'm not proposing that we
support every possible ABI resulting from every possible configuration
of APR, but I see no reason why we should not distinguish between the
two common default configurations.
> 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
I don't think Subversion's run-time checks are any sort of magic
bullet. I'd hazard a guess that BDB configured to use non-default
mutexes would probably pass the Subversion checks and yet still fail
to open an existing environment. If your suggestion that mmap changes
the ABI is true I don't see how Subversion's run-time checks would
detect such a thing.
Since nobody else appears to care about this problem I don't think
it's sensible to change the default. How about a configure option to
allow people to choose to get (or set?) a different SONAME? After all
it is simple to support http-2.0/apr-0.9 and http-2.2/apr-1.2 in
parallel so we should provide a standard way to do it even if it is
not the default.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 11 00:18:29 2006