From the error we can see you are using unixODBC and I presume "DSI" is what Vertica calls itself as ODBC error text is formatted with entries in [] from left to right as the path though the different components (see Example diagnostic messages).
I presume that message should be "No SQLGetPrivateprofileString could be found". SQLGetPrivateProfileString is an API provided by the ODBC driver manager to read entries from the odbc.ini file. I believe it should be found in the libodbcinst.so shared object however, some distributions (e.g., Ubuntu/Debian) strip symbols from shared objects so it is difficult to verify this.
In your DSN, the driver is the file "/opt/vertica/lib/libverticaodbc_unixodbc.so". Although it is more usual to name the driver in the odbc.ini and add an entry to the odbcinst.ini file your DSN looks ok. e.g.:
/etc/odbcinst.ini:
[Easysoft ODBC-SQL Server SSL]
Driver=/usr/local/easysoft/sqlserver/lib/libessqlsrv.so
Setup=/usr/local/easysoft/sqlserver/lib/libessqlsrvS.so
Threading=0
FileUsage=1
DontDLClose=1
/etc/odbc.ini:
[SQLSERVER_SAMPLE_SSL]
Driver=Easysoft ODBC-SQL Server SSL
Description=Easysoft SQL Server ODBC driver
.
.
See in the above example doing it this way allows you to specify additional options associated with the driver like Threading (and a quick search on the net suggests Vertica can use Threading=1 which is less restrictive if using a threaded program) and DontDLClose. However, as I said things should work as you have them now.
Now the next bit depends on your platform and I didn't notice if you specified one. You need to examine that shared object for your ODBC Driver and see what it depends on. On Linux you do something like this:
$ ldd /usr/local/easysoft/sqlserver/lib/libessqlsrv.so
linux-gate.so.1 => (0xb76ff000)
libodbcinst.so.1 => /usr/lib/libodbcinst.so.1 (0xb75fe000)
libesextra_r.so => /usr/local/easysoft/lib/libesextra_r.so (0xb75fb000)
libessupp_r.so => /usr/local/easysoft/lib/libessupp_r.so (0xb75de000)
libeslicshr_r.so => /usr/local/easysoft/lib/libeslicshr_r.so (0xb75cd000)
libestdscrypt.so => /usr/local/easysoft/lib/libestdscrypt.so (0xb75c8000)
libm.so.6 => /lib/libm.so.6 (0xb75a2000)
libc.so.6 => /lib/libc.so.6 (0xb7445000)
libltdl.so.7 => /usr/lib/libltdl.so.7 (0xb743b000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7421000)
/lib/ld-linux.so.2 (0xb7700000)
libdl.so.2 => /lib/libdl.so.2 (0xb741d000)
which shows this ODBC driver depends on libodbcinst.so.1 and the dynamic linker found it. I imagine your Vertica driver should look similar in this respect although it is possible the Vertica driver dynamically loads this shared object itself on first being loaded. Either way, it looks like the Vertica driver cannot find the symbol SQLGetPrivateProfileString which is in libodbcinst.so so make sure a) you have libodbcinst.so b) your dynamic linker knows about it (how this is done depends on your platform - on Linux see /etc/ld.so.conf and LD_LIBRARY_PATH and the man page for ld.so) c) run ldd (or equivalent) on it to make there are no missing dependencies.
The vertica.ini file is probably where the driver stores driver specific configuration - some drivers do this. If the format of this file is like the odbc ones above it may also use SQLGetPrivateProfileString for this file as you can tell that ODBC API which file to use.
Beyond this I've no more ideas other than contact vertica.
