LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Server (https://www.linuxquestions.org/questions/linux-server-73/)
-   -   mysql-connector-odbc RHEL7 incompatible via unixODBC 2.3.1 to Percona 5.6? (https://www.linuxquestions.org/questions/linux-server-73/mysql-connector-odbc-rhel7-incompatible-via-unixodbc-2-3-1-to-percona-5-6-a-4175573005/)

rylan76 02-23-2016 06:59 AM

mysql-connector-odbc RHEL7 incompatible via unixODBC 2.3.1 to Percona 5.6?
 
Hi guys

I have installed Percona-Server 5.6.28-rel76.1.el7.x86_64 on my Centos 7 system via YUM from the official Percona repositories.

It is working fine just like official MySQL used to do.

I am however finding it impossible to connect to Percona 5.6.28 via ODBC.

I have installed the official Centos 7 unixODBC and mysql-connector-odbc packages via YUM.

If I do an isql test to use ODBC to access the running Percona instance, it segfaults:

Code:

[root@localhost lib64]# isql -v percona_dsnname username password
+---------------------------------------+
| Connected!                            |
|                                      |
| sql-statement                        |
| help [tablename]                      |
| quit                                  |
|                                      |
+---------------------------------------+
SQL> select now()
Segmentation fault (core dumped)
[root@localhost lib64]#

Removing Percona and putting official Mysql 5.6 back works perfectly - isql works so ODBC works - so the problem most definitely is Percona 5.6

My /var/log/messages contains:

Code:

Feb 23 14:53:49 localhost kernel: isql[13427]: segfault at 1010070 ip 00007f15e3003f7e sp 00007ffdcf518d70 error 4 in libmyodbc5w.so[7f15e2fdd000+47000]
Feb 23 14:53:49 localhost abrt-server: Generating core_backtrace
Feb 23 14:53:50 localhost abrt-server: Duplicate: core backtrace
Feb 23 14:53:50 localhost abrt-server: DUP_OF_DIR: /var/spool/abrt/ccpp-2016-02-23-14:07:26-12951
Feb 23 14:53:50 localhost abrt-server: Deleting problem directory ccpp-2016-02-23-14:53:49-13427 (dup of ccpp-2016-02-23-14:07:26-12951)

so it is mysql-connector-odbc (which provides libmyodbc5w.so) that is segfaulting when trying to execute a query on the running Percona instance - but simply conneting to it does work.

How can I connect via ODBC to Percona "drop-in replacement" - not true ! - using isql and do queries on Percona without having ODBC segfault?

Is there some way to get a "percona-sql-connector-odbc" for unixODBC 2.3.1 because the official Centos 7 mysql-connector-odbc clearly does not work.

Thanks!

rylan76 02-23-2016 07:42 AM

Hi guys

Ok, I think I've solved this for now.

Bit dirty / hacky, but it works.

Since I was getting the isql segfaults from the Centos 7 official mysql-connector-odbc YUMed package, specifically the file libmyodbc5w.so in that package (as indicated by checking my /var/log/messages and seeing

Code:

Feb 23 14:53:49 localhost kernel: isql[13427]: segfault at 1010070 ip 00007f15e3003f7e sp 00007ffdcf518d70 error 4 in libmyodbc5w.so[7f15e2fdd000+47000]
), I did the following.

I ran ldd on on libmyodbc5.so:

Code:

[root@localhost lib64]# ldd libmyodbc.so
linux-vdso.so.1 =>  (0x00007ffe80998000)
        libodbc.so.2 => /lib64/libodbc.so.2 (0x00007f882fc68000)
        libmysqlclient.so.18 => /lib64/libmysqlclient.so.18 (0x00007f882f769000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f882f54c000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f882f24a000)
        libodbcinst.so.2 => /lib64/libodbcinst.so.2 (0x00007f882f038000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f882ee33000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f882ea72000)
        libltdl.so.7 => /lib64/libltdl.so.7 (0x00007f882e868000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f882e651000)
        libssl.so.10 => /lib64/libssl.so.10 (0x00007f882e3e4000)
        libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f882dffd000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f882dcf4000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f8830133000)
        libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f882daa8000)
        libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f882d7c2000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f882d5be000)
        libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f882d38c000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f882d175000)
        libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f882cf66000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f882cd62000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f882cb47000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f882c922000)
        libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f882c6c0000)
        liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f882c49b000)
[root@localhost lib64]#

This specific dynamic dependancy is listed

Code:

libmysqlclient.so.18 => /lib64/libmysqlclient.so.18 (0x00007f882f769000)
So I took a WAG (wild-ass guess) that it was this file that causing the actual segfault of isql via its usage of libmyodbc5w.so from the official Centos 7 mysql-connector-odbc package.

On checking /usr/lib64 on my Centos 7 box, I found this for libmysqlclient.so.18:

Code:

[root@localhost lib64]# ls libmysqlclient* -l
lrwxrwxrwx. 1 root root      24 Feb 22 15:54 libmysqlclient_r.so.18 -> libmysqlclient.so.18.1.0
lrwxrwxrwx. 1 root root      24 Feb 22 15:54 libmysqlclient_r.so.18.1.0 -> libmysqlclient.so.18.1.0
-rwxrwxrwx  1 root root 1587872 Jun 22  2015 libmysqlclient.so.16.0.0
lrwxrwxrwx  1 root root      24 Feb 23 15:24 libmysqlclient.so.18 -> libmysqlclient.so.18.1.0
-rwxr-xr-x. 1 root root 3619736 Jan  9 00:39 libmysqlclient.so.18.1.0
[root@localhost lib64]#

e. g. the symbolic link libmysqlclient.so.18 actually pointed to to the dynamic library file

libmysqlclient.so.18.1.0

I read on an Ubuntu blog that somebody had a similar problem with unixODBC and Percona downgraded this file and that solved their problem.

So I went to an older Centos box I had and lo and behold it had a file in /usr/lib64 called

libmysqlclient.so.18.0.0

e. g. one minor version older.

I copied this file into my Centos 7 box's /usr/lib64. Then I did this:

Code:

rm libmysqlclient.so.18
and confirmed the "unlink symbolic link" question.

Then I symlinked this same symbolic name to the libmysqlclient.so.18.0.0 file:

Code:

ln -s libmysqlclient.so.18.0.0 libmysqlclient.so.18
so that my directory then looked like this:

Code:

[root@localhost lib64]# ls libmysqlclient* -l
lrwxrwxrwx. 1 root root      24 Feb 22 15:54 libmysqlclient_r.so.18 -> libmysqlclient.so.18.1.0
lrwxrwxrwx. 1 root root      24 Feb 22 15:54 libmysqlclient_r.so.18.1.0 -> libmysqlclient.so.18.1.0
-rwxrwxrwx  1 root root 1587872 Jun 22  2015 libmysqlclient.so.16.0.0
lrwxrwxrwx  1 root root      24 Feb 23 15:24 libmysqlclient.so.18 -> libmysqlclient.so.18.0.0
-rwxrwxrwx  1 root root 3133520 Feb  5  2015 libmysqlclient.so.18.0.0
-rwxr-xr-x. 1 root root 3619736 Jan  9 00:39 libmysqlclient.so.18.1.0
[root@localhost lib64]#

E. g. I switched the symbolic link used by libmyodbc5w.so to find

libmysqlclient.so.18.1.0

to not point to that anymore, but rather to point to

libmysqlclient.so.18.0.0

thus effectively forcing isql to use an older libmysqlclient version when trying to connect over ODBC to Percona.

This solved the problem, now if I use ISQL to test the ODBC connection to Percona:

Code:

[root@localhost lib64]# isql -v percona_dsnname username password
+---------------------------------------+
| Connected!                            |
|                                      |
| sql-statement                        |
| help [tablename]                      |
| quit                                  |
|                                      |
+---------------------------------------+

SQL> select now();
+--------------------+
| now()              |
+--------------------+
| 2016-02-23 15:43:26|
+--------------------+
SQLRowCount returns 1
1 rows fetched
SQL> ^c
[root@localhost lib64]#

So instead of segfaulting when I try to touch Percona from isql (therefore touch Percona over unixODBC on Centos 7) this actually WORKS - by using the older libmysqlclient.so.18.0.0 dynamic library file instead of the stock libmysqlclient.so.18.1.0 dynamic library file Percona installed by default.

E. g. to get Centos 7 with official Centos 7 unixODBC and mysql-connector-odbc to work correctly over ODBC to

Code:

Percona-Server-client-56.x86_64        5.6.28-rel76.1.el7            @percona-release-x86_64
downgrade in the /usr/lib64 directory the

libmysqlclient.so.18

symlink to point to

libmysqlclient.so.18.0.0

and NOT to point to libmysqlclient.so.18.1.0

Using the older MySQLClient dynamic library file enables unixODBC functionality under Centos 7 to access a Percona-Server 5.6.28-rel76.1.el7 MySQL "drop in replacement" instance.

Hope this helps somebody else.

Regards,


All times are GMT -5. The time now is 05:42 PM.