On Thu, 30 Nov 2017, Nathan Cutler wrote: > I thought we already agreed to drop Trusty in Mimic? I'm not sure we made any final decision, but I haven't seen anyone complain this time around, so I'd say let's do it! sage > On 11/30/2017 11:15 AM, kefu chai wrote: > > On Wed, Nov 15, 2017 at 2:47 PM, kefu chai <tchaikov@xxxxxxxxx> wrote: > > > 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. > > > > i just confirmed with the devtoolset maintainer offline, that the bits > > not included by > > the base libstdc++ will be statically linked into the binary. and i > > verified this behavior > > on centos7. but this is not true, when it comes to trusty. > > > > > > $ bin/rados > > bin/rados: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version > > `CXXABI_1.3.8' not found (required by bin/rados) > > bin/rados: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version > > `CXXABI_1.3.8' not found (required by > > /var/ceph/ceph-ubuntu-14.04-kefu/build/lib/librados.so.2) > > bin/rados: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version > > `GLIBCXX_3.4.21' not found (required by > > /var/ceph/ceph-ubuntu-14.04-kefu/build/lib/librados.so.2) > > bin/rados: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version > > `GLIBCXX_3.4.22' not found (required by > > /var/ceph/ceph-ubuntu-14.04-kefu/build/lib/librados.so.2) > > bin/rados: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version > > `CXXABI_1.3.8' not found (required by > > /var/ceph/ceph-ubuntu-14.04-kefu/build/lib/libradosstriper.so.1) > > bin/rados: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version > > `GLIBCXX_3.4.21' not found (required by > > /var/ceph/ceph-ubuntu-14.04-kefu/build/lib/libradosstriper.so.1) > > bin/rados: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version > > `GLIBCXX_3.4.22' not found (required by > > /var/ceph/ceph-ubuntu-14.04-kefu/build/lib/libradosstriper.so.1) > > bin/rados: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version > > `CXXABI_1.3.8' not found (required by > > /var/ceph/ceph-ubuntu-14.04-kefu/build/lib/libceph-common.so.0) > > bin/rados: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version > > `GLIBCXX_3.4.22' not found (required by > > /var/ceph/ceph-ubuntu-14.04-kefu/build/lib/libceph-common.so.0) > > bin/rados: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version > > `GLIBCXX_3.4.21' not found (required by > > /var/ceph/ceph-ubuntu-14.04-kefu/build/lib/libceph-common.so.0) > > bin/rados: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version > > `GLIBCXX_3.4.20' not found (required by > > /var/ceph/ceph-ubuntu-14.04-kefu/build/lib/libceph-common.so.0) > > > > so, an obvious solution is to use "-static-libstdc++"[1] on trusty, > > libceph-common is a good candidate for where the libstdc++ is > > included. or just drop the support of it. thoughts? > > > > --- > > [1] https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html > > > > -- > Nathan Cutler > Software Engineer Distributed Storage > SUSE LINUX, s.r.o. > Tel.: +420 284 084 037 > -- > 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 > > -- 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
