The way this issue has somehow become a multi-year drama-fest is everything bad about what LLVM has become: reviews.llvm.org/D28791
(small patch adding the usual crtbegin.o/crtend.o Linux bits to compiler-rt so they're avail w/o libgcc (!))… mastodon.social/@wdtz/10133858
Conversation
BSD license doesn't explain this culture, this attitude; FreeBSD is not this way at all (and some of those folks are cc'd on this, heh).
What ＊is＊ the purpose of LLVM "these days" anyway?
It's increasingly hard to reject the answer…
3
Replying to
Both people objecting to this are associated with NetBSD and one even explicitly turns it into a political issue where they argue against compatibility with GNU / FSF platforms. I've seen a lot of Clang and LLVM developers doing this with the Linux kernel and GNU userspace.
2
2
The whole thing is stupid because crtbegin.o/crtend.o _make no sense at all_ except for pulling in compiler machinery for wacky langs gcc supports (e.g. Java) or legacy C++ mechanisms (made obsolete by .eh_frame).
1
2
The ideal implementation of them both is empty .o files, or just not even trying to link them at all.
1
2
I've just noticed that they'll add mountains of ugly compatibility code and awful hacks required by the Windows platform, macOS or even a *BSD but when it comes to the Linux kernel or GNU ABIs it gets held back. People in the Linux kernel and GNU projects are as unreasonable too.
There are dozens of cases where compatibility is blocked based on developers on both sides being biased against supporting compatibility with the other project. Neither side will budge an inch over subjective issues where both claim the other side has the wrong approach to it.
1
Yes. In any case, if the compiler driver is going to request linking to them, it needs to provide them, because they're _purely junk the compiler wants_, not anything that belongs to the OS/ABI/libc/etc.
1