List:General Discussion« Previous MessageNext Message »
From:rafal somla Date:August 6 2013 8:59am
Subject:Re: libmysqlclient so version
View as plain text  
Hello again!

On 2013-08-05 15:07, Sebastien FLAESCH wrote:
> Hello Rafal and thank you for you answer.
> Note I sent a similar mail in the mailing list. So I think you should
> also answer in the mailing list too.
> I understand that it should be ok regarding
> $ ldd -r
> /home/sf/genero/devel/fgl/fgl/opt/fgl/dbdrivers/ ....
> => /opt3/dbs/mys/5.6.10/lib/
> (0xb7298000)
> If I may ask you something that would help me a lot:
> We have an internal debate, where some argue that we could have a
> unique binary linked to, that could work for all
> MySQL versions, for example for all 5.x versions.
> While it appears that 5.5.x and 5.6.x libraries are compatible (since
> the major version number (18) of the lib did not change), my instinct
> is that we should produce one specific binary for each major MySQL
> version we want to support (i.e 4.1.x, 5.0.x, 5.1.x, 5.4.x, 5.5.x,
> 5.6.x) ...
> We need a clear rule...!! For example with Oracle database, we have a
> binary for each major version of Oracle (9.0.x, 9.2.x, 10.1.x,
> 10.2.x, 11.1.x, 11.2.x, 12.1.x)
> I asked for a clear compatibility statement in the doc...
> If you could state that it's STRONGLY recommended to link C binaries
> with a<num> version for each major MySQL, it
> would help me to define a clear rule for our product...

In general we strive to keep the library backward compatible - as long
as the major version of the library is the same, it should be safe to
use the library with old applications. You should care about minor
version only if you want to use some new API calls introduced in later
release of the library. I think the best practice would be to check
which release of the library is used at runtime (using
mysql_client_version() API call) and then either make use of new
features conditional on this version check or error-out if library is
not recent enough

The major version of libmysqlclient library is not tied to a particular
version of MySQL server. It rather reflects changes in the C API itself.
Thus it is quite possible that two different versions of MySQL server
offer the same version 18.X of the client library with the same
functionality, but perhaps the newer version contains bug fixes or
improvements in the implementation of this functionality.

Thus I do not see a need to produce new version of binaries for each new
released version of MySQL server. Rather, you should re-compile your
applications only if either:

a) you want to use new C API features introduced in the new release, or

b) we introduce incompatible change in C API and thus increase its major
version number (e.g from 18.X to 19.0). In that case new binaries will
look for while old ones will still use

Note that even without re-compiling your apps, if you upgrade your MySQL
installation then new version of will be installed on
your system and picked up by the dynamic linker. So your application
will take benefit of bug fixes and other improvements in C API

Best Regards,

> Best regards, Sebastien FLAESCH Four JS Development Tools
> On 08/05/2013 02:10 PM, rafal somla wrote:
>> Hello Sebastien,
>> Thank you for your interest in our latest MySQL server release.
>>> On 07/31/2013 01:03 PM, Sunanda Menon wrote:
>>>> * The C API libmysqlclient shared-library .so files now have
>>>> version 18.1.0 (up from version 18.0.0 used in MySQL 5.5). (Bug
>>>> #16809055)
>>> What impact has this change regarding backward compatibility
>>> with existing C programs linked to older 5.6
>>> libs and what is the general policy regarding the backward
>>> compatibility for this library - where can we find clear
>>> statements in the doc?
>>> Does it make sense to change the .so version in a bug fix
>>> release, when the 5.6 was already releases as GA?
>>> We are providing database drivers for MySQL in our development
>>> tool. We have a C shared library linked to, and
>>> we have to link it with the correct 5.6 library version. What
>>> solution would you recommend, if you change the .so version
>>> number in MySQL 5.6 upgrade / bug fix releases?
>> Although we changed the minor library version in 5.6.13, it should
>> be fully backward compatible with previous versions and code using
>> the library should work without any problems. In particular, any
>> code which links against depends on
>> (note that the minor version number is not
>> present in the soname). Version 18.1.0 of the library installs with
>> a symbolic link ->
>> Thus we expect all applications to work as before after upgrading
>> to MySQL 5.6.13.
>> Please let us know if it does not work for you.
>> With Best Regards,
>> Rafal Somla, Senior Software Developer @ MySQL/Oracle
Re: libmysqlclient so versionrafal somla6 Aug