On 15/02/17 10:21 -0000, E.N. virgo wrote:
Alas, clang++ now needs to link against the GCC ABI to successfully compile.
what actual problem is caused by that?
Please read instead “Alas, clang++ currently needs to link against the GCC ABI to successfully compile.”
The problem is that one might want to use libstdc++ (GCC) and libc++ (LLVM) along with GCC ABI and LLVM ABI, respectively. Fedora currently enables the GCC case, but one has to fall back to GCC ABI even when using an LLVM library.
So what? Why is that a problem?
Does the libc++abi have better performance for exception handling?
Smaller footprint for RTTI?
More new features, such as C++17's std::uncaight_exceptions()?
Just because there's a different low-level C++ runtime library
available doesn't mean that using it makes sense. Fedora is built with
GCC and libstdc++, so swapping those pieces out has potentially large
consequences.
You might think I'm biased as I'm a libstdc++ maintainer, but I'd say
the same thing if somebody was asking about replacing libcxxabi on Mac
OS with libsupc++, or replacing libcxxrt on FreeBSD with libsupc++:
don't do it unless you really know what you're doing, and can isolate
it completely from the rest of the OS.
Quoting from https://www.usenix.org/legacy/publications/library/proceedings/bos94/full_papers/adams.a
| One final anecdote regarding the earlier story
| where someone used an int reference parameter. In
| discussing this paper, the programmer's comment was
| - "Well, the feature was in the language so I figured I
| should use it.". It is our belief that this is not a
| sufficient criteria for using a feature of C++. A feature
| should be used only when it can be demonstrated to be
| of benefit. A mountain is climbed "because it is there".
| The same should not hold true for C++ features. Their
| mere existence is not justification for use.
which clang instrumentation tool requires libc++abi?
Not an instrumentation in particular, I ran into problems when trying to LD_PRELOAD some instrumented binaries and founding they needed libc++abi.
Then they were built on a different distro from Fedora?
That's always going to be unsupported to some degree.
there are subtle corner cases breaking exception handling:
https://whatofhow.wordpress.com/2016/03/01/libclibcabi-on-linux/
Blog post amended in the comments.
Overall, I am not willing to argue about C++ best coding/debugging practices. I am rather asking if there is any possibility that package review request (BZ1332306) stalled for ages would get some care. Had I been a packager, sure I would try to handle the review process myself, but I am not a packager. It would be nice to have some contributor giving the libc++abi package some time, I am quite sure there are many people who will be very grateful.
If adding the package makes it easier for people to create
incompatible builds for Fedora that don't play nicely with the rest of
the OS I don't think it's a good idea.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
