"Daniel L. Rall" <dlr@finemaltcoding.com> writes:
> Yes, that's right. The idea was to suppor the use case where Subversion is
> dynamically linked against a pre-3.5 version of SQLite (which basically every
> current OS and package management is using), then SQLite is later upgraded.
> Personally, I tend to do updates like this all the time.
I don't think your behaviour is common. I expect people on unusual
platforms, AIX say, build everything in one go, and people on
Linux/Windows install pre-built packages.
Why would someone choose to upgrade a threadsafe SQLite build to a
non-threadsafe one? If it was simple to catch we should do it, but I
won't loose sleep if we simply ignore the problem.
>> 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.
>
> On Linux and Mac OS X, apr_dso_load() wraps dlopen(), which DTRT for an
> installed Subversion. I'm unsure about Windows, and also about uninstalled
> builds used for testing which have dynamic linkage (would rpath come into
> play here an help out?).
>
> I did have some concern about someone building against a SQLite that's not
> in the standard loader path, then getting unexpected behavior at runtime
> if the loader picks up a different version of SQLite.
Libtool, on my Linux box, creates an executable in the build tree
linked to libraries in the build tree, but that executable doesn't
load DSOs from the build tree. At least, that's what it did in the
past, and unless something has changed in APR I assume it still does.
That means that apr_dso_load/dlopen does not DTRT as you claim, even
if it happens to work some of the time.
>> I think you should avoid apr_dso_load, if configure doesn't detect
>> sqlite_threadsafe then it should simply do not call it.
>
> I considered this (and am certainly not against it), but it does fail to
> take advantage of SQLite's thread-safety checks when upgrades occur and
> they become available, a case which will be very common over the next couple
> years. This is somewhat balanced out by the fact that the thread-safe mode
> is the default in the latest SQLite CVS.
>
>> 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.
>
> Interesting suggestion. It seems like something of an unintuitive and undue
> burden on package maintainers.
I was thinking it's a bit like --disable-neon-version-check. I'd
simply document that SQLite should be threadsafe and leave it up to
the user.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 22 17:51:53 2007