[Mono-dev] Problem with Odbc on 64 bit identified, please advise action
Mads Bondo Dydensborg
mbd at dbc.dk
Wed Mar 19 05:41:34 EDT 2008
onsdag 19 Marts 2008 skrev Jonathan Pryor:
> > There are problem also other places, besides SQLGetData
> >
> > So, what to do? Should I just file a bug, or any suggestions on a patch? I
> > have no idea about Odbc per se, I just needed this to work. :-/
>
> So here's the real problem: SQLGetData() et al use the SQLLEN type,
> which in the publicly available unixODBC-2.2.12 is:
>
> #if (SIZEOF_LONG == 8)
> #ifndef BUILD_REAL_64_BIT_MODE
> typedef int SQLINTEGER;
> typedef unsigned int SQLUINTEGER;
> #define SQLLEN SQLINTEGER
>
> i.e. SQLLEN is 32-bit by default, while CVS-HEAD has:
>
> #if (SIZEOF_LONG_INT == 8)
> #ifdef BUILD_LEGACY_64_BIT_MODE
> typedef int SQLINTEGER;
> typedef unsigned int SQLUINTEGER;
> #define SQLLEN SQLINTEGER
> // ...
> #else
> typedef int SQLINTEGER;
> typedef unsigned int SQLUINTEGER;
> typedef long SQLLEN;
>
> i.e. SQLLEN is 64bit by default. You can't reconcile these differences
> -- they BROKE the ABI!
In fact, I do not use unixODBC - I use the Sybase ODBC so files directly.
> It doesn't even look like it's possible to do a runtime version check,
> as I don't see any versioning function within unixODBC (except perhaps
> for TraceVersion(), but the .tar.gz download doesn't actually implement
> that so I can't compare). A version check wouldn't help anyway, as it's
> apparently still possible to use the "alternate" ABI by providing a
> preprocessor define.
>
> In short, we can "fix" this for you, but in the process we may end up
> breaking some other platform. There is no good solution.
OK - should I file a bug then, or should this just be documented somewhere? (I
did not find this kind of information prior to spending almost a day on
pinpointing the issue).
Regards
Mads
--
Med venlig hilsen/Regards
Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg
Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34
More information about the Mono-devel-list
mailing list