AMD64 distribution produces unresolved symbol error when attempting to use libmyodbc.so driver. 1. Install mysql-server, start mysqld service 2. Install ODBC packages 3. Configure odbc.ini / odbcinst.ini as follows: % cat /etc/odbc.ini [dbconn] driver=MySQL Description=MySQL Server=localhost % cat /etc/odbcinst.ini # Example driver definitinions # # # Included in the unixODBC package #[PostgreSQL] #Description = ODBC for PostgreSQL #Driver = /usr/lib/libodbcpsql.so #Setup = /usr/lib/libodbcpsqlS.so #FileUsage = 1 # Driver from the MyODBC package # Setup from the unixODBC package [MySQL] Description = ODBC for MySQL Driver = /usr/lib64/libmyodbc.so Setup = /usr/lib64/libodbcmyS.so FileUsage = 1 4. isql -v MySQL-test test [unixODBC][Driver Manager]Can't open lib '/usr/lib64/libmyodbc.so' : /usr/lib64/libmyodbc.so: undefined symbol: _dig_vec [ISQL]ERROR: Could not SQLConnect _dig_vec is provided by /usr/lib64/mysql/libmysqlclient.so.10. If I had to guess, I'd say this problem has to do with incorrect settings of library search paths (lib x lib64). I have a strong suspicion on unixODBC. It doesn't seem to be lib64-compatible. Not only does the default .ini file mention /usr/lib, that's unlikely to work on a lib64 box, but also: % strings /usr/lib64/libodbc.so.1 | grep /lib /usr/lib64 %s/libodbcinstQ%s /lib:/usr/lib /lib:/usr/lib The occurrences of /lib:/usr/lib feel like a strong indication that it might fail to locate libraries. A similar configuration (with s/lib64/lib/g) works on an ia32 box.
I think this is the same issue as bug #122877. Not sure yet whether it is MyODBC or unixODBC's fault, though your idea about search path seems plausible.
*** This bug has been marked as a duplicate of 122877 ***
Turns out the bug is really in MyODBC. I'm not sure what those strings in libodbc are being used for, if anything at all, but the real problem was mislinkage of libmyodbc.so against its required libraries. I'm going to leave this bug classified as unixODBC anyway, because it might help lead people to the right thing if they assume it's a unixODBC problem.
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.