[freetds] ODBC on 64 bit linux fix.
sf at 4js.com
Fri Jan 18 04:36:11 EST 2008
Oups actually, it's the UnixODBC definition of the SQLParamOptions() function which is wrong...
This is what you (Steve) explain in previous mails (go fix UnixODBC)... right?
Sorry for the spam ;-)
Sebastien FLAESCH wrote:
> Thank you Steve,
> Here is what we have tested:
> CFLAGS="-D BUILD_REAL_64_BIT_MODE" ./configure --prefix=/opt3/dbs/tds/0.83 --with-odbc-nodm=/opt3/dbs/uxo/3.0
> But when compiling, we get:
> odbc.c:794: conflicting types for `SQLParamOptions'
> /dbs/64bits/uxo/3.0/include/sqlext.h:1893: previous declaration of `SQLParamOptions'
> Am I missing something or is this what Christos tried to fix?
> The headers comme from UnixODBC 2.2.12 ...
> Steve Langasek wrote:
>> Hi Sebastien,
>> On Fri, Jan 18, 2008 at 09:19:18AM +0100, Sebastien FLAESCH wrote:
>>> So first I doubt that Christos patch is I good idea:
>>> -SQLParamOptions(SQLHSTMT hstmt, SQLULEN crow, SQLULEN FAR * pirow)
>>> +SQLParamOptions(SQLHSTMT hstmt, SQLUINTEGER crow, SQLUINTEGER FAR * pirow)
>>> Changing SQLULEN to SQLUINTEGER in FreeTDS would break the standards... no?
>> Yes, I didn't look closely at this part of the patch. In those cases where
>> the ODBC standard is historically broken for 64-bit, it's because the API
>> calls for a SQLUINTEGER or SQLINTEGER where a 64-bit SQLLEN/SQLULEN is
>> needed to accomodate the range of possible values being passed; it would
>> never be appropriate to change an API call that's specified as SQLULEN to
>> SQLUINTEGER instead as part of the 64-bit porting.
>>> If we don't define BUILD_REAL_64_BIT_MODE, SQLLEN would be an int4, since
>>> int is 4 bytes on a 64b linux ... right?
>> All 64-bit Linux implementations are LP64, which means sizeof(int) = 4, yes.
> FreeTDS mailing list
> FreeTDS at lists.ibiblio.org
More information about the FreeTDS