On Wed, Jan 3, 2018 at 10:53 PM, kefu chai <tchaikov@xxxxxxxxx> wrote: > On Wed, Jan 3, 2018 at 1:31 AM, Sage Weil <sweil@xxxxxxxxxx> wrote: >> On Tue, 2 Jan 2018, kefu chai wrote: >>> On Tue, Jan 2, 2018 at 11:28 PM, Ken Dreyer <kdreyer@xxxxxxxxxx> wrote: >>> > On Tue, Dec 26, 2017 at 4:24 AM, kefu chai <tchaikov@xxxxxxxxx> wrote: >>> >> right. unless we swing our own homebrew gcc-7. >>> > >>> > Can we ask the devtoolset maintainers to change this option? >>> > >>> > I imagine they would be interested in this type of feedback from the field. >>> >>> https://git.centos.org/blob/rpms!devtoolset-7-gcc.git/2e5ef6c7934d4417e095855478736742b35bd0af/SPECS!gcc.spec#L1026 >> >> For reference, >> >> ``` >> # Force the old ABI unconditionally, the new one does not work in the >> # libstdc++_nonshared.a model against RHEL 6/7 libstdc++.so.6. >> sed -i -e 's/\(define[[:blank:]]*_GLIBCXX_USE_DUAL_ABI[[:blank:]]*\)1/\10/' $f >> ``` >> >>> I think we need to think about this before sending any inquiries to them. >> >> The problem I see is that it is impossible to write/build many native >> C++11 (or 14 or 17) apps with the toolchain since the old ABI precludes >> O(1) std::list. > > i sort of agree with you. but i think we can still use C++11 (and > probably 14 or 17) > with the old ABI. see > https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html > > <quote> > the choice of ABI to use is independent of the -std option used to > compile your code > </quote> > > in other words, if we rely on the O(1) std::list and copy-on-write > string, then, yes, > we cannot write/build apps using this toolchain. > >> >> If I'm following the _nonshared thing, it's a feature that lets you build >> with teh new toolchain but deploy on systems with much older libstdc++ >> installed (new symbols are statically instead of dynamically linked). >> Is the problem with the "dual ABI" feature? > > i think so. also by inspecting > https://git.centos.org/blob/rpms!devtoolset-7-gcc.git/c7/SOURCES!gcc7-libstdc++-compat.patch, > libstdc++_nonshared.a includes lots of C++98 and C++11 symbols. in the > case of list::size(), it is completely implemented in the header file. > but probably there are also some pieces of libstdc++ implemented in > the source files. in that case, it would be difficult to include both > ABIs a class, std::basic_string<> for example, in the same .a file. > because they are conditionalized by the "_GLIBCXX_USE_CXX11_ABI" macro > at build time. and they are both in the namespace of std::__cxx11 > namespace. > > will drop a mail to SCLs asking for more info on this. they tried to make it work. <quote> The problem is that in the system lib*.so.* + *_nonshared.a model, if some symbol is exported from the system shared library, we must use that, can't override that, and the dual ABI support requires several of the system shared library symbols to behave differently (e.g. for locale facets, need to register twice as many, one set for old ABI, another for new ABI). </quote> so, we need to live with the O(n) std::list::size(), and non copy-on-write basic_string<> on centos. -- 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
