pyodbc: assume SQL_C_WCHAR is native endian

Bump PKG_REV and remove obsolete PKG_MD5SUM while at it.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>

diff --git a/lang/python/pyodbc/Makefile b/lang/python/pyodbc/Makefile
index 198dac71f84a1f495b0d158a01abfd855feefecf..e0c6d4058b64310aa650c518c8864eec3a8449d2 100644 (file)
--- a/lang/python/pyodbc/Makefile
+++ b/lang/python/pyodbc/Makefile
@@ -6,11 +6,10 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=pyodbc
 PKG_VERSION:=4.0.17
-PKG_RELEASE:=2
+PKG_RELEASE:=3
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_URL:=https://pypi.python.org/packages/ce/57/6b92aa5b3497dde6be55fd6fcb76c7db215ed1d56fde45c613add4a43095/
-PKG_MD5SUM:=1560f9c915780237c525b765537d220f
 PKG_HASH:=a82892ba8d74318524efaaccaf8351d3a3b4079a07e1a758902a2b9e84529c9d
 PKG_BUILD_DEPENDS:=python python3 unixodbc
 PKG_LICENSE:=MIT

diff --git a/lang/python/pyodbc/patches/100-connection-assume-SQL_C_WCHAR-is-native-endian.patch b/lang/python/pyodbc/patches/100-connection-assume-SQL_C_WCHAR-is-native-endian.patch
new file mode 100644 (file)
index 0000000..e03cd94
--- /dev/null
+++ b/lang/python/pyodbc/patches/100-connection-assume-SQL_C_WCHAR-is-native-endian.patch
@@ -0,0 +1,44 @@
+--- a/src/connection.cpp
++++ b/src/connection.cpp
+@@ -90,7 +90,7 @@ static bool Connect(PyObject* pConnectSt
+         // indication that we can handle Unicode.  We are going to use the same unicode ending
+         // as we do for binding parameters.
+ 
+-        SQLWChar wchar(pConnectString, SQL_C_WCHAR, encoding, "utf-16le");
++        SQLWChar wchar(pConnectString, SQL_C_WCHAR, encoding, "utf-16");
+         if (!wchar)
+             return false;
+ 
+@@ -216,24 +216,24 @@ PyObject* Connection_New(PyObject* pConn
+     // single-byte text we don't actually know what the encoding is.  For example, with SQL
+     // Server the encoding is based on the database's collation.  We ask the driver / DB to
+     // convert to SQL_C_WCHAR and use the ODBC default of UTF-16LE.
+-    cnxn->sqlchar_enc.optenc = OPTENC_UTF16LE;
+-    cnxn->sqlchar_enc.name   = _strdup("utf-16le");
++    cnxn->sqlchar_enc.optenc = OPTENC_UTF16;
++    cnxn->sqlchar_enc.name   = _strdup("utf-16");
+     cnxn->sqlchar_enc.ctype  = SQL_C_WCHAR;
+ 
+-    cnxn->sqlwchar_enc.optenc = OPTENC_UTF16LE;
+-    cnxn->sqlwchar_enc.name   = _strdup("utf-16le");
++    cnxn->sqlwchar_enc.optenc = OPTENC_UTF16;
++    cnxn->sqlwchar_enc.name   = _strdup("utf-16");
+     cnxn->sqlwchar_enc.ctype  = SQL_C_WCHAR;
+ 
+-    cnxn->metadata_enc.optenc = OPTENC_UTF16LE;
+-    cnxn->metadata_enc.name   = _strdup("utf-16le");
++    cnxn->metadata_enc.optenc = OPTENC_UTF16;
++    cnxn->metadata_enc.name   = _strdup("utf-16");
+     cnxn->metadata_enc.ctype  = SQL_C_WCHAR;
+ 
+     // Note: I attempted to use UTF-8 here too since it can hold any type, but SQL Server fails
+     // with a data truncation error if we send something encoded in 2 bytes to a column with 1
+     // character.  I don't know if this is a bug in SQL Server's driver or if I'm missing
+     // something, so we'll stay with the default ODBC conversions.
+-    cnxn->unicode_enc.optenc = OPTENC_UTF16LE;
+-    cnxn->unicode_enc.name   = _strdup("utf-16le");
++    cnxn->unicode_enc.optenc = OPTENC_UTF16;
++    cnxn->unicode_enc.name   = _strdup("utf-16");
+     cnxn->unicode_enc.ctype  = SQL_C_WCHAR;
+ 
+ #if PY_MAJOR_VERSION < 3