On Tue, Nov 14, 2017 at 5:49 AM, kefu chai <tchaikov@xxxxxxxxx> wrote: > On Mon, Nov 13, 2017 at 5:29 PM, kefu chai <tchaikov@xxxxxxxxx> wrote: >> On Sat, Nov 11, 2017 at 1:47 AM, Sage Weil <sweil@xxxxxxxxxx> wrote: >>> We noticed a big performance regression when switching some code to >>> use list::size() because although C++11 promizes that it is O(1), some of >>> the libstdc++'s out there are still O(n). This PR aims to fix that >>> >>> https://github.com/ceph/ceph/pull/18863 >>> >>> by adding the various devtoolset packages as dependencies to pull in >>> updated build toolchains. For el7 that's devtoolset-7-{binutils,gcc-c++}. >>> > > when running the binaries built using GCC 5.1 in an env where an old > libstdc++ (typically comes with GCC 4.8): > > $ rados > rados: relocation error: /usr/lib/ceph/libceph-common.so.0: symbol > _ZTINSt8ios_base7failureB5cxx11E, version GLIBCXX_3.4.21 not defined > in file libstdc++.so.6 with link time reference > > because libstdc++ introduced a new ABI which is incompatible with the old one. > see https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html > and https://developers.redhat.com/blog/2015/02/05/gcc5-and-the-c11-abi/ . > > in other words, we need to either 1) link statically with libstdc++.so or > 2) include it in librados2 on distros with GCC version less than 5.1. because > ceph-osd (and other daemons packages) => ceph-base => ceph-common => > python-rados => librados2. For 1), what does that imply for packages' debuginfo sizes? For 2), where would libstdc++.so ship in the filesystem? What does that mean for other applications that would load libstdc++.so and also link with ceph? - Ken -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
