I have a C++ application that worked perfectly with MySQL 5.7, but now it crashes whenever I try to connect to MySQL 8.4. After checking the core dump, I discovered that there’s a conflict between two libraries. The third-party library libthosttraderapi_se.so appears to be interfering with the SSL connection that libmysqlclient.so is trying to establish.
When I remove the problematic third-party library from my program, the MySQL connection works fine. This suggests that the issue is specifically related to how these two libraries handle SSL connections.
I’m running this on CentOS 9. Has anyone encountered similar library conflicts when upgrading from MySQL 5.7 to 8.4? How can I resolve this SSL conflict without removing the third-party library completely?
Hit this same issue on CentOS 9 a few months back. Both libraries were bundling different OpenSSL versions internally. I fixed it by setting export LD_LIBRARY_PATH=/usr/lib64/mysql:$LD_LIBRARY_PATH before running the app - forces MySQL lib priority. You can also try compiling with -Wl,--as-needed to skip loading unnecessary SSL symbols.
This looks like a classic symbol collision issue that’s gotten worse with MySQL 8.4’s stricter SSL requirements. I hit something similar last year upgrading from 5.7 with a different third-party library. Both libraries are probably statically linking OpenSSL or using different versions. MySQL 8.4 enforces stronger SSL defaults than 5.7, which makes these conflicts worse. Try changing the library load order with LD_PRELOAD to control symbol resolution. Also check if there’s a newer version of libthosttraderapi_se.so that works with OpenSSL 3.x since CentOS 9 ships with that version. You could also use dlopen() with the RTLD_LOCAL flag when loading the third-party library to isolate its symbols. If none of that works, consider wrapping the MySQL connection logic in a separate process and using IPC for complete library isolation.
MySQL 8.4 has indeed tightened SSL certificate validation compared to 5.7, exposing conflicts between libraries that previously operated without issue. I’ve experienced a similar challenge while upgrading a trading application. The core issue lies in both libraries attempting to initialize their own OpenSSL contexts concurrently. To resolve this, implement lazy loading for the third-party library; delay the initialization of libthosttraderapi_se.so until after you have established and authenticated your MySQL connection. Additionally, consider specifying ssl-mode=REQUIRED in your MySQL connection string along with cipher suites that are less likely to clash with your trading API’s SSL configuration. Ultimately, it’s crucial to control the order of SSL context initialization to avoid conflicts.
In migrating legacy applications, I encountered a similar issue. MySQL 8.4 introduced stricter SSL configurations compared to 5.7, which can create conflicts with libraries like libthosttraderapi_se.so that utilize their own cryptographic implementations. A solution that worked well was to create a dedicated connection wrapper where I set the SSL mode to DISABLED initially. After loading the third-party library, I reconfigured the SSL context with mysql_options() and set MYSQL_OPT_SSL_MODE to SSL_MODE_DISABLED prior to establishing a connection. Additionally, employing MySQL’s C API connection pooling to establish connections before the third-party library is loaded can help mitigate these timing issues.