Bug #59106 Wrong symlinks created for libmysqlclient_r shared library
Submitted: 21 Dec 2010 22:53 Modified: 11 Nov 2013 17:24
Reporter: [ name withheld ] Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Packaging Severity:S3 (Non-critical)
Version:5.5.8, 5.5.13 OS:Linux (Fedora 13 x86_64)
Assigned to: CPU Architecture:Any

[21 Dec 2010 22:53] [ name withheld ]
Description:
I see that 5.5 has removed the separate libmysqlclient_r library and creates symlinks for compatibility's sake.  That's fine, but it's not getting the symlinks quite right.  What it produces looks like

lrwxrwxrwx. 1 root root      17 Dec 21 16:29 libmysqlclient_r.so.16 -> libmysqlclient.so
lrwxrwxrwx. 1 root root      17 Dec 21 16:29 libmysqlclient_r.so.16.0.0 -> libmysqlclient.so

In an RPM package layout, where libmysqlclient.so is likely to be in a -devel subpackage, this is no good because the symlinks fail to function when the -devel subpackage is not present.  It would be better if the links worked like this:

lrwxrwxrwx. 1 root root      17 Dec 21 16:29 libmysqlclient_r.so.16 -> libmysqlclient.so.16
lrwxrwxrwx. 1 root root      17 Dec 21 16:29 libmysqlclient_r.so.16.0.0 -> libmysqlclient.so.16.0.0

How to repeat:
Build and install from source, examine installed symlinks
[23 Dec 2010 21:12] Sveta Smirnova
Thank you for the report.

> In an RPM package layout, where libmysqlclient.so is likely to be in a -devel subpackage,
this is no good because the symlinks fail to function when the -devel subpackage is not
present.  It would be better if the links worked like this:

Which package layout do you use? I have libmysqlclient.so in shared RPM:

$rpm2cpio MySQL-shared-5.5.8-1.rhel5.x86_64.rpm       | cpio -idvu
./usr/lib64/libmysqlclient.so
./usr/lib64/libmysqlclient.so.16
./usr/lib64/libmysqlclient.so.16.0.0
./usr/lib64/libmysqlclient_r.so
./usr/lib64/libmysqlclient_r.so.16
./usr/lib64/libmysqlclient_r.so.16.0.0
13644 blocks

$ls -l ./usr/lib64/
total 6840
lrwxrwxrwx 1 ssmirnova ssmirnova      17 Dec 23 22:10 libmysqlclient_r.so -> libmysqlclient.so
lrwxrwxrwx 1 ssmirnova ssmirnova      17 Dec 23 22:10 libmysqlclient_r.so.16 -> libmysqlclient.so
lrwxrwxrwx 1 ssmirnova ssmirnova      17 Dec 23 22:10 libmysqlclient_r.so.16.0.0 -> libmysqlclient.so
lrwxrwxrwx 1 ssmirnova ssmirnova      20 Dec 23 22:10 libmysqlclient.so -> libmysqlclient.so.16
lrwxrwxrwx 1 ssmirnova ssmirnova      24 Dec 23 22:10 libmysqlclient.so.16 -> libmysqlclient.so.16.0.0
-rwxr-xr-x 1 ssmirnova ssmirnova 6984277 Dec 23 22:10 libmysqlclient.so.16.0.0
drwx------ 3 ssmirnova ssmirnova    4096 Dec 23 22:10 mysql
[23 Dec 2010 21:56] [ name withheld ]
> Which package layout do you use?

I'm following the Red Hat/Fedora standard where the shared library itself is in the base package, and the libfoo.so symlink is in the -devel subpackage.  I think many other distros use a similar convention.

Since filing the bug, though, I've found out that it doesn't work right even with the corrected symlinks, because the soname in libmysqlclient isn't correct for libmysqlclient_r.  And that in turn causes RPM to fail to generate a Provides: for libmysqlclient_r.  You could possibly stick in a manual Provides: instead, but what I've been told is that the wrong-soname problem will cause issues at link time anyway.  So this needs some further thought.  Right at the moment, it's not ABI-compatible with existing clients that expect to link to libmysqlclient_r.
[7 Jan 2011 9:37] Ulf Wendel
Category is wrong, isn't it? This is libmysql from the server not C/C 6.0.2+.
[24 Jan 2011 12:23] Ulf Wendel
Changing Category: this is not Connector/C but libmysql [client] / MySQL Client Library shipped together with the MySQL Server.
[9 Feb 2011 19:24] Clint Byrum
The reason for not linking a versioned library symlink to the unversioned library is so that old versions can co-exist with new versions during a transition.

Its reasonable to expect that during a build, only one libmysqlclient.so exists in /usr/lib.. build hosts should be building things against new libraries.

However for runtime systems, its also reasonable to expect that things will need to keep running against old library versions until everything has been rebuilt. Of course, this is not possible because of this bug:

http://bugs.mysql.com/bug.php?id=59078

which is right now set to status "Not a bug", but as you can see from my comments there, most definitely is a bug, as new versions of libmysqlclient.so.16.0.0 are not ABI compatible w/ old versions, requiring the soname to be bumped to 17.
[14 Apr 2011 10:41] Valeriy Kravchuk
The problem of ABI-incompatible .so.16 should be already fixed in current version, 5.5.11. Please, check if it solves this problem for you also.
[16 Apr 2011 1:24] [ name withheld ]
Well, given that you've bumped the soname version as of 5.5.10, ABI compatibility is toast anyway.  At this point you should probably just drop the libmysqlclient_r symlink altogether; if applications have to be relinked, there's no point in having them still link to libmysqlclient_r.
[27 Apr 2011 14:34] Valeriy Kravchuk
Even with .so.18 now, I'd agree that symlinks to non-versioned libmysqlclient.so should be fixed.
[29 Oct 2013 15:40] Ståle Deraas
Posted by developer:
 
Terje confirms that this bug is fixed in bug#16809055, included in 5.6 14
[11 Nov 2013 17:24] Paul DuBois
That bugfix is in 5.6.13, actually.

The C API libmysqlclient shared-library files now have version 18.1.0
(up from version 18.0.0 used in MySQL 5.5).