I'm using generic Linux binaries on Debian.

If you install a binary tarball, you need to make sure all dependencies are satisfied — your package manager cannot help here. On Debian, I suppose, you need to install libodbc1 package.

On the same machine:

MariaDB [test]> SELECT version();
+----------------+
| version()      |
+----------------+
| 10.0.7-MariaDB |
+----------------+
1 row in set (0.00 sec)

MariaDB [test]> INSTALL SONAME 'ha_connect';
Query OK, 0 rows affected (0.00 sec)

The new version has new dependencies?

Yes, I confirm that was the problem, sorry.

Hi Federico,

It's more like the new packages have.
Since you are on Debian, you must be using the old-libc packages. Between 10.0.7 and 10.0.8 releases the machine where they are built changed from Hardy to Centos 5. Apparently, Hardy didn't have ODBC installed, so the packages were built without ODBC support (it's an option). Now the packages are built in full.

10.0.7:
linux-vdso.so.1 => (0x00007fffc33ff000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4d91a1e000)
libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f4d918bc000)
libstdc+.so.6 => /usr/lib/x86_64-linux-gnu/libstdc+.so.6 (0x00007f4d915b4000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4d91332000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4d90fa8000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4d91f67000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4d90da3000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f4d90b8c000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f4d90969000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f4d90752000)

10.0.8:

linux-vdso.so.1 => (0x00007fff217ff000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f34b4648000)
libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f34b44e6000)
libodbc.so.1 => not found
libstdc+.so.6 => /usr/lib/x86_64-linux-gnu/libstdc+.so.6 (0x00007f34b41de000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f34b3f5c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f34b3bd1000)
/lib64/ld-linux-x86-64.so.2 (0x00007f34b4b97000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f34b39cd000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f34b37b6000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f34b3592000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f34b337c000)

libc 2.14 bintars and OS-dependent packages had ODBC support (and hence the dependency) both in 10.0.7 and 10.0.8.

Using mariadb-10.0.14-linux-x86_64.tar.gz on a RHEL6 host:

  INSTALL SONAME 'ha_connect';

also resulted in the same error as above:

  ERROR 1126 (HY000): Can't open shared library '<REMOVED>lib/plugin/ha_connect.so' (errno: 2, libodbc.so.1: cannot open shared object file: No such file or directory)
 

The RH unixODBC-2.2.14-11.el6 package provides:

/usr/lib64/libodbc.so
/usr/lib64/libodbc.so.2
/usr/lib64/libodbc.so.2.0.0

( On RHEL5 the RH unixODBC-2.2.11-10.el5 package provides /usr/lib/libodbc.so.1 )

http://www.unixodbc.org/ mentions:

"28.Nov.2011 2.3.1 Released
Major change is to change the library version number from 1 to 2 to signal the SQLLEN change for 64 land. Should have been done for 2.3.0, but better late than never. So if after installing you have apps that can't find libodbc.so, its likely they are linked to libodbc.so.1, so just create a symlink from libodbc.so.2"

msodbcsql-11.0.2270.0-3.el6.x86_64 (used for SQL Server AlwaysOn) is built with unixODBC-2.3.0 so I ended up editing mariadb-10.0.14-linux-x86_64/bin/mysqld_safe to

mysqld_ld_library_path=/opt/microsoft/unixODBC/

and now after loading the CONNECT storage engine and after creating a ~/.odbc.ini for the mysql user and pointing VERTICAINI to a .vertica.ini file:

mysql> create table vertica_cluster_001 engine=connect table_type=ODBC srcdef="select sum(processor_core_count) as 'processor_core_count' from host_resources"  Connection='DSN=VerticaDSN01;';
Query OK, 0 rows affected (0.01 sec)

 
mysql> select * from vertica_cluster_001;
+----------------------+
| processor_core_count |
+----------------------+
|                  192 |
+----------------------+
1 row in set (0.03 sec)