When sys-cluster/ceph-14.2.0-r1 builds, it builds a libcrc32.so library and various rados utilities (/usr/bin/rados, /usr/bin/radosgw, and Python libraries) link to it. But then libcrc32.so is not installed as part of the package, resulting in: # ceph -s Traceback (most recent call last): File "/usr/bin/ceph", line 137, in <module> import rados ImportError: libcrc32.so: cannot open shared object file: No such file or directory # ldd /usr/bin/rados | egrep crc32 libcrc32.so => not found libcrc32.so => not found This has been fixed in Fedora by forcing static linking of the internal/bundled libcrc32: https://bugzilla.redhat.com/show_bug.cgi?id=1686679 https://src.fedoraproject.org/rpms/ceph/c/13fa69ddf904febdb4fe2b8c509a819c15f5bf49?branch=295d99c80e2d6e8e67a2b8437132b222d1734010 I will attach a patch I adapted from the above. Currently still building (over an hour with -j10, yay); will follow up if it doesn't complete successfully for some reason. This is particularly painful because emerge succeeds, but then a working ceph cluster becomes a non-working one. I don't know all the rules for bumping -rN, but really suggest incrementing when this is fixed so that the update gets picked up by anyone who's already got -14.* installed.
Created attachment 570284 [details, diff] link the bundled libcrc32 statically, fixes rados runtime errors.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4b1f971d7c5d842d3422d2e167e9d8e272820af1 commit 4b1f971d7c5d842d3422d2e167e9d8e272820af1 Author: Patrick McLean <patrick.mclean@sony.com> AuthorDate: 2019-03-22 22:29:35 +0000 Commit: Patrick McLean <chutzpah@gentoo.org> CommitDate: 2019-03-22 22:32:11 +0000 sys-cluster/ceph: revbump 14.2.0-r1 static crc32 fork (bug #681216) Statically link internal crc32 fork to avoid collisions and runtime errors. Closes: https://bugs.gentoo.org/681216 Copyright: Sony Interactive Entertainment Inc. Package-Manager: Portage-2.3.62, Repoman-2.3.12 Signed-off-by: Patrick McLean <chutzpah@gentoo.org> .../ceph/{ceph-14.2.0-r1.ebuild => ceph-14.2.0-r2.ebuild} | 4 +++- .../ceph/files/ceph-14.2.0-link-crc32-statically.patch | 11 +++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-)
Thanks for the quick attention! Hm, this: > + dev-libs/crc32c:= May be fixing the problem twice? I do not know if dev-libs/crc32c is exactly / a drop-in replacement for the libcrc32 that ceph bundles (looks like it is the same lib, but ceph may make some customizations based on their PR history?), but I would think one of these is true? a) it is compatible, so once it's added as a DEPEND, we can shared-link to it just fine, and do not need the patch to add_library(crc32 STATIC ${crc32_srcs}) b) it is not compatible, so we do need the STATIC, but do not need it as a DEPEND c) I am confused and wrong ;)
(In reply to Hank Leininger from comment #3) > Thanks for the quick attention! > > Hm, this: > > > + dev-libs/crc32c:= > Ah, darn. I was initially trying to use the system version, and I guess I left that behind. Will remove.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=64034ce6ed5f78e6beea27681d2c68f3b5e75fdf commit 64034ce6ed5f78e6beea27681d2c68f3b5e75fdf Author: Patrick McLean <patrick.mclean@sony.com> AuthorDate: 2019-03-22 23:06:34 +0000 Commit: Patrick McLean <chutzpah@gentoo.org> CommitDate: 2019-03-22 23:07:00 +0000 sys-cluster/ceph: revbump to 14.2.0-r3 remove left over test dep Bug: https://bugs.gentoo.org/681216 Copyright: Sony Interactive Entertainment Inc. Package-Manager: Portage-2.3.62, Repoman-2.3.12 Signed-off-by: Patrick McLean <chutzpah@gentoo.org> sys-cluster/ceph/{ceph-14.2.0-r2.ebuild => ceph-14.2.0-r3.ebuild} | 1 - 1 file changed, 1 deletion(-)
