Daniel Rall <dlr@collab.net> writes:
> +/* If possible, verify that SQLite was compiled in a thread-safe
> + manner. The library will be unloaded when POOL is destroyed. */
> +static svn_error_t *
> +init_sqlite(apr_pool_t *pool)
> +{
> + svn_boolean_t is_threadsafe = TRUE;
> +
> + /* SQLite 3.5 allows verification of its thread-safety at runtime.
> + Older versions are simply expected to have been configured with
> + --enable-threadsafe, which compiles with -DSQLITE_THREADSAFE=1
> + (or -DTHREADSAFE, for older versions). */
> +#ifdef SVN_HAVE_SQLITE_THREADSAFE_PREDICATE
> + /* sqlite3_threadsafe() was available at Subversion 'configure'-time. */
> + is_threadsafe = sqlite3_threadsafe();
> +
> +#elsif APR_HAS_DSO
> + /* Attempt to dynamically load sqlite3_threadsafe(), since the
> + version of SQLite present at compile-time may've changed. */
> + apr_status_t status;
> + apr_dso_handle_t *dso = NULL;
> + apr_dso_handle_sym_t symbol;
> +
> +#if DARWIN
> + status = apr_dso_load(&dso, "libsqlite3.dylib", pool);
> +#endif
> + if (dso == NULL)
> + status = apr_dso_load(&dso, "libsqlite3.so", pool);
If I understand this correctly you are attempting to dlopen a shared
library that is already dynamically linked to the executable. My
first reaction is yuck! That will only work if apr_dso_load uses the
same search path as the linker, and I seem to recall that people have
problems running the tests when RA/FS are loaded using apr_dso_load as
the search path doesn't do what we want, it doesn't include the build
tree for example.
I think you should avoid apr_dso_load, if configure doesn't detect
sqlite_threadsafe then it should simply do not call it. If you think
that is not good enough then perhaps we could require an additional
configure option, --enable-assume-sqlite-is-threadsafe say, and only
allow people to use an sqlite without sqlite_threadsafe if they enable
the extra option.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 22 00:51:45 2007