-----Original Message----- From: Sergei Golubchik [mailto:serg@askmonty.org] Sent: Montag, 28. März 2011 10:46 To: Vladislav Vaintroub Cc: monty@askmonty.org; maria-discuss@lists.launchpad.net Subject: Re: [Maria-discuss] client library shared library version changed in 5.5.10
Hi, Vladislav!
From http://dev.mysql.com/doc/refman/5.5/en/news-5-5-10.html >> Incompatible Change: The shared library version of the client library was increased to 18 to reflect ABI changes, and avoid compatibility problems with the client library in MySQL 5.1. Note that this is an incompatible change between 5.5.10 and earlier 5.5 versions, so client programs that use the 5.5 client library should be recompiled against the 5.5.10 client library.
Serg, as you have now probably have full insight into the MariaDB 5.5 code, is it possible to keep the API compatible with MariaDB 5.1 / MySQL 5.1 to not force all applications to have to be recompiled when upgrading to 5.5 ?
The API incompatibility was caused by migration to CMake. If you want to keep libraries compatible, if's something that Wlad may need to look into.
I do not really think it was CMake that broke it. The "official" ABI has not changed, however some people claim that API and ABI are 2 different things ;)
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 Wlad