[freetds] ODBC on 64 bit linux fix.
Sebastien FLAESCH
sf at 4js.com
Fri Jan 18 04:22:46 EST 2008
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 ...
Cheers,
Seb
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.
>
> Cheers,
More information about the FreeTDS
mailing list