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. 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? 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
