maria-discuss team mailing list archive

["Vladislav Vaintroub" <wlad@xxxxxxxxxxxxxxxx>]

> -----Original Message-----
> From: Sergei Golubchik [mailto:serg@xxxxxxxxxxxx]
> Sent: Montag, 28. März 2011 10:46
> To: Vladislav Vaintroub
> Cc: monty@xxxxxxxxxxxx; maria-discuss@xxxxxxxxxxxxxxxxxxx
> 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