On 15.02.2017 09:48, E.N. virgo wrote: >> I'm not sure if I follow. Supporting multiple C++ ABIs would make >> things more complicated for developers because they now have to figure >> out which ABI their project needs and if all the libraries they want to > > ^^^^^^^^^^^^^^^^^^^^^^^^ >> use are available with the right ABI. > > From the example in BZ1415512, all libraries are standard, the sources remain > the same regardless the compiler to be used. Alas, clang++ now needs to link > against the GCC ABI to successfully compile.
what actual problem is caused by that? > There are some cases when one needs to try different tools, for instance to > take advantage of the LLVM's instrumentation tools which IMHO constitute a > plus, not a pain. which clang instrumentation tool requires libc++abi? all the sanitizers i tried work just fine with libstdc++. last i checked, libc++ didn't even have an equivalent of _GLIBCXX_DEBUG, which is a pretty severe limitation and makes it useless for me. >> I really don't think we should move in this direction. > > Are there pointers elsewhere indicating the corner cases of introducing > another C++ ABI into Fedora? there are subtle corner cases breaking exception handling: https://whatofhow.wordpress.com/2016/03/01/libclibcabi-on-linux/ but hey, some people think that spending many hours debugging that sort of thing is fun, so taking that as an argument against packaging libc++abi would clearly go against the C++ philosophy. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
