homepage

This is essentially the same issue as http://bugs.python.org/issue14572.
The following addition in Python 2.7.4 (compared to 2.7.3) reintroduced the same problem in a different place:
--- Python-2.7.3/Modules/_sqlite/util.h 2012年04月10日 01:07:33.000000000 +0200
+++ Python-2.7.4/Modules/_sqlite//util.h 2013年04月06日 16:02:36.000000000 +0200
@@ -33,6 +33,10 @@ int pysqlite_step(sqlite3_stmt* statemen
 /**
 * Checks the SQLite error code and sets the appropriate DB-API exception.
 * Returns the error code (0 means no error occurred).
 */
 int _pysqlite_seterror(sqlite3* db, sqlite3_stmt* st);
+
+PyObject * _pysqlite_long_from_int64(sqlite3_int64 value);
+sqlite3_int64 _pysqlite_long_as_int64(PyObject * value);
+
 #endif
The fix is the same as for the 2.7.3 issue: replace sqlite3_int64 with sqlite_int64

Adding the same people to the nosy list as on issue #14572.

The regression was introduced in issue17073.

Here is a patch for 2.7. Please test. Should it be fixed on 3.x?

The patch does solve the build problem for 2.7 on 10.4 (Tiger). The same problem exists for 3.3 and default as well. I see the Tiger buildbots aren't failing with this problem; I suspect that's because there is a newer version of libsqlite3 being supplied in /usr/local/{include,lib}, like the OS X installer builds do since the Apple-supplied version of libsqlite3 in 10.4 is the ancient 3.1.3.

On 27.04.2013 22:27, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka added the comment:
> 
> Here is a patch for 2.7. Please test. Should it be fixed on 3.x?
Thanks, Serhiy.
I can confirm that the patch fixes the problem with 2.7.4 on
Mac OS X (and probably other platforms with old sqlite libs as
well).
Python 3.3 is not affected by this. It uses a Python type
for storing the values.

Marc-Andre, can you elaborate on why you think Python 3 is not affected? The changes for Issue17073 also added sqlite3_int64 to 3.2, 3.3, and default and, for me on 10.4, _sqlite3.so currently fails to build in all three. (I don't think 3.2 is worth worrying about but if Georg does spin a brown bag 3.2.5 he could cherry pick it.)

On 28.04.2013 05:20, Ned Deily wrote:
> 
> Ned Deily added the comment:
> 
> Marc-Andre, can you elaborate on why you think Python 3 is not affected? The changes for Issue17073 also added sqlite3_int64 to 3.2, 3.3, and default and, for me on 10.4, _sqlite3.so currently fails to build in all three. (I don't think 3.2 is worth worrying about but if Georg does spin a brown bag 3.2.5 he could cherry pick it.)
Oh, I just did a grep on the Python 3.3.0 code base and couldn't
find any hits. Was the issue you mentioned applied to the 3.3.1 dot
release ?
If so, then those new mentions will have to be fixed as well,
of course.

Patch for issue14572 was applied only to 2.7 and then I backported the bug back from 3.x.

New changeset 44fe1f5b07e3 by Serhiy Storchaka in branch '2.7':
Issue #17857: Prevent build failures with pre-3.5.0 versions of sqlite3,
http://hg.python.org/cpython/rev/44fe1f5b07e3
New changeset b677f656c0bf by Serhiy Storchaka in branch '3.3':
Issue #17857: Prevent build failures with pre-3.5.0 versions of sqlite3,
http://hg.python.org/cpython/rev/b677f656c0bf
New changeset 19015fc0c338 by Serhiy Storchaka in branch 'default':
Issue #17857: Prevent build failures with pre-3.5.0 versions of sqlite3,
http://hg.python.org/cpython/rev/19015fc0c338 

Fix verified on OS X 10.4 for 2.7, 3.3, and default.

This issue, like 14572, is also effecting Python 2.7.4 on CentOS 5. I can confirm the patch fixes this issue on CentOS5.

Thanks, Serhiy.

I think this fix should be included in the next regression release.

Georg, do you want a 3.2 patch for this as well?

Would be nice, yes.

Cherry-picked to 3.2 branch.

New changeset d5b5116bf953 by Serhiy Storchaka in branch '3.2':
Issue #17857: Prevent build failures with pre-3.5.0 versions of sqlite3,
http://hg.python.org/cpython/rev/d5b5116bf953