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.
This is triggered by upgrading mariadb from 1:10.1.8-3.fc24 to 1:10.1.11-4.fc24.
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
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.
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
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?
(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.
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;'
(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.
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) #
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?
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
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)
I've created a smaller reproducer and reported the problem against binutils (bz #1312151), since I suspect some issue during linking.
Build with fixed binutils on the way: http://koji.fedoraproject.org/koji/taskinfo?taskID=13189307
Thank you this important fix.