If Connector/ODBC is connecting securely with the MySQL server and the application using the connection makes calls itself to an OpenSSL library, the application might then fail, as two copies of the OpenSSL library will then be in use.
Connector/ODBC 8.0 and higher link to OpenSSL dynamically while earlier Connector/ODBC versions link to OpenSSL statically. This solves problems related to using two OpenSSL copies from the same application.
The TLSv1.0 and TLSv1.1 connection protocols are deprecated as of Connector/ODBC 8.0.26 and support for them is subject to removal in a future version.
To prevent the issue, in your application, do not allow OpenSSL
initialization in one thread and the opening of an Connector/ODBC
connection in another thread (which also initializes openSSL) to
happen simultaneously. For example, use a mutex to ensure
SQLConnect() calls and openSSL
initialization. In addition to that, implement the following if
Use a build of Connector/ODBC that links (statically or dynamically) to a version of the
libmysqlclientlibrary that is in turn dynamically linked to the same OpenSSL library that the application calls.
When creating a build of Connector/ODBC that links (statically or dynamically) to a version of the
libmysqlclientlibrary that is in turn statically linked to an OpenSSL library, do NOT export OpenSSL symbols in your build. That prevents incorrect resolution of application symbols; however, that does not prevent other issues that come with running two copies of OpenSSL code within a single application.