The client library — libmysqlclient — is part of the same source code repository as the server. It comes both as a dynamic link library (.so), also called a shared library, and as a static link library (.a). During the 5.7 development cycle, we’ve made several improvements to the library, which has resulted in a bump from ABI version 18 to version 20. This is the third in a series of blog posts focusing on the client library. If you want to read the whole series, go back to the first post, called The API, the whole API and nothing but the API.
In the previous post, I covered how the client library is versioned. This time we’re going to look at a few changes that have nothing to do with the API or ABI, but still affect how client applications are built.
Thread safety
A long time ago, libmysqlclient came in two versions: one that was thread safe and one that wasn’t. But that was a long time ago. Since MySQL 5.5, the thread safe libmysqlclient_r library has just been a symlink to the libmysqlclient library, which has been thread safe at least since then.
The symlinks have been there in MySQL 5.5 and 5.6, but in 5.7 we’ve finally removed them. They’re simply not needed anymore. Since we’ve bumped the major ABI version number, there are no applications linking with version 20 of the libmysqlclient_r library.
The symlinks are gone, but we’ve kept the --libs_r option to mysql_config. It now produces the same output as the --libs option. This means that applications that used to link with libmysqlclient_r now will link with libmysqlclient, and everything will work just the way it used to.
Developers don’t need to do anything, but at some point in the future, we expect --libs_r to go, so it’s a good idea to replace it with --libs now. Using --libs_r only makes sense if you’re linking with libmysqlclient_r version 16 (which came with MySQL 5.1), but that version has reached end of life a long time ago.
Pkg-config
If you’re changing mysql_config options in your build scripts, maybe you should have a look at pkg-config while you’re at it. Back when mysql_config was written, automated build systems weren’t that common. They are now. Both autotools and CMake can use pkg-config to locate libraries and find compile and link flags.
With MySQL 5.7, we’ve added pkg-config support. If you’re building MySQL from source, you might want to know that by default, mysqlclient.pc will be installed to INSTALL_LIBDIR/pkgconfig/. This can be tweaked using the INSTALL_PKGCONFIGDIR CMake option at build time.
After installing MySQL, you can use the pkg-config command to retrieve the same compile and link information that you can get from mysql_config. I won’t go into the details about each option, but here’s a mysql_config to pkg-config conversion table:
| mysql_config | pkg-config |
|---|---|
| mysql-config --cflags | pkg-config --cflags mysqlclient |
| mysql-config --cxxflags | N/A |
| mysql-config --libs | pkg-config --libs mysqlclient pkg-config --libs --static mysqlclient |
| mysql_config --variable=pkgincludedir | pkg-config --variable=includedir mysqlclient |
| mysql_config --variable=pkglibdir | pkg-config --variable=libdir mysqlclient |
| mysql_config --version | N/A |
| N/A | pkg-config --modversion mysqlclient |
| N/A | pkg-config --exists mysqlclient |
Using pkg-config the right way
You can, as a first step, replace mysql_config commands with pkg-config command, but that would still leave you with custom build scripts to maintain. As I already mentioned, pkg-config is supported by some of the most popular build systems, and the best way would be to exploit this.
For the fourth and final post in this series, I will cover how to write a simple MySQL client using CMake and pkg-config to automatically find the library and necessary compile and link flags.
Until then, if you have any questions or comments, please use the comment field below.