psqlODBC won't load after installing MS SQL ODBC driver on RHEL 6

Question

I had the PostgreSQL drivers working on my RHEL 6. But after I installed Microsoft® SQL Server® ODBC Driver 1.0 for Linux I can no longer connect to PosgreSQL data sources. I can connect to SQL Server data sources fine.

When I had this same issue a week ago I uninstalled MS SQL Server ODBC driver from Linux and it fixed the issue. I removed MS SQL Server ODBC driver by executing the following commands:

rm /usr/bin/bcp
rm /usr/bin/sqlcmd
odbcinst -u -d -n "SQL Server Native Client 11.0"
rm -r /opt/microsoft/sqlncli

I still had to copy the psqlodbcw.so file (MS drivers installation made them inaccessible despite their existence) from another Linux machine that had PostgreSQL drivers working.

Again, I needed to use MS SQL drivers and so installed again. With MS SQL drivers installed again - I again failed to connect to PostgreSQL drivers. Though, I did not uninstall MS SQL drivers and checked what was going on. This time around I found that the setup files had got deleted: /usr/lib64/libodbcpsqlS.so. However, replenishing the file did not fix the issue since I did not uninstall MS SQL as in the previous case.

I kept getting the following error message in spite of the file being present with rwx permisions:

[root@localhost lib64]# isql -v STUDENT dsname pwd12345
[01000][unixODBC][Driver Manager]Can't open lib '/usr/lib64/psqlodbc.so' : file not found
[ISQL]ERROR: Could not SQLConnect
[root@localhost lib64]#

Here is a printout of the file permissions:

[root@localhost lib64]# ls -al p*.so
lrwxrwxrwx. 1 root root     12 Dec  7 09:15 psqlodbc.so -> psqlodbcw.so
-rwxr-xr-x. 1 root root 519496 Dec  7 09:35 psqlodbcw.so

and my odbcinst.ini file looks as follows:

[PostgreSQL]
Description=ODBC for PostgreSQL
Driver=/usr/lib/psqlodbc.so
Driver64=/usr/lib64/psqlodbc.so
Setup=/usr/lib/libodbcpsqlS.so
Setup64=/usr/lib64/libodbcpsqlS.so
FileUsage=1
UsageCount=4

I also referred to this link: http://mailman.unixodbc.org/pipermail/unixodbc-support/2010-September.txt

Output from running:

[root@localhost bin]# ldd /usr/lib64/psqlodbc.so 
    linux-vdso.so.1 =>  (0x00007fff371ea000)
    libssl.so.10 => /usr/lib64/libssl.so.10 (0x00007f55f288f000)
    libpq.so.5 => /usr/lib64/libpq.so.5 (0x00007f55f2667000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f55f2449000)
    libodbcinst.so.2 => not found
    libodbc.so.2 => not found
    libc.so.6 => /lib64/libc.so.6 (0x00007f55f20b5000)
    libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f55f1e73000)
    libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f55f1b94000)
    libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f55f198f000)
    libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f55f1763000)
    libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x00007f55f13c9000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f55f11c4000)
    libz.so.1 => /lib64/libz.so.1 (0x00007f55f0fae000)
    libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f55f0d77000)
    libldap_r-2.4.so.2 => /lib64/libldap_r-2.4.so.2 (0x00007f55f0b23000)
    /lib64/ld-linux-x86-64.so.2 (0x0000003d6f600000)
    libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f55f0918000)
    libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f55f0715000)
    libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f55f04fa000)
    libfreebl3.so => /lib64/libfreebl3.so (0x00007f55f0298000)
    liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00007f55f0088000)
    libssl3.so => /usr/lib64/libssl3.so (0x00007f55efe4c000)
    libsmime3.so => /usr/lib64/libsmime3.so (0x00007f55efc20000)
    libnss3.so => /usr/lib64/libnss3.so (0x00007f55ef8e3000)
    libnssutil3.so => /usr/lib64/libnssutil3.so (0x00007f55ef6bd000)
    libplds4.so => /lib64/libplds4.so (0x00007f55ef4b9000)
    libplc4.so => /lib64/libplc4.so (0x00007f55ef2b3000)
    libnspr4.so => /lib64/libnspr4.so (0x00007f55ef076000)
    libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00007f55eee5c000)
    libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f55eec3c000)

I don't want to uninstall the MS SQL drivers from my Linux machine to get the PostgreSQL drivers to work. I want both drivers to work on Linux.

Craig Ringer suggested to run:

[root@localhost bin]# LD_DEBUG=libs isql -v STUDENT dsname pwd12345
     22029: find library=libodbc.so.1 [0]; searching
     22029:  search path=/usr/lib64/tls/x86_64:/usr/lib64/tls:/usr/lib64/x86_64:/usr/lib64      (system search path)
     22029:   trying file=/usr/lib64/tls/x86_64/libodbc.so.1
     22029:   trying file=/usr/lib64/tls/libodbc.so.1
     22029:   trying file=/usr/lib64/x86_64/libodbc.so.1
     22029:   trying file=/usr/lib64/libodbc.so.1
     22029: 
     22029: find library=libdl.so.2 [0]; searching
     22029:  search path=/usr/lib64/tls:/usr/lib64      (system search path)
     22029:   trying file=/usr/lib64/tls/libdl.so.2
     22029:   trying file=/usr/lib64/libdl.so.2
     22029:  search cache=/etc/ld.so.cache
     22029:   trying file=/lib64/libdl.so.2
     22029: 
     22029: find library=libpthread.so.0 [0]; searching
     22029:  search path=/usr/lib64/tls:/usr/lib64      (system search path)
     22029:   trying file=/usr/lib64/tls/libpthread.so.0
     22029:   trying file=/usr/lib64/libpthread.so.0
     22029:  search cache=/etc/ld.so.cache
     22029:   trying file=/lib64/libpthread.so.0
     22029: 
     22029: find library=libc.so.6 [0]; searching
     22029:  search path=/usr/lib64/tls:/usr/lib64      (system search path)
     22029:   trying file=/usr/lib64/tls/libc.so.6
     22029:   trying file=/usr/lib64/libc.so.6
     22029:  search cache=/etc/ld.so.cache
     22029:   trying file=/lib64/libc.so.6
     22029: 
     22029: 
     22029: prelink checking: ok
     22029: 
     22029: calling init: /lib64/libpthread.so.0
     22029: 
     22029: 
     22029: calling init: /lib64/libc.so.6
     22029: 
     22029: 
     22029: calling init: /lib64/libdl.so.2
     22029: 
     22029: 
     22029: calling init: /usr/lib64/libodbc.so.1
     22029: 
     22029: 
     22029: initialize program: isql
     22029: 
     22029: 
     22029: transferring control: isql
     22029: 
     22029: find library=libnss_files.so.2 [0]; searching
     22029:  search path=/usr/lib64/tls:/usr/lib64      (system search path)
     22029:   trying file=/usr/lib64/tls/libnss_files.so.2
     22029:   trying file=/usr/lib64/libnss_files.so.2
     22029:  search cache=/etc/ld.so.cache
     22029:   trying file=/lib64/libnss_files.so.2
     22029: 
     22029: 
     22029: calling init: /lib64/libnss_files.so.2
     22029: 
     22029: 
     22029: calling init: /usr/lib64/gconv/UTF-16.so
     22029: 
     22029: find library=libssl.so.10 [0]; searching
     22029:  search path=/usr/lib64/tls:/usr/lib64      (system search path)
     22029:   trying file=/usr/lib64/tls/libssl.so.10
     22029:   trying file=/usr/lib64/libssl.so.10
     22029: 
     22029: find library=libpq.so.5 [0]; searching
     22029:  search path=/usr/lib64/tls:/usr/lib64      (system search path)
     22029:   trying file=/usr/lib64/tls/libpq.so.5
     22029:   trying file=/usr/lib64/libpq.so.5
     22029: 
     22029: find library=libodbcinst.so.2 [0]; searching
     22029:  search path=/usr/lib64/tls:/usr/lib64      (system search path)
     22029:   trying file=/usr/lib64/tls/libodbcinst.so.2
     22029:   trying file=/usr/lib64/libodbcinst.so.2
     22029:  search cache=/etc/ld.so.cache
     22029:  search path=/lib64/tls/x86_64:/lib64/tls:/lib64/x86_64:/lib64:/usr/lib64/tls:/usr/lib64        (system search path)
     22029:   trying file=/lib64/tls/x86_64/libodbcinst.so.2
     22029:   trying file=/lib64/tls/libodbcinst.so.2
     22029:   trying file=/lib64/x86_64/libodbcinst.so.2
     22029:   trying file=/lib64/libodbcinst.so.2
     22029:   trying file=/usr/lib64/tls/libodbcinst.so.2
     22029:   trying file=/usr/lib64/libodbcinst.so.2
     22029: 
[01000][unixODBC][Driver Manager]Can't open lib '/usr/lib64/psqlodbc.so' : file not found
[ISQL]ERROR: Could not SQLConnect
     22029: 
     22029: calling fini: isql [0]
     22029: 
     22029: 
     22029: calling fini: /usr/lib64/libodbc.so.1 [0]
     22029: 
     22029: 
     22029: calling fini: /lib64/libdl.so.2 [0]
     22029: 
     22029: 
     22029: calling fini: /lib64/libpthread.so.0 [0]
     22029: 
     22029: 
     22029: calling fini: /lib64/libnss_files.so.2 [0]
     22029: 
     22029: 
     22029: calling fini: /usr/lib64/gconv/UTF-16.so [0]
     22029: 
     22029: 
     22029: calling fini: /lib64/libc.so.6 [0]
     22029: 
[root@localhost bin]#

John Greene suggested:

[root@localhost bin]# ldd /usr/bin/isql 
    linux-vdso.so.1 =>  (0x00007fff12cf9000)
    libodbc.so.1 => /usr/lib64/libodbc.so.1 (0x0000003ef0800000)
    libdl.so.2 => /lib64/libdl.so.2 (0x0000003d6fe00000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003d70200000)
    libc.so.6 => /lib64/libc.so.6 (0x0000003d6fa00000)
    /lib64/ld-linux-x86-64.so.2 (0x0000003d6f600000)

My guess is that the problem is not at the postgres side ( can you still connect? Try `telnet mydatabaseserve 5432`) If that fails: call Bill Gates. — wildplasser, Dec 11 '12 at 23:35
Does the MS-SQL installer replace unixODBC with its own version? `md5sum` the binaries before and after. Does it mess with `/etc/ld.so.conf`? Did it change `LD_LIBRARY_PATH`? I'd say one way or another the MS SQL installer probably just clobbers your existing unixODBC install with no respect for packaging. You'll probably have to install it to a throwaway machine, collect up the files it produces, and make your own script to install it less intrusively. — Craig Ringer, Dec 12 '12 at 01:42
You say "this time around"... so you've tried something multiple times. Please cover more detail. What exactly did you try each time? Please also add the output of `ldd /usr/lib64/psqlodbc.so` and `LD_DEBUG=libs isql -v STUDENT dsname pwd12345` by editing your question. — Craig Ringer, Dec 12 '12 at 05:04

score 3 · Answer 1 · answered Dec 12 '12 at 00:25

Some really cool tricks to find out WHY it couldn't find the library file.

Where is your isql looking for the library?:
ldd <insert-path>/isql
If there are no 'not found'... to be found, then try following the code to see where it did NOT open:
strace -f isql -v STUDENT dsname pwd12345

And look for the open failure (most commonly symbolic-link failures) like these:

open("/usr/lib64/psqlodbc.so", O_RDONLY) = -1 ENOENT (No such file or directory)
Else, check the /etc/ld.so.conf or /etc/ld.so.conf.d/ for missing entries like

/usr/lib64

I'd like to keep the following in /etc/ld.so.conf.d/local.conf
/usr/local/lib64
/usr/local/lib
/usr/lib64
/usr/lib

If any changes were made to the /etc/ld.so.conf*, be sure to reload the library system cache (again):
ldconfig -v

Rather than using `strace` to trace library loading, it's way nicer to use `LD_DEBUG=libs`. Try running `LD_DEBUG=help /bin/true` for help, and see `man ld.so`. For example `LD_DEBUG=libs psql -c 'SELECT 1;'` — Craig Ringer, Dec 12 '12 at 05:05
Running `ldconfig -v` did not fix the issue. `strace` outputs too much info. I like LD_DEBUG. — Kapil Vyas, Dec 12 '12 at 22:08

score 1 · Accepted Answer · answered Dec 13 '12 at 17:46

I ran: rpm -q unixODBC to check if unixODBC was still installed and unfortunately found out that it wasn't. The unixODBC drivers had somehow got uninstalled after installing SQL Server drivers without explicit intervention. I installed with yum install unixODBC.x86_64. And for the first time, I got both SQL Server drivers,PostgreSQL drivers and other drivers to connect to their respective data sources from the same machine (RHEL 6).

psqlODBC won't load after installing MS SQL ODBC driver on RHEL 6

2 Answers2