On Tue, Nov 14, 2017 at 8:58 PM, Haomai Wang <haomai@xxxxxxxx> wrote: > > Haomai Wang <haomai@xxxxxxxx>于2017年11月14日 周二20:57写道： >> >> >> kefu chai <tchaikov@xxxxxxxxx>于2017年11月14日 周二20:51写道： >>> >>> 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. >>> >>> i think the 2) approach is better. what do you think? >> >> >> Do we consider to keep it? I checked the usage of std::c++ > > list > >> , most is ok. Large list only used by pglog which is newly introdeced >> i guess by "keep it", what you mean is to keep using whatever the toolchain comes with the distro. yeah, we *can* live with it. but a standard conforming C++ implementation can save us more time in long term. it took me at least 1 whole day in total to understand that 1) the std::regex in GCC 4.8 is incomplete and buggy 2) list::size() in GCC 4.8 is O(n). the list will be growing over the time. i am sure. >>> >>> >>> >> I'm not sure what the requirement for deb-based distros is. >>> >> ubuntu-toolchain-r? >>> > >>> > for ubuntu trusty, yes. for old stable (jessie) of debian, not sure if >>> > "apt-get -t experimental" works or not. >>> > >>> >> >>> >> My preference would to move our build requirements forward so that you >>> >> have to have a modern libstdc++ in order to build, allowing us to make >>> >> C++11-ish assumptions (like an O(1) list::size()). >>> >> >>> >> 1) Is this needed for xenial, or just trusty? >>> > >>> > it's just trusty. xenial comes with gcc 5.3.1, see >>> > >>> > https://packages.ubuntu.com/search?keywords=gcc&searchon=names&suite=xenial§ion=all. >>> > >>> >> >>> >> 2) If only trusty, should we do something weird here to keep >>> >> buliding for it post-luminous, or can we (finally!) drop the trusty >>> >> builds? >>> > >>> > i'd vote for dropping it. but if we need to stick with trusty, here >>> > comes the weird thing: https://github.com/ceph/ceph-build/pull/914 =) >>> > >>> >> >>> >> sage >>> >> -- >>> >> 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 >>> > >>> > >>> > >>> > -- >>> > Regards >>> > Kefu Chai >>> >>> >>> >>> -- >>> 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 -- 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
