pyodbc ignores unixODBC install on OS X 10.9 (Mavericks)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install Homebrew and use that to install unixODBC on OS X 10 10.9 (Mavericks)
2. Try to connect to a DSN using pyodbc.

What is the expected output? What do you see instead?

Instead of connecting, you get this error:

pyodbc.Error: ('01000', "[01000] [unixODBC][Driver Manager]Can't open lib 'SQL 
Server' : file not found (0) (SQLDriverConnect)")

What version of the product are you using? On what operating system?

Using latest from source, installed using setup.py. OS X 10.9.1.

Please provide any additional information below.

OS X 10.9 no longer comes with iODBC installed on it. It is now *much easier* 
to use Homebrew to install unixODBC than it is to install iODBC, and pyodbc 
does not seem to support this configuration at all on OS X 10.9+.

I believe the problem comes from this code in setup.py which only compiles in 
support for iODBC if it detects the system is OS X (darwin).

elif sys.platform == 'darwin':
        # OS/X now ships with iODBC.
        settings['libraries'].append('iodbc')

I tried to change the append() line to:

        settings['libraries'].extend('iodbc', 'odbc')

but that didn't seem to work either. Does it matter what order we use here? I 
haven't tried appending 'odbc' first and then 'iodbc', so it might work. But if 
I did try that, I don't have an older OS X machine to test what that would do 
on systems prior to OS X 10.9, which have iODBC installed on them.

Original issue reported on code.google.com by lexicalu...@gmail.com on 20 Jan 2014 at 6:16

[GoogleCodeExporter]

I'm very sorry, but I copy/pasted that error incorrectly. The actual error you 
see is this:

pyodbc.Error: ('00000', '[00000] [iODBC][Driver Manager]dlopen({SQL Server}, 
6): image not found (0) (SQLDriverConnect)')

The error I posted was simply from a unixODBC configuration issue that is easy 
to resolve. I got it after chaining the setup.py code to: 

        settings['libraries'].append('odbc')

but before I had fixed my unixODBC configuration files.

Original comment by lexicalu...@gmail.com on 20 Jan 2014 at 6:20

[GoogleCodeExporter]

I primarily use OS/X 10.9 myself and only use iODBC because it ships with OS/X.

Is there any reason you don't want to use iODBC?

Original comment by mich...@kleehammer.com on 3 Feb 2014 at 12:56

• Changed state: Investigating

[GoogleCodeExporter]

It appears that OS X 10.9 (Mavericks) no longer ships with iODBC, and 
installation of unixODBC is much easier as it is provided by Homebrew.

Original comment by bo...@haarsma.eu on 11 Apr 2014 at 7:32

[GoogleCodeExporter]

Yeah, that's exactly it. unixODBC is now much easier to use on OS X than iODBC, 
but the setup.py for pyodbc simply doesn't allow it's usage.

Original comment by lexicalu...@gmail.com on 13 Apr 2014 at 12:28

[GoogleCodeExporter]

Any movement on this? 

Original comment by m...@jeremycade.com on 4 Sep 2014 at 11:16

[GoogleCodeExporter]

I'm trying to replicate our Linux dev environment on my Mac, but I'm struggling 
with this error. I do not have iODBC on my mac (OS X 10.9). Our install builds 
FreeTDS, unixODBC, and pyodbc from source, which all appear successful. I can 
successfully connect to our servers via isql. However, pyodbc is giving me this 
iODBC error. I don't think it's a good idea to try setting up iODBC, since 
unixODBC is used on production. So... what gives?

Original comment by Kevinrst...@gmail.com on 28 Oct 2014 at 8:06

[GoogleCodeExporter]

If you change the line in setup.py which I indicated in my first comment, 
pyodbc will work with unixODBC on 10.9 (and won't work with iODBC). Either or. 
There's probably a way to detect either iODBC or unixODBC, or allow both to 
work regardless, but that's the quick fix solution. Just grab the source, edit 
the file, and re-install (python setup.py install).

Original comment by lexicalu...@gmail.com on 28 Oct 2014 at 8:23

[GoogleCodeExporter]

Ah, it works now. I was using a version 3.0.3 and editing the setup.py line for 
platform == 'darwin' did not do anything. Just downloaded latest 3.0.7 and it 
worked. 

Original comment by Kevinrst...@gmail.com on 28 Oct 2014 at 8:52

[GoogleCodeExporter]

Interesting, 3.0.7 uses:

    settings['libraries'].append('iodbc') # this tells pyodbc to only look for libiodbc

so I wouldn't have expected it to work. Also I neglected to mention the change 
shown in my first reply to this email is wrong, my second reply corrects it to:

    settings['libraries'].append('odbc') # this tells pyodbc to only look for libodbc (unixODBC)

In my first reply I had thought that this would work for both:

    settings['libraries'].extend('iodbc', 'odbc')

but I found that it only worked for iODBC and not unixODBC, unfortunately.

Original comment by lexicalu...@gmail.com on 28 Oct 2014 at 9:09

[GoogleCodeExporter]

I've run into this a few times in the past and had updated the setup.py to use 
unixODBC. I changed the `iodbc` to `odbc`, as mentioned above, but still had 
issues during the build (it couldn't find the libs).

I just did a quick fork of pyodbc to GitHub to append the few lines so I don't 
have to remember next time =)

It's for the MacPorts unixODBC install, but could easily be updated to work 
with Homebrew too.

Here's the link if anyone wants it: https://github.com/juztin/pyodbc
All it's doing is the below (line 147):

 if '--macports' in sys.argv:
   # OS/X using unixODBC via MacPorts.
   sys.argv.remove('--macports')
   settings['libraries'].append('odbc')
   settings['include_dirs'] = ['/opt/local/include']
   settings['library_dirs'] = ['/opt/local/lib']
 else:
   # OS/X now ships with iODBC.
   settings['libraries'].append('iodbc')

Then, after unixODBC/FreeTDS are installed and working, I can just do a:

  % python.py setup.py build install --macports

Original comment by jus...@minty.io on 3 Feb 2015 at 4:27

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

FYI 3.0.10 is the latest version and uses unixodbc by default on OSX.

Original comment by dbkap...@gmail.com on 2 Jun 2015 at 3:34