I've been working on 1.22 doesn't compile on 64 bit systems with unixODBC on and off for a few days. Boy, this is tiresome (no reflection on the poster of this rt).
The unixODBC ODBC driver manager may be compiled from C source on 32 or 64 bit platforms but there are also C macros which affect whether it is built with the original 3.5 API (some ODBC APIs take 32 bit values or write 32 bits values to addresses even on 64 bit platforms) or the new API (where some APIs take 64 bit values or write 64 bit values to pointers on 64 bit platforms). As far as I can tell there is no way to tell how unixODBC was built unless it is supplied with the odbc_config binary which outputs a) the cc -D commands to define macros and b) the size of SQLLEN/SQLULEN (the new types which are 64 bit on 64 bit platforms). If you build your app one way and the driver manager (or ODBC driver) the other way you are going to get memory corruption on 64 bit platforms!
Add to this the fact that most Linux distributions include unixODBC 2.2.12 (or even earlier) and that is before odbc_config was even added to the unixODBC project. In addition some commercial ODBC drivers come with ODBC drivers matched with unixODBC but they are installed out of the usual system paths and are too old for odbc_config too.
Then there is the fact (mentioned in the rt) that most unixes have different paths for 32 bit and 64 bit shared objects (e.g., most linuxes put them in /lib and /lib64 or /usr/lib and /usr/lib64) and even have different environment variables (the old LD_LIBRARY_PATH, LD_RUN_PATH etc) for 32 bit and 64 bit.
As far as I can see it is almost impossible to match all this up in DBD::ODBC when running the Makefile.PL but I've made a lot of changes to help. If odbc_config is found it is believed and used (this is all down to which, if any, odbc_config is on your path). If -o (or ODBCHOME is set) this is believed but we may not find odbc_config and although it tries its best, you could run into problems. I've not added any tests for LD_LIBRARY_PATH64 etc as yet but I think it is better and certainly works better in the case sited in the rt.
As an aside, if you are a packager for a unix distribution please a) try and get up to date and at least use unixODBC 2.2.15 and b) add odbc_config to the binaries in the package. It will make life easier for everyone (and that is not withstanding the fact that 2.2.15 has a lot of fixes which most users need).