This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: sqlite3: bug with monotone

Yaakov (Cygwin/X <yselkowitz <at>> 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:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]