Description of problem: RHCS is compiled --without-libatomic-ops Version-Release number of selected component (if applicable): ceph-0.94.2-6.el7cp Actual results: no atomic ops Expected results: Ceph should be built --with-libatomic-ops, as is done upstream
discussed at program meeting today and agreed to take this in for 1.3.1
This actually failed to print the output of libbatomic_ops.so.1 . I don't see the libbatomic_ops.so.1 linked with the ceph libs.. Version : Ceph :- 0.94.2.8 Note :- Checked on an Server which was Upgraded from 1.3.0 --------------------------------------------------------------------------- [root@magna047 ~]# ldd /usr/lib64/librados.so.2 | grep atomic [root@magna047 ~]# ldd /usr/lib64/librados.so.2 linux-vdso.so.1 => (0x00007fffab347000) libboost_thread-mt.so.1.53.0 => /lib64/libboost_thread-mt.so.1.53.0 (0x00007fdcf2f2a000) libboost_system-mt.so.1.53.0 => /lib64/libboost_system-mt.so.1.53.0 (0x00007fdcf2d25000) liblttng-ust.so.0 => /lib64/liblttng-ust.so.0 (0x00007fdcf2ad9000) libssl3.so => /lib64/libssl3.so (0x00007fdcf2897000) libsmime3.so => /lib64/libsmime3.so (0x00007fdcf266f000) libnss3.so => /lib64/libnss3.so (0x00007fdcf2349000) libnssutil3.so => /lib64/libnssutil3.so (0x00007fdcf211d000) libplds4.so => /lib64/libplds4.so (0x00007fdcf1f18000) libplc4.so => /lib64/libplc4.so (0x00007fdcf1d13000) libnspr4.so => /lib64/libnspr4.so (0x00007fdcf1ad5000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fdcf18b8000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fdcf16b4000) libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fdcf14af000) librt.so.1 => /lib64/librt.so.1 (0x00007fdcf12a6000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fdcf0f9f000) libm.so.6 => /lib64/libm.so.6 (0x00007fdcf0c9d000) libc.so.6 => /lib64/libc.so.6 (0x00007fdcf08db000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fdcf06c5000) liblttng-ust-tracepoint.so.0 => /lib64/liblttng-ust-tracepoint.so.0 (0x00007fdcf04ab000) liburcu-bp.so.1 => /lib64/liburcu-bp.so.1 (0x00007fdcf02a3000) liburcu-cds.so.1 => /lib64/liburcu-cds.so.1 (0x00007fdcf009c000) /lib64/ld-linux-x86-64.so.2 (0x00007fdcf578e000) libz.so.1 => /lib64/libz.so.1 (0x00007fdcefe86000) liburcu-common.so.1 => /lib64/liburcu-common.so.1 (0x00007fdcefc82000) [root@magna047 ~]# ceph -v ceph version 0.94.2 (5fb85614ca8f354284c713a2f9c610860720bbf3) [root@magna047 ~]# rpm -qa | grep rados librados2-0.94.2-8.el7cp.x86_64 python-rados-0.94.2-8.el7cp.x86_64 [root@magna047 ~]# rpm -qa | grep ceph ceph-0.94.2-8.el7cp.x86_64 ceph-osd-0.94.2-8.el7cp.x86_64 qemu-kvm-tools-rhev-1.5.3-60_ceph.el7.5.x86_64 qemu-img-rhev-1.5.3-60_ceph.el7.5.x86_64 mod_fastcgi-2.4.7-1.ceph.el7.x86_64 iozone-3.424-2_ceph.el7.x86_64 qemu-kvm-common-rhev-1.5.3-60_ceph.el7.5.x86_64 ceph-common-0.94.2-8.el7cp.x86_64 qemu-kvm-rhev-1.5.3-60_ceph.el7.5.x86_64 katello-ca-consumer-cephqe1.lab.eng.blr.redhat.com-1.0-1.noarch
Sorry Harish, we were incorrect, and apparently there is no "libatomic_ops.so.1" file on RHEL 7. It's a Fedora (F22+) thing. Boris is looking into another way to verify this BZ.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2015:2512
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2015:2066