I'm fooling around with trying to update mysql from 5.1.x to 5.5.x. One of the things that's happened in that transition is that they've dropped the separate "libmysqlclient_r.so" library --- presumably everything in regular "libmysqlclient.so" is now thread-safe. Upstream's idea of maintaining ABI compatibility is to provide symlinks, libmysqlclient_r.so.16.0.0 -> libmysqlclient.so.16.0.0 etc. I find that that only sort of works --- RPM fails to generate the --provides entries that it used to. So for example I have this with the old RPMs:
$ rpm -qp mysql-libs-5.1.52-1.fc13.x86_64.rpm --provides config(mysql-libs) = 5.1.52-1.fc13 libmysqlclient.so.16()(64bit) libmysqlclient.so.16(libmysqlclient_16)(64bit) libmysqlclient_r.so.16()(64bit) libmysqlclient_r.so.16(libmysqlclient_16)(64bit) mysql-libs = 5.1.52-1.fc13 mysql-libs(x86-64) = 5.1.52-1.fc13
but the closest I've been able to get with the new ones is
$ rpm -qp mysql-libs-5.5.8-1.fc13.x86_64.rpm --provides config(mysql-libs) = 5.5.8-1.fc13 libmysqlclient.so.16()(64bit) libmysqlclient.so.16(libmysqlclient_16)(64bit) mysql-libs = 5.5.8-1.fc13 mysql-libs(x86-64) = 5.5.8-1.fc13
I thought for a bit that RPM was ignoring symlinks for this purpose, but even copying instead of symlinking the library didn't get me a second set of provides items. What drives those decisions?
If there isn't any good hack to fix this, how bad would it be to just drop libmysqlclient_r.so ?
regards, tom lane
On Tue, 2010-12-21 at 22:10 -0500, Tom Lane wrote:
I'm fooling around with trying to update mysql from 5.1.x to 5.5.x. One of the things that's happened in that transition is that they've dropped the separate "libmysqlclient_r.so" library --- presumably everything in regular "libmysqlclient.so" is now thread-safe. Upstream's idea of maintaining ABI compatibility is to provide symlinks, libmysqlclient_r.so.16.0.0 -> libmysqlclient.so.16.0.0 etc. I find that that only sort of works --- RPM fails to generate the --provides entries that it used to. So for example I have this with the old RPMs:
$ rpm -qp mysql-libs-5.1.52-1.fc13.x86_64.rpm --provides config(mysql-libs) = 5.1.52-1.fc13 libmysqlclient.so.16()(64bit) libmysqlclient.so.16(libmysqlclient_16)(64bit) libmysqlclient_r.so.16()(64bit) libmysqlclient_r.so.16(libmysqlclient_16)(64bit) mysql-libs = 5.1.52-1.fc13 mysql-libs(x86-64) = 5.1.52-1.fc13
but the closest I've been able to get with the new ones is
$ rpm -qp mysql-libs-5.5.8-1.fc13.x86_64.rpm --provides config(mysql-libs) = 5.5.8-1.fc13 libmysqlclient.so.16()(64bit) libmysqlclient.so.16(libmysqlclient_16)(64bit) mysql-libs = 5.5.8-1.fc13 mysql-libs(x86-64) = 5.5.8-1.fc13
I thought for a bit that RPM was ignoring symlinks for this purpose, but even copying instead of symlinking the library didn't get me a second set of provides items. What drives those decisions?
I guess RPM is using the SONAME embedded in the library, which you can see with "readelf -d". Assuming that ld.so is happy to satisfy a NEEDED entry for libmysqlclient_r.so.16 by opening a file with that name and getting a library with SONAME libmysqlclient.so.16, it seems that rpm should add the Provides based on the file name.
On 12/21/2010 07:42 PM, Matt McCutchen wrote:
On Tue, 2010-12-21 at 22:10 -0500, Tom Lane wrote:
I'm fooling around with trying to update mysql from 5.1.x to 5.5.x. One of the things that's happened in that transition is that they've dropped the separate "libmysqlclient_r.so" library --- presumably everything in regular "libmysqlclient.so" is now thread-safe. Upstream's idea of maintaining ABI compatibility is to provide symlinks, libmysqlclient_r.so.16.0.0 -> libmysqlclient.so.16.0.0 etc. I find that that only sort of works --- RPM fails to generate the --provides entries that it used to. So for example I have this with the old RPMs:
$ rpm -qp mysql-libs-5.1.52-1.fc13.x86_64.rpm --provides config(mysql-libs) = 5.1.52-1.fc13 libmysqlclient.so.16()(64bit) libmysqlclient.so.16(libmysqlclient_16)(64bit) libmysqlclient_r.so.16()(64bit) libmysqlclient_r.so.16(libmysqlclient_16)(64bit) mysql-libs = 5.1.52-1.fc13 mysql-libs(x86-64) = 5.1.52-1.fc13
but the closest I've been able to get with the new ones is
$ rpm -qp mysql-libs-5.5.8-1.fc13.x86_64.rpm --provides config(mysql-libs) = 5.5.8-1.fc13 libmysqlclient.so.16()(64bit) libmysqlclient.so.16(libmysqlclient_16)(64bit) mysql-libs = 5.5.8-1.fc13 mysql-libs(x86-64) = 5.5.8-1.fc13
I thought for a bit that RPM was ignoring symlinks for this purpose, but even copying instead of symlinking the library didn't get me a second set of provides items. What drives those decisions?
I guess RPM is using the SONAME embedded in the library, which you can see with "readelf -d". Assuming that ld.so is happy to satisfy a NEEDED entry for libmysqlclient_r.so.16 by opening a file with that name and getting a library with SONAME libmysqlclient.so.16, it seems that rpm should add the Provides based on the file name.
ld.so isn't happy with that (lookups aren't based on filenames, so symlinks won't do anything and it will never find the library).
You need to create an empty shared library with the libmysqlclient_r.so.16 SONAME that has a DT_AUXILIARY entry for libmysqlclient.so.16.
On 12/21/2010 09:43 PM, Nicholas Miell wrote:
ld.so isn't happy with that (lookups aren't based on filenames, so symlinks won't do anything and it will never find the library).
You need to create an empty shared library with the libmysqlclient_r.so.16 SONAME that has a DT_AUXILIARY entry for libmysqlclient.so.16.
In theory, the following should produce a usable library:
eu-readelf -s /usr/lib64/mysql/libmysqlclient_r.so.16.0.0 | ./mysql_filter.gawk > hack.c gcc $(rpm --eval %optflags) -fPIC -shared -fno-toplevel-reorder -Wl,-soname,libmysqlclient_r.so.16 -Wl,--filter,libmysqlclient.so.16 hack.c -o libmysqlclient_r.so.16
but in practice, it gives me:
/usr/bin/ld: libmysqlclient_r.so.16: version node not found for symbol sf_malloc_mem_limit@@libmysqlclient_16 /usr/bin/ld: failed to set dynamic section sizes: Bad value collect2: ld returned 1 exit status
and nobody on the internet has any idea what that error means.
On Tue, 2010-12-21 at 23:28 -0800, Nicholas Miell wrote:
On 12/21/2010 09:43 PM, Nicholas Miell wrote:
ld.so isn't happy with that (lookups aren't based on filenames, so symlinks won't do anything and it will never find the library).
You need to create an empty shared library with the libmysqlclient_r.so.16 SONAME that has a DT_AUXILIARY entry for libmysqlclient.so.16.
In theory, the following should produce a usable library:
eu-readelf -s /usr/lib64/mysql/libmysqlclient_r.so.16.0.0 | ./mysql_filter.gawk > hack.c gcc $(rpm --eval %optflags) -fPIC -shared -fno-toplevel-reorder -Wl,-soname,libmysqlclient_r.so.16 -Wl,--filter,libmysqlclient.so.16 hack.c -o libmysqlclient_r.so.16
but in practice, it gives me:
/usr/bin/ld: libmysqlclient_r.so.16: version node not found for symbol sf_malloc_mem_limit@@libmysqlclient_16 /usr/bin/ld: failed to set dynamic section sizes: Bad value collect2: ld returned 1 exit status
and nobody on the internet has any idea what that error means.
I cargo-culted this into the libva spec, at one point, from Gwenole Beauchesne's Debian spec:
echo ".text"|gcc -xassembler - -o debian/tmp/usr/lib/libva.so.0.29.0 -shared -Wl,-soname,libva.so.0 -Ldebian/tmp/usr/lib -lva-x11
No idea how it actually works, but I believe it effectively does what you'd be trying to do if you did 'ln -s libva.so.0.29.0 libva.so.0' .
so maybe something like it could be used in this case. If it eats your cat, don't blame me =)
On Tue, 21 Dec 2010, Tom Lane wrote:
I'm fooling around with trying to update mysql from 5.1.x to 5.5.x. One of the things that's happened in that transition is that they've dropped the separate "libmysqlclient_r.so" library --- presumably everything in regular "libmysqlclient.so" is now thread-safe. Upstream's idea of maintaining ABI compatibility is to provide symlinks, libmysqlclient_r.so.16.0.0 -> libmysqlclient.so.16.0.0 etc. I find that that only sort of works --- RPM fails to generate the --provides entries that it used to. So for example I have this with the old RPMs:
$ rpm -qp mysql-libs-5.1.52-1.fc13.x86_64.rpm --provides config(mysql-libs) = 5.1.52-1.fc13 libmysqlclient.so.16()(64bit) libmysqlclient.so.16(libmysqlclient_16)(64bit) libmysqlclient_r.so.16()(64bit) libmysqlclient_r.so.16(libmysqlclient_16)(64bit) mysql-libs = 5.1.52-1.fc13 mysql-libs(x86-64) = 5.1.52-1.fc13
but the closest I've been able to get with the new ones is
$ rpm -qp mysql-libs-5.5.8-1.fc13.x86_64.rpm --provides config(mysql-libs) = 5.5.8-1.fc13 libmysqlclient.so.16()(64bit) libmysqlclient.so.16(libmysqlclient_16)(64bit) mysql-libs = 5.5.8-1.fc13 mysql-libs(x86-64) = 5.5.8-1.fc13
I thought for a bit that RPM was ignoring symlinks for this purpose, but even copying instead of symlinking the library didn't get me a second set of provides items. What drives those decisions?
The file must be recognized as being ELF by libmagic for the ELF soname dependencies to be generated, so yes the upstream symlink approach wont work. The other part of the puzzle is that rpm reads the ELF soname, and if it doesn't exist, basename of the file is used as a provide (to match the linker behavior). As the mysql libraries apparently do have a soname, the basename wont be used even if you copy/link to another name.
One possibility is to keep the upstream created symlinks and add the necessary provides manually in the spec.
- Panu -
Panu Matilainen pmatilai@laiskiainen.org writes:
One possibility is to keep the upstream created symlinks and add the necessary provides manually in the spec.
Right offhand that seems less magic than the ELF-hacking alternatives. However, how do I get the conditional "(64bit)" property on the Provides items? I hope there's a better way than #ifarch'ing for all the known 64-bit arches ...
regards, tom lane
On Wed, 2010-12-22 at 09:43 -0500, Tom Lane wrote:
Panu Matilainen pmatilai@laiskiainen.org writes:
One possibility is to keep the upstream created symlinks and add the necessary provides manually in the spec.
Right offhand that seems less magic than the ELF-hacking alternatives. However, how do I get the conditional "(64bit)" property on the Provides items? I hope there's a better way than #ifarch'ing for all the known 64-bit arches ...
what I'd actually recommend is that you explain to upstream that just creating symlinks isn't really the right thing to do, and have them sort out their build system to create duplicate libraries with the correct internal soname. It's really not right to just symlink them. The internal soname of the library really ought to match the filename.
On Wed, Dec 22, 2010 at 09:43:51AM -0500, Tom Lane wrote:
Panu Matilainen pmatilai@laiskiainen.org writes:
One possibility is to keep the upstream created symlinks and add the necessary provides manually in the spec.
Right offhand that seems less magic than the ELF-hacking alternatives. However, how do I get the conditional "(64bit)" property on the Provides items? I hope there's a better way than #ifarch'ing for all the known 64-bit arches ...
As another approach, giflib has this snippet so things can link against libungif::
# Handling of libungif compatibility MAJOR=`echo '%{version}' | sed -e 's/([0-9]+)..*/\1/'` %{__cc} $RPM_OPT_FLAGS -shared -Wl,-soname,libungif.so.$MAJOR -Llib/.libs -lgif -o libungif.so.%{version}
%install # Handling of libungif compatibility install -p -m 755 libungif.so.%{version} $RPM_BUILD_ROOT%{_libdir} ln -sf libungif.so.%{version} $RPM_BUILD_ROOT%{_libdir}/libungif.so.4 ln -sf libungif.so.4 $RPM_BUILD_ROOT%{_libdir}/libungif.so
It's very old so I don't know if it's still the best way to do things.
Another thought is that within the distro, patching software to stop using the deprecated library name is what we want. For Fedora, removing the compatibility symlink, not providing an alternative, and rebuilding any packages that use the older library name may be the right way to go.
-Toshio
Toshio Kuratomi a.badger@gmail.com writes:
Another thought is that within the distro, patching software to stop using the deprecated library name is what we want. For Fedora, removing the compatibility symlink, not providing an alternative, and rebuilding any packages that use the older library name may be the right way to go.
Well, that would certainly make life easier on my end. A quick look with repoquery suggests that only these packages are referencing libmysqlclient_r ... so maybe just rebuilding them is what to do.
mysql++ mysql-connector-c++ nekovm qt-mysql
regards, tom lane
devel@lists.stg.fedoraproject.org
-
Adam Williamson -
Matt McCutchen -
Nicholas Miell -
Panu Matilainen -
Tom Lane -
Toshio Kuratomi