You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2008/10/07 17:39:56 UTC
Re: svn commit: r33520 - requiring SQLite
On Tue, 2008-10-07 at 10:03 -0700, hwright@tigris.org wrote:
> Author: hwright
> Date: Tue Oct 7 10:03:29 2008
> New Revision: 33520
>
> Log:
> Break everybody's build by requiring SQLite.
Harrumph. I have SQLite installed. What else do I need?
From config.log:
[[[
configure:6070: checking sqlite library
configure:6352: checking for pkg-config
configure:6370: found /usr/bin/pkg-config
configure:6382: result: /usr/bin/pkg-config
configure:6390: checking sqlite library version (via pkg-config)
configure:6401: result: none or unsupported 3.2
configure:6427: checking sqlite3.h usability
configure:6439: gcc -c -g -O -Wall -Wundef -Wendif-labels -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wredundant-decls
-Wdeclaration-after-statement -Wnested-externs -Wno-system-headers
-Wunused -Wno-deprecated-declarations -pthread -D_LARGEFILE64_SOURCE
-DNE_LFS -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE
-I/usr/include -I/usr/include/apr-1 conftest.c >&5
configure:6445: $? = 0
configure:6449: test -z
|| test ! -s conftest.err
configure:6452: $? = 0
configure:6455: test -s conftest.o
configure:6458: $? = 0
configure:6468: result: yes
configure:6472: checking sqlite3.h presence
configure:6482: gcc -E -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE
-D_LARGEFILE64_SOURCE -I/usr/include -I/usr/include/apr-1 conftest.c
configure:6488: $? = 0
configure:6508: result: yes
configure:6543: checking for sqlite3.h
configure:6550: result: yes
configure:6556: checking sqlite library version (via header)
configure:6651: result: none or unsupported
configure:6668: WARNING: no suitable sqlite found
configure:6683: error: Subversion requires SQLite
]]]
[[[
$ rpm -ql sqlite
/usr/bin/sqlite3
/usr/lib/libsqlite3.so.0
/usr/lib/libsqlite3.so.0.8.6
/usr/share/man/man1/sqlite3.1.gz
$ rpm -ql sqlite2
/usr/bin/sqlite
/usr/lib/libsqlite.so.0
/usr/lib/libsqlite.so.0.8.6
/usr/share/man/man1/sqlite.1.gz
$ rpm -ql sqlite
/usr/bin/sqlite3
/usr/lib/libsqlite3.so.0
/usr/lib/libsqlite3.so.0.8.6
/usr/share/man/man1/sqlite3.1.gz
$ rpm -ql sqlite-devel
/usr/include/sqlite3.h
/usr/lib/libsqlite3.a
/usr/lib/libsqlite3.la
/usr/lib/libsqlite3.so
/usr/lib/pkgconfig/sqlite3.pc
/usr/share/[...]
]]]
This is on SuSE SLED 10 SP2.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r33520 - requiring SQLite
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Justin Erenkrantz wrote:
> BTW, OS X 10.5 seems to have 3.4.0 by default - what's the rationale
> behind enforcing 3.5.x+? Would it be a lot of work to support 3.4.x
> too, or is there some big nasty bug? -- justin
IIRC, we do use features from SQLite 3.5.x in our code, but I don't remember if
they are vital or where we use them.
-Hyrum
Re: svn commit: r33520 - requiring SQLite
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Oct 7, 2008 at 2:31 PM, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On Tue, Oct 7, 2008 at 2:20 PM, Greg Stein <gs...@gmail.com> wrote:
>> There is some #if'd code in init_sqlite() that is incomplete. Are
>> those two functions in 3.4?
>
> Nope. We should be able to protect them with another
> SQLITE_VERSION_AT_LEAST(3,5,0) check. Hmm, sqlite3_threadsafe() isn't
> defined in 3.4.x, but gcc isn't emitting a warning - but, it too
> should probably be behind a 3.5.0+ check.
There used to be a guarded check for that, but I tossed it when I
assumed 3.5.x minimum.
> We can also do run-time version checking with
> sqlite3_libversion_number() to ensure we don't downgrade from what we
> compile against.
Right. My WC has a comment in sqlite.c to do just that. Specifically,
I'm worried about apr-util loading an old sqlite into the process
space, regardless of what we compile/link against. Thus, the runtime
check is mandatory.
> I don't know what guarantees SQLite3 has with
> respect to ABI compatibility though (if any)... -- justin
Functions can come and go, but I think the functions' signature and
semantics are rigid.
Hmm. On the config stuff... I think here are corresponding pragmas
(just less easy to use).
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r33520 - requiring SQLite
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Oct 7, 2008 at 2:20 PM, Greg Stein <gs...@gmail.com> wrote:
> There is some #if'd code in init_sqlite() that is incomplete. Are
> those two functions in 3.4?
Nope. We should be able to protect them with another
SQLITE_VERSION_AT_LEAST(3,5,0) check. Hmm, sqlite3_threadsafe() isn't
defined in 3.4.x, but gcc isn't emitting a warning - but, it too
should probably be behind a 3.5.0+ check.
We can also do run-time version checking with
sqlite3_libversion_number() to ensure we don't downgrade from what we
compile against. I don't know what guarantees SQLite3 has with
respect to ABI compatibility though (if any)... -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r33520 - requiring SQLite
Posted by Greg Stein <gs...@gmail.com>.
There is some #if'd code in init_sqlite() that is incomplete. Are
those two functions in 3.4?
On Tue, Oct 7, 2008 at 2:09 PM, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On Tue, Oct 7, 2008 at 1:19 PM, Greg Stein <gs...@gmail.com> wrote:
>> So. For the moment, we require 3.5.x (and allow 3.6.x). If somebody
>> wants to do the legwork for 3.4.x, then by all means...
>
> Patch below compiles against SQLite 3.4.0 as shipped with Mac OS X
> 10.5. Do you see any reason not to commit?
>
> This should institute the checking when we do read-only/read-write
> that the database already exists. And, since older versions of
> sqlite3 don't support read-only ops, it will be implicitly read-write;
> but not a whole lot we can do there, IMO.
>
> I haven't checked to see whether 3.3 or 3.2 would be coming along for
> free - perhaps, but this should be okay with 3.4.x. -- justin
>
> ---
>
> SQLite: compile against version 3.4.x (aka what Mac OS X 10.5 includes).
>
> * subversion/libsvn_subr/sqlite.c
> (private/svn_dep_compat.h): Include.
> (svn_sqlite__open): Use sqlite3_open on older sqlite instances.
> * subversion/include/private/svn_dep_compat.h
> (SQLITE_VERSION_AT_LEAST): Implement helper macro.
> * configure.ac
> (SQLITE_ALLOWED_PATTERN): Add 3.4.x to mix.
>
> Index: subversion/libsvn_subr/sqlite.c
> ===================================================================
> --- subversion/libsvn_subr/sqlite.c (revision 33523)
> +++ subversion/libsvn_subr/sqlite.c (working copy)
> @@ -25,6 +25,7 @@
>
> #include "private/svn_sqlite.h"
> #include "svn_private_config.h"
> +#include "private/svn_dep_compat.h"
>
>
> #ifdef SQLITE3_DEBUG
> @@ -364,6 +365,7 @@
> /* ### use a pool cleanup to close this? (instead of __close()) */
> *db = apr_palloc(result_pool, sizeof(**db));
>
> +#if SQLITE_VERSION_AT_LEAST(3,5,0)
> if (mode == svn_sqlite__mode_readonly)
> flags = SQLITE_OPEN_READONLY;
> else if (mode == svn_sqlite__mode_readwrite)
> @@ -387,7 +389,34 @@
> occurs (except for out-of-memory); thus, we can safely use it to
> extract an error message and construct an svn_error_t. */
> SQLITE_ERR(sqlite3_open_v2(path, &(*db)->db3, flags, NULL), *db);
> +#else
> + /* Older versions of SQLite (pre-3.5.x) will always create the database
> + if it doesn't exist. So, if we are asked to be read-only or read-write,
> + we ensure the database already exists - if it doesn't, then we will
> + explicitly error out before asking SQLite to do anything.
>
> + Pre-3.5.x SQLite versions also don't support read-only ops either.
> + */
> + if (mode == svn_sqlite__mode_readonly || mode == svn_sqlite__mode_readwrite)
> + {
> + svn_node_kind_t *kind;
> + SVN_ERR(svn_io_check_path(path, &kind, scratch_pool));
> + if (kind != svn_node_file) {
> + return svn_error_createf(SVN_ERR_WC_CORRUPT, NULL,
> + _("Expected SQLite database not found: %s"),
> + svn_path_local_style(path, scratch_pool));
> + }
> + }
> + else if (mode == svn_sqlite__mode_rwcreate)
> + {
> + /* do nothing - older SQLite's will create automatically. */
> + }
> + else
> + SVN_ERR_MALFUNCTION();
> +
> + SQLITE_ERR(sqlite3_open(path, &(*db)->db3), *db);
> +#endif
> +
> /* Retry until timeout when database is busy. */
> SQLITE_ERR(sqlite3_busy_timeout((*db)->db3, BUSY_TIMEOUT), *db);
> #ifdef SQLITE3_DEBUG
> Index: subversion/include/private/svn_dep_compat.h
> ===================================================================
> --- subversion/include/private/svn_dep_compat.h (revision 33523)
> +++ subversion/include/private/svn_dep_compat.h (working copy)
> @@ -69,6 +69,23 @@ extern "C" {
> (patch) <= SERF_PATCH_VERSION))
> #endif /* SERF_VERSION_AT_LEAST */
>
> +/**
> + * Check at compile time if the SQLite version is at least a certain
> + * level.
> + * @param major The major version component of the version checked
> + * for (e.g., the "1" of "1.3.0").
> + * @param minor The minor version component of the version checked
> + * for (e.g., the "3" of "1.3.0").
> + * @param patch The patch level component of the version checked
> + * for (e.g., the "0" of "1.3.0").
> + *
> + * @since New in 1.6.
> + */
> +#ifndef SQLITE_VERSION_AT_LEAST
> +#define SQLITE_VERSION_AT_LEAST(major,minor,patch) \
> +((major*1000000 + minor*1000 + patch) <= SQLITE_VERSION_NUMBER)
> +#endif /* SQLITE_VERSION_AT_LEAST */
> +
> #ifdef __cplusplus
> }
> #endif /* __cplusplus */
> Index: configure.ac
> ===================================================================
> --- configure.ac (revision 33523)
> +++ configure.ac (working copy)
> @@ -111,7 +111,7 @@ dnl Find Apache with a recent-enough magic module
> SVN_FIND_APACHE(20020903)
>
> dnl Search for SQLite
> -SQLITE_ALLOWED_PATTERN="(3\.5|3\.6)($|\..*)"
> +SQLITE_ALLOWED_PATTERN="(3\.4|3\.5|3\.6)($|\..*)"
> SQLITE_RECOMMENDED_VER="3.5.9"
> SQLITE_URL="http://www.sqlite.org/sqlite-${SQLITE_RECOMMENDED_VER}.tar.gz"
> SVN_LIB_SQLITE(${SQLITE_ALLOWED_PATTERN}, ${SQLITE_RECOMMENDED_VER},
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r33520 - requiring SQLite
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Oct 7, 2008 at 1:19 PM, Greg Stein <gs...@gmail.com> wrote:
> So. For the moment, we require 3.5.x (and allow 3.6.x). If somebody
> wants to do the legwork for 3.4.x, then by all means...
Patch below compiles against SQLite 3.4.0 as shipped with Mac OS X
10.5. Do you see any reason not to commit?
This should institute the checking when we do read-only/read-write
that the database already exists. And, since older versions of
sqlite3 don't support read-only ops, it will be implicitly read-write;
but not a whole lot we can do there, IMO.
I haven't checked to see whether 3.3 or 3.2 would be coming along for
free - perhaps, but this should be okay with 3.4.x. -- justin
---
SQLite: compile against version 3.4.x (aka what Mac OS X 10.5 includes).
* subversion/libsvn_subr/sqlite.c
(private/svn_dep_compat.h): Include.
(svn_sqlite__open): Use sqlite3_open on older sqlite instances.
* subversion/include/private/svn_dep_compat.h
(SQLITE_VERSION_AT_LEAST): Implement helper macro.
* configure.ac
(SQLITE_ALLOWED_PATTERN): Add 3.4.x to mix.
Index: subversion/libsvn_subr/sqlite.c
===================================================================
--- subversion/libsvn_subr/sqlite.c (revision 33523)
+++ subversion/libsvn_subr/sqlite.c (working copy)
@@ -25,6 +25,7 @@
#include "private/svn_sqlite.h"
#include "svn_private_config.h"
+#include "private/svn_dep_compat.h"
#ifdef SQLITE3_DEBUG
@@ -364,6 +365,7 @@
/* ### use a pool cleanup to close this? (instead of __close()) */
*db = apr_palloc(result_pool, sizeof(**db));
+#if SQLITE_VERSION_AT_LEAST(3,5,0)
if (mode == svn_sqlite__mode_readonly)
flags = SQLITE_OPEN_READONLY;
else if (mode == svn_sqlite__mode_readwrite)
@@ -387,7 +389,34 @@
occurs (except for out-of-memory); thus, we can safely use it to
extract an error message and construct an svn_error_t. */
SQLITE_ERR(sqlite3_open_v2(path, &(*db)->db3, flags, NULL), *db);
+#else
+ /* Older versions of SQLite (pre-3.5.x) will always create the database
+ if it doesn't exist. So, if we are asked to be read-only or read-write,
+ we ensure the database already exists - if it doesn't, then we will
+ explicitly error out before asking SQLite to do anything.
+ Pre-3.5.x SQLite versions also don't support read-only ops either.
+ */
+ if (mode == svn_sqlite__mode_readonly || mode == svn_sqlite__mode_readwrite)
+ {
+ svn_node_kind_t *kind;
+ SVN_ERR(svn_io_check_path(path, &kind, scratch_pool));
+ if (kind != svn_node_file) {
+ return svn_error_createf(SVN_ERR_WC_CORRUPT, NULL,
+ _("Expected SQLite database not found: %s"),
+ svn_path_local_style(path, scratch_pool));
+ }
+ }
+ else if (mode == svn_sqlite__mode_rwcreate)
+ {
+ /* do nothing - older SQLite's will create automatically. */
+ }
+ else
+ SVN_ERR_MALFUNCTION();
+
+ SQLITE_ERR(sqlite3_open(path, &(*db)->db3), *db);
+#endif
+
/* Retry until timeout when database is busy. */
SQLITE_ERR(sqlite3_busy_timeout((*db)->db3, BUSY_TIMEOUT), *db);
#ifdef SQLITE3_DEBUG
Index: subversion/include/private/svn_dep_compat.h
===================================================================
--- subversion/include/private/svn_dep_compat.h (revision 33523)
+++ subversion/include/private/svn_dep_compat.h (working copy)
@@ -69,6 +69,23 @@ extern "C" {
(patch) <= SERF_PATCH_VERSION))
#endif /* SERF_VERSION_AT_LEAST */
+/**
+ * Check at compile time if the SQLite version is at least a certain
+ * level.
+ * @param major The major version component of the version checked
+ * for (e.g., the "1" of "1.3.0").
+ * @param minor The minor version component of the version checked
+ * for (e.g., the "3" of "1.3.0").
+ * @param patch The patch level component of the version checked
+ * for (e.g., the "0" of "1.3.0").
+ *
+ * @since New in 1.6.
+ */
+#ifndef SQLITE_VERSION_AT_LEAST
+#define SQLITE_VERSION_AT_LEAST(major,minor,patch) \
+((major*1000000 + minor*1000 + patch) <= SQLITE_VERSION_NUMBER)
+#endif /* SQLITE_VERSION_AT_LEAST */
+
#ifdef __cplusplus
}
#endif /* __cplusplus */
Index: configure.ac
===================================================================
--- configure.ac (revision 33523)
+++ configure.ac (working copy)
@@ -111,7 +111,7 @@ dnl Find Apache with a recent-enough magic module
SVN_FIND_APACHE(20020903)
dnl Search for SQLite
-SQLITE_ALLOWED_PATTERN="(3\.5|3\.6)($|\..*)"
+SQLITE_ALLOWED_PATTERN="(3\.4|3\.5|3\.6)($|\..*)"
SQLITE_RECOMMENDED_VER="3.5.9"
SQLITE_URL="http://www.sqlite.org/sqlite-${SQLITE_RECOMMENDED_VER}.tar.gz"
SVN_LIB_SQLITE(${SQLITE_ALLOWED_PATTERN}, ${SQLITE_RECOMMENDED_VER},
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r33520 - requiring SQLite
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Oct 7, 2008 at 11:17 AM, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
>...
> BTW, OS X 10.5 seems to have 3.4.0 by default - what's the rationale
> behind enforcing 3.5.x+? Would it be a lot of work to support 3.4.x
> too, or is there some big nasty bug? -- justin
SQLite 3.5.x adds the open_v2 interface, which allows SQLite to fail
if the database doesn't exist, rather than create it on the spot. We
only want SQLite to create the database when we *tell* it to do that.
As I recall, there are also a couple other interfaces related to
dynamic configuration and thread support detection that 3.5.x
contains.
So. For the moment, we require 3.5.x (and allow 3.6.x). If somebody
wants to do the legwork for 3.4.x, then by all means...
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r33520 - requiring SQLite
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Oct 7, 2008 at 11:12 AM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
>> That would do it, but from the rpm listing it looks like you really
>> have 3.6.8: /usr/lib/libsqlite3.so.0.8.6. (if I read that version
>> correctly)
>
> Uh, if he's got SQLite 3.6.8, I want to know how I too can get a time machine.
> (3.6.3 is the latest version.)
Heh. Didn't check that.
It's possible that SQLite doesn't encode the version in their DSOs.
APR does. In fact, the way APR encodes it, the above would be 3.8.6.
*grin*
BTW, OS X 10.5 seems to have 3.4.0 by default - what's the rationale
behind enforcing 3.5.x+? Would it be a lot of work to support 3.4.x
too, or is there some big nasty bug? -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r33520 - requiring SQLite
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Justin Erenkrantz wrote:
> On Tue, Oct 7, 2008 at 10:57 AM, Julian Foad <ju...@btopenworld.com> wrote:
>> On Tue, 2008-10-07 at 10:46 -0700, Justin Erenkrantz wrote:
>>> On Tue, Oct 7, 2008 at 10:39 AM, Julian Foad <ju...@btopenworld.com> wrote:
>>>> Harrumph. I have SQLite installed. What else do I need?
>>> Looks like the version detection has gone haywire - what does the
>>> following snippet produce for you:
>>>
>>> sqlite_version=`$pkg_config $SQLITE_PKGNAME --modversion --silence-errors`
>>>
>>> if $ECHO $sqlite_version | $EGREP -q $SQLITE_ALLOWED_PATTERN; then
>>>
>>> (That's around line 48 in build/ac-macros/sqlite.m4)
>> $ pkg-config sqlite3 --modversion --silence-errors
>> 3.2
>
> That would do it, but from the rpm listing it looks like you really
> have 3.6.8: /usr/lib/libsqlite3.so.0.8.6. (if I read that version
> correctly)
Uh, if he's got SQLite 3.6.8, I want to know how I too can get a time machine.
(3.6.3 is the latest version.)
-Hyrum
Re: svn commit: r33520 - requiring SQLite
Posted by Peter Samuelson <pe...@p12n.org>.
[Justin Erenkrantz]
> > $ pkg-config sqlite3 --modversion --silence-errors
> > 3.2
>
> That would do it, but from the rpm listing it looks like you really
> have 3.6.8: /usr/lib/libsqlite3.so.0.8.6. (if I read that version
> correctly)
The last 2 fields often don't mean much, except that libtool requires
them, so you plug some numbers in and you may never bother to update
them, since they have little real purpose on modern OSes. The ".8.6"
seems to have remained constant at least between 3.2.1 and 3.5.9.
SQLite is in good company: libsvn_foo has kept an equally useful
suffix of ".0.0" since the beginning of time.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Re: svn commit: r33520 - requiring SQLite
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Oct 7, 2008 at 11:43 AM, Julian Foad <ju...@btopenworld.com> wrote:
> I don't know how you got that from the library file name. It's packaged
> as v3.2.8.
>
> [[[
> $ rpm -qa | grep sqlite
> sqlite-3.2.8-15.2
> sqlite-devel-3.2.8-15.2
> mono-data-sqlite-1.2.2-12.20
> sqlite2-2.8.17-14.2
> ]]]
>
> Sorry, I meant to include that in the previous transcript, but pasted
> the wrong bit. That would have made things a lot clearer.
If it helps, since you didn't specify the version (like above), the
reason I inferred it was from the file name of the .so:
/usr/lib/libsqlite3.so.0.8.6
If you use GNU libtool's versioning parameters, that should refer to
3.8.6. For APR 1.2.11, the installed .so is:
/usr/lib/libapr-1.so.0.2.11
But, it looks like SuSE (or SQLite) does something different with
their suffixes. *shrug* -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r33520 - requiring SQLite
Posted by Julian Foad <ju...@btopenworld.com>.
On Tue, 2008-10-07 at 11:01 -0700, Justin Erenkrantz wrote:
> On Tue, Oct 7, 2008 at 10:57 AM, Julian Foad <ju...@btopenworld.com> wrote:
> > On Tue, 2008-10-07 at 10:46 -0700, Justin Erenkrantz wrote:
> >> On Tue, Oct 7, 2008 at 10:39 AM, Julian Foad <ju...@btopenworld.com> wrote:
> >> > Harrumph. I have SQLite installed. What else do I need?
> >>
> >> Looks like the version detection has gone haywire - what does the
> >> following snippet produce for you:
> >>
> >> sqlite_version=`$pkg_config $SQLITE_PKGNAME --modversion --silence-errors`
> >>
> >> if $ECHO $sqlite_version | $EGREP -q $SQLITE_ALLOWED_PATTERN; then
> >>
> >> (That's around line 48 in build/ac-macros/sqlite.m4)
> >
> > $ pkg-config sqlite3 --modversion --silence-errors
> > 3.2
>
> That would do it, but from the rpm listing it looks like you really
> have 3.6.8: /usr/lib/libsqlite3.so.0.8.6. (if I read that version
> correctly)
I don't know how you got that from the library file name. It's packaged
as v3.2.8.
[[[
$ rpm -qa | grep sqlite
sqlite-3.2.8-15.2
sqlite-devel-3.2.8-15.2
mono-data-sqlite-1.2.2-12.20
sqlite2-2.8.17-14.2
]]]
Sorry, I meant to include that in the previous transcript, but pasted
the wrong bit. That would have made things a lot clearer.
> Could this be a SuSE packaging issue? What's the version reported in
> your sqlite3.h? -- justin
I don't see any "issue" with the packaging. I've already uninstalled it
to make way for upgrading. The configure script detected it as "3.2",
which agrees with the package name.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r33520 - requiring SQLite
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Oct 7, 2008 at 10:57 AM, Julian Foad <ju...@btopenworld.com> wrote:
> On Tue, 2008-10-07 at 10:46 -0700, Justin Erenkrantz wrote:
>> On Tue, Oct 7, 2008 at 10:39 AM, Julian Foad <ju...@btopenworld.com> wrote:
>> > Harrumph. I have SQLite installed. What else do I need?
>>
>> Looks like the version detection has gone haywire - what does the
>> following snippet produce for you:
>>
>> sqlite_version=`$pkg_config $SQLITE_PKGNAME --modversion --silence-errors`
>>
>> if $ECHO $sqlite_version | $EGREP -q $SQLITE_ALLOWED_PATTERN; then
>>
>> (That's around line 48 in build/ac-macros/sqlite.m4)
>
> $ pkg-config sqlite3 --modversion --silence-errors
> 3.2
That would do it, but from the rpm listing it looks like you really
have 3.6.8: /usr/lib/libsqlite3.so.0.8.6. (if I read that version
correctly)
Could this be a SuSE packaging issue? What's the version reported in
your sqlite3.h? -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r33520 - requiring SQLite
Posted by Julian Foad <ju...@btopenworld.com>.
On Tue, 2008-10-07 at 10:46 -0700, Justin Erenkrantz wrote:
> On Tue, Oct 7, 2008 at 10:39 AM, Julian Foad <ju...@btopenworld.com> wrote:
> > Harrumph. I have SQLite installed. What else do I need?
>
> Looks like the version detection has gone haywire - what does the
> following snippet produce for you:
>
> sqlite_version=`$pkg_config $SQLITE_PKGNAME --modversion --silence-errors`
>
> if $ECHO $sqlite_version | $EGREP -q $SQLITE_ALLOWED_PATTERN; then
>
> (That's around line 48 in build/ac-macros/sqlite.m4)
$ pkg-config sqlite3 --modversion --silence-errors
3.2
Mark Phippard told me that it currently requires v3.5.x
configure.ac contains:
SQLITE_ALLOWED_PATTERN="(3\.5|3\.6)($|\..*)"
SQLITE_RECOMMENDED_VER="3.5.9"
SQLITE_URL="http://www.sqlite.org/sqlite-${SQLITE_RECOMMENDED_VER}.tar.gz"
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r33520 - requiring SQLite
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Oct 7, 2008 at 10:39 AM, Julian Foad <ju...@btopenworld.com> wrote:
> Harrumph. I have SQLite installed. What else do I need?
Looks like the version detection has gone haywire - what does the
following snippet produce for you:
sqlite_version=`$pkg_config $SQLITE_PKGNAME --modversion --silence-errors`
if $ECHO $sqlite_version | $EGREP -q $SQLITE_ALLOWED_PATTERN; then
(That's around line 48 in build/ac-macros/sqlite.m4)
HTH. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org