Bug#354723: Problem NOT absent in Version 1.1.3
Now I built r-cran-rodbc 1.1.5 on my stable box - it works also on the unstable box. This again shows that the problem is in the build environment. However, I don't know how to further investigate this. Any suggestions? Please be patient. I need to take a look at the r-cran-rodbc and unixodbc sources and sort out what's breaking this. I'm still in the process of setting up my test case here, it will probably take me a few days to figure it out. I also really appreciate your help. If I can help, I'll do my best. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354723: Problem NOT absent in Version 1.1.3
reassign 354723 r-cran-rodbc tags 354723 patch thanks Back to you, Dirk. :) Explanation below. On Thu, Mar 02, 2006 at 07:16:14PM -0600, Dirk Eddelbuettel wrote: On 2 March 2006 at 14:22, Steve Langasek wrote: | On Thu, Mar 02, 2006 at 11:10:56PM +0100, Johannes Ranke wrote: | | So with RODBC the only variable here, I'm still pretty sure it's an RODBC | | bug. | I just built r-cran-rodbc 1.1.3 on my unstable box - the problem is | back! If I reinstall the version from stable, it goes away again (and so | on:) | Hah, ok, you beat me to it. :) | Alright, I'll try to take a look at what could be different between unixodbc | 2.2.4 and unixodbc 2.2.11 that would be triggering this. I have an amd64 | system I can test on, so hopefully the problem will be reproducible. That sounds more like it. The upstream author/maintainer of RODBC is pretty experienced in matters relating to 64bit having had access to 64bit Solaris forever. Be that as it may, the default UnixODBC API is not 64-bit clean. The spec wrongly specifies SQLLEN and SQLULEN to be 32-bit, and then shoves pointers into them all over the place -- and even, IIRC, defines some of these pointer-carrying functions to take SQLINT instead of SQLLEN. The only way you get a 64-bit clean interface out of UnixODBC is by specifying -DBUILD_REAL_64_BIT_MODE to the compiler. I've tried in the past to convince UnixODBC upstream to make this the default, so far without any success; I'm going to go ahead and make the Debian packages use this unconditionally, since this *is* the only way to have a 64-bit-clean UnixODBC, and it is the way that the library is being built today. But anyway, r-cran-rodbc still needs a patch, because it's using SQLINT in several places where SQLLEN is needed. The patch is attached. I have confirmed that this patch fixes the problem with returning rows on amd64. The only thing I don't have an explanation for, is why the sarge version of r-cran-rodbc works correctly. The hacks in the Debian package to support 64-bit systems properly aren't new; the sarge build had a different name for this variable, but libodbc was still shipping a non-standard 64-bit ABI. Incidentally, you're missing a proper clean target in this package; if the build is interrupted in the middle, ./debian/rules clean will fail to clean up the binaries from the src/ directory. On Fri, Mar 03, 2006 at 02:34:55PM -0600, Dirk Eddelbuettel wrote: No, it's clearly a difference in how r-cran-rodbc is being built against unixodbc 2.2.4 vs. 2.2.11, possibly due to 2.2.11's support for additional ODBC API calls. If memory serves, and in a galaxy far away, I once built RODBC against iODBC. Would it help to reconsider the other ODBC library? Or is that one dead now? I think iODBC is languishing unmaintained. I'm not sure if it's 64-bit clean or not; if it is, you need this same patch, and if it *isn't*, you have problems with truncated pointers all over the place instead. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ diff -Nru /tmp/KeP9uZ3ItY/rodbc-1.1.5/debian/changelog /tmp/W7l6P0uH3P/rodbc-1.1.5/debian/changelog --- /tmp/KeP9uZ3ItY/rodbc-1.1.5/debian/changelog2006-03-04 12:45:05.0 -0800 +++ /tmp/W7l6P0uH3P/rodbc-1.1.5/debian/changelog2006-03-04 12:45:07.0 -0800 @@ -1,3 +1,10 @@ +rodbc (1.1.5-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Fix a handful of SQL types for 64-bit compatibility + + -- Steve Langasek [EMAIL PROTECTED] Sat, 4 Mar 2006 02:09:39 -0800 + rodbc (1.1.5-1) unstable; urgency=low * New upstream release diff -Nru /tmp/KeP9uZ3ItY/rodbc-1.1.5/debian/rules /tmp/W7l6P0uH3P/rodbc-1.1.5/debian/rules --- /tmp/KeP9uZ3ItY/rodbc-1.1.5/debian/rules2006-03-04 12:45:05.0 -0800 +++ /tmp/W7l6P0uH3P/rodbc-1.1.5/debian/rules2006-03-04 12:45:07.0 -0800 @@ -6,6 +6,9 @@ include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/langcore.mk +CPPFLAGS := -DBUILD_REAL_64_BIT_MODE +export CPPFLAGS + ## We need the CRAN (upstream) name cranName := $(shell grep Package: DESCRIPTION | cut -f2 -d ) ## and we need to build a Debian Policy-conformant lower-case package name diff -Nru /tmp/KeP9uZ3ItY/rodbc-1.1.5/src/RODBC.c /tmp/W7l6P0uH3P/rodbc-1.1.5/src/RODBC.c --- /tmp/KeP9uZ3ItY/rodbc-1.1.5/src/RODBC.c 2005-08-05 23:32:57.0 -0700 +++ /tmp/W7l6P0uH3P/rodbc-1.1.5/src/RODBC.c 2006-03-04 12:45:07.0 -0800 @@ -53,7 +53,7 @@ SQLCHARColName[256]; SQLSMALLINTNameLength; SQLSMALLINTDataType; -SQLUINTEGERColSize; +SQLULENColSize; SQLSMALLINTDecimalDigits; SQLSMALLINTNullable; char *pData; @@ -61,7 +61,7 @@ SQLREALR4Data;
Bug#354723: Problem NOT absent in Version 1.1.3
* Steve Langasek [EMAIL PROTECTED] [060304 11:20]: reassign 354723 r-cran-rodbc tags 354723 patch thanks Well, thanks to you! The patch is attached. I have confirmed that this patch fixes the problem with returning rows on amd64. I can second this, the patch fixes the problem - I am impressed and happy! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354723: Problem NOT absent in Version 1.1.3
* Johannes Ranke [EMAIL PROTECTED] [060302 23:10]: I just built r-cran-rodbc 1.1.3 on my unstable box - the problem is back! If I reinstall the version from stable, it goes away again (and so on:) Hi again, Now I built r-cran-rodbc 1.1.5 on my stable box - it works also on the unstable box. This again shows that the problem is in the build environment. However, I don't know how to further investigate this. Any suggestions? Is it possible that my sid-ia32 chroot gets in the way (set up according to the Debian AMD64 Howto)? Quite restless, Johannes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354723: Problem NOT absent in Version 1.1.3
On Fri, Mar 03, 2006 at 03:50:32PM +0100, Johannes Ranke wrote: * Johannes Ranke [EMAIL PROTECTED] [060302 23:10]: I just built r-cran-rodbc 1.1.3 on my unstable box - the problem is back! If I reinstall the version from stable, it goes away again (and so on:) Hi again, Now I built r-cran-rodbc 1.1.5 on my stable box - it works also on the unstable box. This again shows that the problem is in the build environment. However, I don't know how to further investigate this. Any suggestions? Please be patient. I need to take a look at the r-cran-rodbc and unixodbc sources and sort out what's breaking this. I'm still in the process of setting up my test case here, it will probably take me a few days to figure it out. Is it possible that my sid-ia32 chroot gets in the way (set up according to the Debian AMD64 Howto)? No, it's clearly a difference in how r-cran-rodbc is being built against unixodbc 2.2.4 vs. 2.2.11, possibly due to 2.2.11's support for additional ODBC API calls. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#354723: Problem NOT absent in Version 1.1.3
On Fri, Mar 03, 2006 at 12:27:40PM -0800, Steve Langasek wrote: On Fri, Mar 03, 2006 at 03:50:32PM +0100, Johannes Ranke wrote: * Johannes Ranke [EMAIL PROTECTED] [060302 23:10]: I just built r-cran-rodbc 1.1.3 on my unstable box - the problem is back! If I reinstall the version from stable, it goes away again (and so on:) Hi again, Now I built r-cran-rodbc 1.1.5 on my stable box - it works also on the unstable box. This again shows that the problem is in the build environment. However, I don't know how to further investigate this. Any suggestions? Please be patient. I need to take a look at the r-cran-rodbc and unixodbc sources and sort out what's breaking this. I'm still in the process of setting up my test case here, it will probably take me a few days to figure it out. I really appreciate this. Lemme know if I can help with R aspects ... Is it possible that my sid-ia32 chroot gets in the way (set up according to the Debian AMD64 Howto)? No, it's clearly a difference in how r-cran-rodbc is being built against unixodbc 2.2.4 vs. 2.2.11, possibly due to 2.2.11's support for additional ODBC API calls. If memory serves, and in a galaxy far away, I once built RODBC against iODBC. Would it help to reconsider the other ODBC library? Or is that one dead now? [ You see what you get for all your hard work on unixodbc: us library users get totally ignorant of the finer print :) ] Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354723: Problem NOT absent in Version 1.1.3
| So with RODBC the only variable here, I'm still pretty sure it's an RODBC | bug. I just built r-cran-rodbc 1.1.3 on my unstable box - the problem is back! If I reinstall the version from stable, it goes away again (and so on:) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354723: Problem NOT absent in Version 1.1.3
On Thu, Mar 02, 2006 at 11:10:56PM +0100, Johannes Ranke wrote: | So with RODBC the only variable here, I'm still pretty sure it's an RODBC | bug. I just built r-cran-rodbc 1.1.3 on my unstable box - the problem is back! If I reinstall the version from stable, it goes away again (and so on:) Hah, ok, you beat me to it. :) Alright, I'll try to take a look at what could be different between unixodbc 2.2.4 and unixodbc 2.2.11 that would be triggering this. I have an amd64 system I can test on, so hopefully the problem will be reproducible. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#354723: Problem NOT absent in Version 1.1.3
I just built r-cran-rodbc 1.1.3 on my unstable box - the problem is back! If I reinstall the version from stable, it goes away again (and so on:) Hah, ok, you beat me to it. :) Alright, I'll try to take a look at what could be different between unixodbc 2.2.4 and unixodbc 2.2.11 that would be triggering this. I have an amd64 system I can test on, so hopefully the problem will be reproducible. and don't forget to reassign to unixodbc :):) Dirk will be happy... But it could also be some other lib, right? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354723: Problem NOT absent in Version 1.1.3
Alright, I'll try to take a look at what could be different between unixodbc 2.2.4 and unixodbc 2.2.11 that would be triggering this. I have an amd64 system I can test on, so hopefully the problem will be reproducible. and don't forget to reassign to unixodbc :):) Dirk will be happy... But it could also be some other lib, right? I tried to compile and install unixodbc 2.2.4-11 on unstable, but I failed due to dependencies I couldn't satisfy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354723: Problem NOT absent in Version 1.1.3
reassign 354723 unixodbc thanks On 2 March 2006 at 14:22, Steve Langasek wrote: | On Thu, Mar 02, 2006 at 11:10:56PM +0100, Johannes Ranke wrote: | | So with RODBC the only variable here, I'm still pretty sure it's an RODBC | | bug. | | I just built r-cran-rodbc 1.1.3 on my unstable box - the problem is | back! If I reinstall the version from stable, it goes away again (and so | on:) | | Hah, ok, you beat me to it. :) | | Alright, I'll try to take a look at what could be different between unixodbc | 2.2.4 and unixodbc 2.2.11 that would be triggering this. I have an amd64 | system I can test on, so hopefully the problem will be reproducible. That sounds more like it. The upstream author/maintainer of RODBC is pretty experienced in matters relating to 64bit having had access to 64bit Solaris forever. I don't think that it is a simple cast or something like that tripping up RODBC. And as I said, it's code has changed little, and RODBC is being used quite a bit. Now, that doesn't mean it must be unixodbc, but I would simply assign a higher probability to that case. Hence I'm reassigning as predicted by Steve :) Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
