Note that at least some of dependency bugs are not fixed in 3.3.5.

Thanks, I'll check them when I do the new version.

The changes in this patch allow sqlite to build in THREADSAFE mode under BeOS. Mozilla Makefile.in must be modified to build os_beos.c.

Comment on attachment 222641 [details] [diff] [review] Sqlite 3.3.5 This fixes a whole bunch of coverity warnings and other issues, and now that we have nothing but mozStorage using sqlite on the branch it's a safe fix. Branch tree is closed at the moment though -- coordinate with #bonecho for a landing slot.

Note that form history also uses sqlite via storage.

This patch allows threadsafe=1 building with BeOS. It was created by first applying sqlite 3.3.5 patch from brettw, then making BeOS changes and diffing between the original patch and patch+BeOS additions. Not sure whether you'd like a patch in this form or a complete 3.3.4 to 3.3.5 diff with BeOS changes so took the lesser of the two.

Fixed on trunk. Leaving open for branch checkin.

For the record, I think you upgraded not to 3.3.5 but to trunk or something, because this diff includes a check-in from 2006/04/16, which was after 3.3.5 was released: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/db/sqlite3/src&command=DIFF_FRAMESET&file=utf.c&rev1=1.3&rev2=1.4&root=/cvsroot

Is there a reason not to do this? I suppose the releases might be stabler, but in the past we've usually wanted at least one fix that wasn't in a real release yet.

Fixed on 1.8 branch.

(In reply to comment #10) > Is there a reason not to do this? I suppose the releases might be stabler, but > in the past we've usually wanted at least one fix that wasn't in a real release > yet. > For what it's worth, we are using the 3.3.5 patch in the last round of BeOS test builds (with additions in the BeOS patch above) with good luck. Brett, did you check in only the 3.3.5 patch, or BeOS patch also?

(In reply to comment #12) > (In reply to comment #10) > > Is there a reason not to do this? I suppose the releases might be stabler, but > > in the past we've usually wanted at least one fix that wasn't in a real release > > yet. > > > For what it's worth, we are using the 3.3.5 patch in the last round of BeOS > test builds (with additions in the BeOS patch above) with good luck. Brett, > did you check in only the 3.3.5 patch, or BeOS patch also? No, it's not a very high priority right now, maybe I can do it when a3 is done. I looked at your patch very briefly. Many of the comments still mention unix, which is confusing, eg: +#if OS_BEOS /* This file is used on unix only */ Also, the patch isn't correct and references absolute patches on your box. Please use cvs diff to get the correct format. I suggest you post future patches in bug 330340 since this bug is fixed.

(comment 10) > Is there a reason not to do this? I suppose the releases might be stabler, but > in the past we've usually wanted at least one fix that wasn't in a real release > yet. Yeah, it's just that it's confusing for someone who might be doing code archeology later, which is why I added the comment.

(In reply to comment #13) > > I suggest you post future patches in bug 330340 since this bug is fixed. > Now that 3.3.5 is in CVS, using CVS Diff will be easy. I will clean up unix-oriented comments and post new patch at but 330340, as requested.