Greg Stein wrote:
> 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...
Here's what I'd like to see:
* keep amalgamation ability, but ship the actual amalgamation file in -deps and
install it in the correct place during configure
* resurrect the link-to-system-library ability, have an officially recommended
minimum version (preferably something like 3.5.0 for the time being)
I can take a look over the next couple of days, but it may be slow going as I
reteach myself m4. Justin, if you think it'd be helpful, would you might
posting your patch-in-progress?
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1024898
Received on 2009-01-14 22:14:32 CET