Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 124484 - pymssql 0.7.3 failed to compile on AMD64
Summary: pymssql 0.7.3 failed to compile on AMD64
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: AMD64 Linux
: High normal
Assignee: Thomas Raschbacher
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-28 21:52 UTC by E A Faisal
Modified: 2006-03-02 04:18 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description E A Faisal 2006-02-28 21:52:26 UTC
Reproducible: Always
Step to Reproduce:
1. emerge pymssql

Actual Result:
pymssql 0.7.3 failed to build

mssqldbmodule.c: In function `GetRow':
mssqldbmodule.c:776: error: `DBCOL' undeclared (first use in this function)
mssqldbmodule.c:776: error: (Each undeclared identifier is reported only once
mssqldbmodule.c:776: error: for each function it appears in.)
mssqldbmodule.c:776: error: parse error before "dbcol"
mssqldbmodule.c:796: error: `DBBIT' undeclared (first use in this function)
mssqldbmodule.c:796: error: parse error before ')' token
mssqldbmodule.c:813: error: `dbcol' undeclared (first use in this function)
mssqldbmodule.c:815: error: `CI_REGULAR' undeclared (first use in this function)
mssqldbmodule.c:815: error: `CI_ALTERNATE' undeclared (first use in this function)
error: command 'x86_64-pc-linux-gnu-gcc' failed with exit status 1

Expected Result:
Successful build

GCC version:
Version 3.4.4

Hand compilation:
[ie. not via ebuild and using the source from pymssql.sourceforge.net]
Still failed

Possible reason(s) for compilation failure:
DBCOL and DBBIT datatype; dbcol function; CI_REGULAR and CI_ALTERNATE constants are probably valid for MS_WINDOWS platform only

Potential solution:
Apply patch below to mssqldbmodule.c

--- pymssql-0.7.3-portage/mssqldbmodule.c   2005-09-05 06:12:48.000000000 +0800
+++ pymssql-0.7.3-new/mssqldbmodule.c      2006-03-01 13:10:20.000000000 +0800
@@ -773,7 +773,9 @@
   DBDATETIME dt;
   PyObject *o;  // datetime or decimal value
   char buf[NUMERIC_BUF_SZ]; // buffer in which we store text rep of big nums
+#ifdef MS_WINDOWS
   DBCOL dbcol;
+#endif
   BYTE prec;
   PyObject *po;
 
@@ -792,10 +794,12 @@
       Py_INCREF(Py_None);
     } else {                   // else have data
       switch (coltype) {
+#ifdef MS_WINDOWS
         case SQLBIT:
           intdata = (int) *(DBBIT *) data;
           PyTuple_SET_ITEM(record,x-1,PyBool_FromLong((long)intdata));
           break;
+#endif
         case SQLINT1:
           intdata = (int) *(DBTINYINT *) data;
           PyTuple_SET_ITEM(record,x-1,Py_BuildValue("i",intdata));
@@ -810,13 +814,14 @@
           break;
         case SQLMONEY: case SQLMONEY4:
         case SQLNUMERIC: case SQLDECIMAL:  //XXX TEST
+#ifdef MS_WINDOWS
           dbcol.SizeOfStruct = sizeof(dbcol);
-
           if (dbcolinfo(dbproc,(rowinfo==REG_ROW) ? CI_REGULAR : CI_ALTERNATE,
                 x, (rowinfo==REG_ROW) ? 0 : rowinfo, &dbcol) == FAIL) {
               PyErr_SetString(_mssql_error,"Could not obtain column info");
               return NULL;
           }
+#endif
 
           if (coltype == SQLMONEY || coltype == SQLMONEY4)  prec = 4;

Result after Patching:
Compile successfully
Comment 1 E A Faisal 2006-03-02 04:18:52 UTC
OK! I made a fool of myself. Apparently I was using the package freetds version 0.62.3 - the stable package. pymssql package version 0.7.3 and above apparently require freetds 0.63 - testing package. Merging freetds 0.63 solved the problem.

However the ebuild for pymssql-0.7.3 required some amendment on the DEPEND variable. ">=dev-db/freetds-0.62.3" should really be ">=dev-db/freetds-0.63"