On Wed, Nov 15, 2017 at 6:04 AM, Ken Dreyer <kdreyer@xxxxxxxxxx> wrote: > 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? since we don't compile the source of libstdc++, i don't think this will increase the size of debuginfo. > > 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? if we just statically link libceph-common against libstdc++, and let daemons link againt libceph-common, the problem will be solved. that's actually 2) but after a second thought, i think it's a better approach. please note, the daemons are linked against libceph-common statically. [OT] we could let daemon link libceph-common dynamically, but the downside is that the daemon will need to depend on a client side library: librados2. which is a little bit weird. but the upside is: this will shrink the size of debug-info and the size of daemons, as the daemon will not include ceph-common statically. -- Regards Kefu Chai -- 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
