This is the mail archive of the
mailing list for the Cygwin project.
Re: sqlite3: bug with monotone
- From: Achim Gratz <Stromeko at NexGo dot DE>
- To: cygwin at cygwin dot com
- Date: Fri, 31 May 2013 08:51:23 +0000 (UTC)
- Subject: Re: sqlite3: bug with monotone
- References: <51A6B6EB dot 6050309 at users dot sourceforge dot net> <loom dot 20130530T122354-144 at post dot gmane dot org> <51A7862F dot 1070507 at etr-usa dot com> <51A7D47E dot 3050502 at users dot sourceforge dot net>
Yaakov (Cygwin/X <yselkowitz <at> users.sourceforge.net> writes:
> Yes, I can now confirm that (the lack of) SQLITE_OS_UNIX is the culprit.
> If it's a choice between Cygwin programs functioning correctly (in this
> case, mtn clone), and allowing interoperability with Windows programs,
> there is NO QUESTION that the former MUST take priority. Add a `mount
> -o mand' feature if you wish (or get someone who cares about this to do
> so), but DON'T BREAK Cygwin programs for the sake of those NOT USING Cygwin.
We've had this discussion before, please re-read the arguments made there if
you haven't done so already.
I've been running my own sqlite3 package for a while that treats Cygwin as
UNIX, but I don't use TortoiseSVN and other programs that would lead to
concurrent access from the Windows side (or from the Cygwin side, really).
I do use (not often) temporary tables that are large and should not be held
in memory, so the even if that option was used to fix the temp table issue I
would still rather use my own package.
> Please fix sqlite3 accordingly.
I've looked into this situation a few times (and Warren has been doing that
more than just once, too). Things aren't as clear cut as you seem to
believe. For starters, upstream doesn't seem to give much thought about
Cygwin at all. I've tried to find where to fix things and the situation is
that the test suite doesn't run at all when sqlite3 is compiled like
upstream wants (i.e. SQLITE_OS_WIN) and fails quite a few of its own
concurrency tests when compiled with SQLITE_OS_UNIX. A few of these test
fails are simply of the sort that you are seeing with monotone (DB access
fails), but some of them look like database corruptions. A "fixed" sqlite3
should not fail its own test suite I suppose.
I haven't had time yet to build sqlite3 and run the tests on a UNIX box to
get a baseline from which to work. But whichever way you compile sqlite3 on
Cygwin, you can either not test it at all or you produce test failures, so
you can only chose which way to break it. I agree that it would be a good
thing to fix this, but it takes a bit more work than just using a different
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple