Re: svn commit: r35241 - in trunk: . build/ac-macros subversion/include/private subversion/libsvn_subr

On Wed, Jan 14, 2009 at 18:21, Justin Erenkrantz <jerenkrantz_at_apache.org> wrote:
>...
> In order to use a static version, we have to rename all symbols to
> avoid conflicts as APR-util can also bring in sqlite. Therefore, we

Nope... note the use of SQLITE_API defined as "static". All of the
sqlite functions are static to libsvn_subr/sqlite.c. No naming
contention at all!

> have now introduced symbol/version collisions that can cause failures
> at run-time and indeterminate behavior.
>
> FWIW, I was already working on a patch to do the external config when
> ./sqlite exists - as no one added ./sqlite bundled-support to
> configure. IMO, that's a far more elegant solution... -- justin

This was a first step to get svn working in the presence of an old
system sqlite. Obviously, it didn't work all that well for some
definition of "everybody".

I'd prefer to see an amalgamation build over a ./sqlite build. Tho I
guess with the latter, it can be independently rev'd independent of
what amalgamation we include into our build.

I'm curious about the ENOTSUP error though. I thought sqlite was very portable.

Anyways... looks like a blend of restoring-autoconf and the amalg
build should do the trick. Just needs some volunteers...

Cheers,
-g
Received on 2009-01-14 18:42:50 CET