Hi, Vladislav!
The main source of the breakage is migration to CMake: making libmysqlclient.so in 5.5 cmake builds don't use version script, and don't use -Wl,--whole-archive.
Yep, version script is likely a factor. Well spotted, thanks!
I've run the gcc -shared line manually in 5.5 with the version script, whole-archive, and the version changed to 16. And mysql client from 5.1 happily loaded the resulted library.
I think you would agree that our own utilities (mysql client for example) were not designed with well-designed shared libraries or backward compatibility in mind. Except officially documented API, they use a whole bunch of undocumented mysys/dbug/strings functionality. That stuff is not sacred, it is not found in the API header files, and it is subject to changes and refactoring, as you also noticed in case of missing my_no_flags_free(). Client utilities cannot link to shared client library on Windows and even on Linux they require "export everything"-strategy, which you fix with non-portable -Wl,--whole-archive. Personally, I would not support any attempts to link our client utilities with the shared library. We do not do it, and others should not attempt it either
I think I'd prefer our command-line tools (excluding mysqlbinlog) to be just "normal" client, using our client shared library. I don't like -Wl,--whole-archive and prefer a controlled export approach. But I think (not sure, and I hasn't tried) that the only problem is my_getopt - which de-facto was always part of the API, but in mysql-5.5 it's not exported. Our command-line utilites use it. I suspect that adding my_getopt function to the CLIENT_API_FUNCTIONS list, would've solved the issue. my_getopt has a great general applicability, I can easily see other clients that may want to use it (I would certainly use it if I were writing MySQL client). And we need to restore the version script. It's still there - in libmysql/libmysql.ver.in - but it's not used. Which made the bug#3074 to re-appear. Regards, Sergei