Skip to Content.
Sympa Menu

freetds - Re: [freetds] ODBC on 64 bit linux fix.

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Sebastien FLAESCH <sf AT 4js.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] ODBC on 64 bit linux fix.
  • Date: Fri, 18 Jan 2008 10:22:46 +0100

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,





Archive powered by MHonArc 2.6.24.

Top of Page