Bug 1309199 - Rebuilding perl-DBD-MySQL-4.033-2.fc24 results into unresolvable mysql.so: symbol mysql_read_query_result, version libmysqlclient_16 not defined in file libmysqlclient.so.18 with link time reference
Rebuilding perl-DBD-MySQL-4.033-2.fc24 results into unresolvable mysql.so: sy...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: mariadb (Show other bugs)
24
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Jakub Dorňák
Fedora Extras Quality Assurance
:
Depends On: 1312151
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-17 02:36 EST by Petr Pisar
Modified: 2016-03-02 01:05 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-02 01:05:37 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
libmysql_versions.ld that defines symbols of the libmysqlclient.so library (14.29 KB, text/plain)
2016-02-25 07:21 EST, Honza Horak
no flags Details

  None (edit)
Description Petr Pisar 2016-02-17 02:36:45 EST
If I rebuild perl-DBD-MySQL-4.033-2.fc24 against current mariadb-devel-10.1.11-8.fc24.x86_64, resulting /usr/lib64/perl5/vendor_perl/auto/DBD/mysql/mysql.so will be unusable:

# ldd -r /usr/lib64/perl5/vendor_perl/auto/DBD/mysql/mysql.so 
        linux-vdso.so.1 (0x00007ffcdf58d000)
        libmysqlclient.so.18 => /usr/lib64/mysql/libmysqlclient.so.18 (0x00007fb05a510000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb05a2f2000)
        libz.so.1 => /lib64/libz.so.1 (0x00007fb05a0dc000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fb059dd2000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fb059bce000)
        libssl.so.10 => /lib64/libssl.so.10 (0x00007fb059953000)
        libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007fb0594f5000)
        libperl.so.5.22 => /lib64/libperl.so.5.22 (0x00007fb05910a000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fb058d33000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fb0589a9000)
        /lib64/ld-linux-x86-64.so.2 (0x0000564c658f5000)
        libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007fb05875d000)
        libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fb058476000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fb058272000)
        libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fb058040000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fb057e24000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fb057c0b000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fb0579d5000)
        libutil.so.1 => /lib64/libutil.so.1 (0x00007fb0577d1000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb0575ba000)
        libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007fb0573ab000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fb0571a6000)
        libfreebl3.so => /lib64/libfreebl3.so (0x00007fb056f29000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fb056d06000)
        libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fb056a91000)
symbol mysql_read_query_result, version libmysqlclient_16 not defined in file libmysqlclient.so.18 with link time reference     (/usr/lib64/perl5/vendor_perl/auto/DBD/mysql/mysql.so)
[...]

This prevents other Perl modules from using DBD::MySQL.
Comment 1 Petr Pisar 2016-02-17 02:46:52 EST
This is triggered by upgrading mariadb from 1:10.1.8-3.fc24 to 1:10.1.11-4.fc24.
Comment 2 Petr Pisar 2016-02-17 03:05:33 EST
This is the difference on mysql_read_query_result in readelf --symbols output:

[test@fedora-24 maria]$ < old grep mysql_read_query_result
   319: 0000000000032870   160 FUNC    GLOBAL DEFAULT   12 mysql_read_query_result_s@@libmysqlclient_18
   374: 0000000000032910   195 FUNC    GLOBAL DEFAULT   12 mysql_read_query_result_c@@libmysqlclient_18
   567: 00000000000294f0     0 FUNC    GLOBAL DEFAULT   12 mysql_read_query_result@libmysqlclient_16
   568: 00000000000294f0    17 FUNC    GLOBAL DEFAULT   12 mysql_read_query_result@@libmysqlclient_18
[test@fedora-24 maria]$ < new grep mysql_read_query_result
   317: 0000000000031f90   152 FUNC    GLOBAL DEFAULT   12 mysql_read_query_result_s@@libmysqlclient_18
   381: 0000000000032030   195 FUNC    GLOBAL DEFAULT   12 mysql_read_query_result_c@@libmysqlclient_18
   447: 0000000000028e50     0 FUNC    GLOBAL DEFAULT   12 mysql_read_query_result@@libmysqlclient_16
   572: 0000000000028e50    17 FUNC    GLOBAL DEFAULT   12 mysql_read_query_result@@libmysqlclient_18
Comment 3 Petr Pisar 2016-02-17 06:53:17 EST
As described in <http://www.scoberlin.de/content/media/http/informatik/gcc_docs/ld_3.html#SEC39>:

> When you have multiple definitions of a given symbol, there needs to be some
> way to specify a default version to which external references to this symbol
> will be bound. You can do this with the `foo@@VERS_2.0' type of `.symver'
> directive. You can only declare one version of a symbol as the default in
> this manner; otherwise you would effectively have multiple definitions of
> the same symbol.

At most one default version of a symbol makes sense.

The old libmysqlclient.so.18 declares only libmysqlclient_18 as the default:
 
  mysql_read_query_result@libmysqlclient_16
  mysql_read_query_result@@libmysqlclient_18

while the new libmysqlclient.so.18 declares both versions as default:

  mysql_read_query_result@@libmysqlclient_16
  mysql_read_query_result@@libmysqlclient_18

I think this is the reason why newly built libmysqlclient.so.18 application selects libmysqlclient_16 instead of the libmysqlclient_18.

I still don't understand why dynamic linker cannot found the libmysqlclient_16 versioned symbol in the library.
Comment 4 Morten Stevens 2016-02-17 14:37:50 EST
I see a similar issue with PowerDNS if I rebuild against the latest mariadb-devel...

Feb 17 19:46:45 fc24 pdns_server: Feb 17 19:46:45 Unable to load module '/usr/lib64/pdns/libgmysqlbackend.so': /usr/lib64/pdns/libgmysqlbackend.so: symbol mysql_stmt_bind_result, version libmysqlclient_16 not defined in file libmysqlclient.so.18 with link time reference
Feb 17 19:46:45 fc24 pdns_server: Feb 17 19:46:45 DNSBackend unable to load module in gmysql
Comment 5 Honza Horak 2016-02-18 11:47:04 EST
Worth mentioning that there is one difference between mariadb 10.1.8 and 10.1.11 that 10.1.8 was built with 5.2.1 and 10.1.11 is build with gcc-6.0.0. Can this be the cause?
Comment 6 Morten Stevens 2016-02-18 11:50:07 EST
(In reply to Honza Horak from comment #5)
> Worth mentioning that there is one difference between mariadb 10.1.8 and
> 10.1.11 that 10.1.8 was built with 5.2.1 and 10.1.11 is build with
> gcc-6.0.0. Can this be the cause?

I'm not sure. I've added Jakub to the cc list.
Comment 7 Terje Røsten 2016-02-18 16:30:34 EST
Changing spec file to use community-mysql-devel and rebuilding against MySQL 5.7.11 and libmysqlclient.so.1020 (really .20) works:

# ldd /usr/lib64/perl5/vendor_perl/auto/DBD/mysql/mysql.so
	linux-vdso.so.1 (0x00007fff3f7d9000)
	libmysqlclient.so.1020 => /usr/lib64/mysql/libmysqlclient.so.1020 (0x00007f130d5f6000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f130d3d8000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f130d1c2000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f130ceb8000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f130ccb0000)
	libssl.so.10 => /lib64/libssl.so.10 (0x00007f130ca35000)
	libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f130c5d7000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f130c3d3000)
	libperl.so.5.22 => /lib64/libperl.so.5.22 (0x00007f130bfe7000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f130bc11000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f130b887000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f130b66f000)
	/lib64/ld-linux-x86-64.so.2 (0x00005609f8ff1000)
	libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f130b423000)
	libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f130b13d000)
	libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f130af38000)
	libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f130ad06000)
	libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f130aaeb000)
	libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f130a8d1000)
	libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f130a69b000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007f130a498000)
	libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f130a288000)
	libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f130a084000)
	libfreebl3.so => /lib64/libfreebl3.so (0x00007f1309e06000)
	libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f1309be4000)
	libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f130996f000)
#

No errors from:

# perl -e 'use DBD::mysql;'
Comment 8 Petr Pisar 2016-02-19 02:07:26 EST
(In reply to Terje Røsten from comment #7)
> # ldd /usr/lib64/perl5/vendor_perl/auto/DBD/mysql/mysql.so

I'd like to emphases importance of the ldd's "-r" option. The problem with mariadb is not a soname, but symbol names. While plain "ldd" resolves only sonames, it succeeds, but "ldd -r" fails on resolving the symbols against mariadb library.
Comment 9 Terje Røsten 2016-02-19 02:44:54 EST
Ok, with -r added it still works with MySQL 5.7.11:

# ldd -r /usr/lib64/perl5/vendor_perl/auto/DBD/mysql/mysql.so
	linux-vdso.so.1 (0x00007ffec5ef4000)
	libmysqlclient.so.1020 => /usr/lib64/mysql/libmysqlclient.so.1020 (0x00007f7e3126f000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7e31051000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f7e30e3b000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f7e30b31000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f7e30929000)
	libssl.so.10 => /lib64/libssl.so.10 (0x00007f7e306ae000)
	libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f7e30250000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f7e3004c000)
	libperl.so.5.22 => /lib64/libperl.so.5.22 (0x00007f7e2fc60000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f7e2f88a000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f7e2f500000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f7e2f2e8000)
	/lib64/ld-linux-x86-64.so.2 (0x00005599fca01000)
	libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f7e2f09c000)
	libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f7e2edb6000)
	libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f7e2ebb1000)
	libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f7e2e97f000)
	libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f7e2e764000)
	libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f7e2e54a000)
	libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f7e2e314000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007f7e2e111000)
	libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f7e2df01000)
	libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f7e2dcfd000)
	libfreebl3.so => /lib64/libfreebl3.so (0x00007f7e2da7f000)
	libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f7e2d85d000)
	libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f7e2d5e8000)
#
Comment 10 Honza Horak 2016-02-24 05:25:30 EST
I've build the same srpm in F23 and F24 and then ran `objdump -T libmysqlclient.so.18.0.0` and this is the difference:

F23: (libmysqlclient_16) mysql_info
F24: libmysqlclient_16 mysql_info

For libmysqlclient_18 versioned symbols it is the same.

I'm not sure much I understand it, my interpretation is the libmysqlclient_16 is not necessary in F23, so there are both, unversioned and versioned variant of mysql_info symbol, while in F24 there is only versioned.

The fact that same SRPM produces different output on F23 and F24 means the difference is in the toolchain. Jakub, can you tell us what changed in gcc 6 in regards the symbol versioning? Or even better, give us some guidance where this needs to be fixed?
Comment 11 Jan Kurik 2016-02-24 10:34:10 EST
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
Comment 12 Honza Horak 2016-02-25 07:21 EST
Created attachment 1130500 [details]
libmysql_versions.ld that defines symbols of the libmysqlclient.so library

Few more information for debugging, the library is linked with this:
  -Wl,/builddir/build/BUILD/mariadb-10.0.23/libmysql/libmysql_versions.ld

(attached)
Comment 13 Honza Horak 2016-02-25 16:36:18 EST
I've created a smaller reproducer and reported the problem against binutils (bz #1312151), since I suspect some issue during linking.
Comment 14 Honza Horak 2016-03-01 10:10:01 EST
Build with fixed binutils on the way: http://koji.fedoraproject.org/koji/taskinfo?taskID=13189307
Comment 15 Petr Pisar 2016-03-01 10:54:26 EST
Thank you this important fix.

Note You need to log in before you can comment on or make changes to this bug.