Beside the Oracle skills debate and the stupid mistakes with soname
changes between 5.5.8 and 5.5.10 or 5.6.x, (imagine all of this did
not happen):
I have a VERY simple question that needs a VERY CLEAR answer:
In our distribution packages (for different platforms! not only Linux),
I need to provide mysql client binaries for different versions of mysql
client environments:
4.1.x
5.1.x
5.4.x
5.5.x
5.6.x
How many binaries do I have to provide to support all these versions?
We compile with headers of a given version and link dynamically with
-lmysqlclient of course.
Thanks...
Seb
On 05/17/2013 11:26 AM, Reindl Harald wrote:
Oracle fails the context by make incompatible ABI changes
which are *expected* by raise the minor release number
but claim they are compatible until it is clear that
random things are broken and the soname needs to be
changed what leaves the question: was the QA at holiday
due the whole development cycle?
* MySQL 5.5.8 was the GA release
* MySQL 5.5.10 changed the soname
* *wow* the same happens now again with 5.6?
* this leaded in mass-rebuilds for linux-distributions after GA
* maybe one of the reasons why Oracle MySQL get dropped everywhere
and replaced by MariaDB and instead to accept the fact as example
in Fedora Oracle stepped in and make things more complicated
by try to figure out how both forks can be in the distribution
instead doing a clean cut
everybody but Oracle knows when you need to raise the so-number
to make sure any package-managment prevents the enduser to end
in incompatible linked applications, if the so-number would be
raised RPM would *not allow* to install the new client library
until all depending packages are rebuilt and if something like
the 5.5.10 breakage happens more than once i claim someone
to be learning resistent
Changes in MySQL 5.5.10 (2011-03-15)
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. (Bug #60061, Bug #11827366)
Am 17.05.2013 11:10, schrieb Sebastien FLAESCH:
Could someone from the libmysqlclient contributors comment on this, and
could someone complete the documentation regarding client compatiblity?
On 02/20/2013 09:31 AM, Sebastien FLAESCH wrote:
Hello,
FYI, I found this statement in the doc, at the end of the C API main page:
http://dev.mysql.com/doc/refman/5.6/en/c.html
If, after an upgrade, you experience problems with compiled client
programs, such as Commands out of sync or unexpected core dumps, you
probably have used old header or library files when compiling your
programs. In this case, check the date for your mysql.h file and
libmysqlclient.a library to verify that they are from the new MySQL
distribution. If not, recompile your programs with the new headers and
libraries. Recompilation might also be necessary for programs compiled
against the shared client library if the library major version number
has changed (for example from libmysqlclient.so.15 to libmysqlclient.so.16.
...
This sounds like guessing/hoping that the a client program compiled/linked
with older headers/libmysqlclient can eventually work with a more recent
client lib.
There should be a clear rule for that.
A simple rule could be that it's mandatory to recompile when upgrading to
a new production release (5.5 to 5.6), even if the client libs are still
compatible.
Further, I would expect to see such note in "Building Client Programs":
http://dev.mysql.com/doc/refman/5.6/en/building-clients.html
Seb
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql
