blue-yonder / turbodbc

Turbodbc is a Python module to access relational databases via the Open Database Connectivity (ODBC) interface. The module complies with the Python Database API Specification 2.0.
http://turbodbc.readthedocs.io/en/latest
MIT License
623 stars 85 forks source link

Can't build master on macOS Sierra #63

Closed dirkjonker closed 7 years ago

dirkjonker commented 7 years ago

I can't build the latest master on macOS Sierra anymore using Python 3.5 or 3.6.

During make:

[ 10%] Building CXX object cpp/cpp_odbc/Library/CMakeFiles/cpp_odbc.dir/src/level2/level1_connector.cpp.o
/Users/Dirkjonker/src/turbodbc/cpp/cpp_odbc/Library/src/level2/level1_connector.cpp:361:43: error: no matching member function for call to 'prepare_statement'
    auto const return_code = level1_api_->prepare_statement(handle.handle, buffered.data_pointer(), buffered.size());
                             ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
/Users/Dirkjonker/src/turbodbc/cpp/cpp_odbc/Library/cpp_odbc/level1/api.h:117:15: note: candidate function not viable: no known conversion from 'unsigned short *' to 'SQLCHAR *'
      (aka 'unsigned char *') for 2nd argument
    SQLRETURN prepare_statement(SQLHSTMT statement_handle, SQLCHAR * statement_text, SQLINTEGER text_length) const;
              ^
/Users/Dirkjonker/src/turbodbc/cpp/cpp_odbc/Library/cpp_odbc/level1/api.h:122:15: note: candidate function not viable: no known conversion from 'unsigned short *' to 'SQLWCHAR *'
      (aka 'wchar_t *') for 2nd argument
    SQLRETURN prepare_statement(SQLHSTMT statement_handle, SQLWCHAR * statement_text, SQLINTEGER text_length) const;
              ^
1 error generated.
make[2]: *** [cpp/cpp_odbc/Library/CMakeFiles/cpp_odbc.dir/src/level2/level1_connector.cpp.o] Error 1
make[1]: *** [cpp/cpp_odbc/Library/CMakeFiles/cpp_odbc.dir/all] Error 2
make: *** [all] Error 2

1.0.5 builds without any errors. Also, on Centos 7, no problems.

MathMagique commented 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.

dirkjonker commented 7 years ago

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.

dirkjonker commented 7 years ago

Nope, links from homebrew were just fine, /usr/local/lib/libodbc.dylib points to unixODBC, however the unixODBC headers are at /usr/local/include

MathMagique commented 7 years ago

So the headers used for compiling are different from the library that is linked? That sounds a little problematic to me ;-).

dirkjonker commented 7 years ago

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
MathMagique commented 7 years ago

You can try setting the UNIXODBC_INCLUDE_DIR environment variable before calling the cmake command.

MathMagique commented 7 years ago

Glad you got it running!