Closed dirkjonker closed 7 years ago
That's weird; travis CI does not complain about it and I can compile things on my MacBook as well.
I think the issue may be that you are using iodbc
to build turbodbc. This issue provides some background information. iodbc
uses a 32 bit wchar_t type for wide SQL strings, while unixodbc
and Microsoft's original ODBC use 16 bit types (such as unsigned short
).
I'd recommend to install unixodbc
, since that's the thing turbodbc is tested with. iodbc
is no longer shipped with recent versions of OSX.
You don't see the issue with 1.0.5 because 1.0.5 did not use wide strings at all. You don't see the issue on Centos because it uses unixodbc
.
You are exactly right, I looked at the cmake output and it shows:
-- Detecting unixODBC library
-- Found header files at: /Library/Frameworks/iODBC.framework/Headers
-- Found library at: /usr/local/lib/libodbc.dylib
Funny thing is, I do have unixODBC installed, but Homebrew probably did not link it or something. Changing the paths in the CMakeCache.txt file fixes the issue.
Nope, links from homebrew were just fine, /usr/local/lib/libodbc.dylib
points to unixODBC, however the unixODBC headers are at /usr/local/include
So the headers used for compiling are different from the library that is linked? That sounds a little problematic to me ;-).
Got rid of iODBC, now it works fine
-- Detecting unixODBC library
-- Found header files at: /usr/local/include
-- Found library at: /usr/local/lib/libodbc.dylib
You can try setting the UNIXODBC_INCLUDE_DIR
environment variable before calling the cmake
command.
Glad you got it running!
I can't build the latest master on macOS Sierra anymore using Python 3.5 or 3.6.
During
make
:1.0.5 builds without any errors. Also, on Centos 7, no problems.