Conversation

Replying to and
Google is far from controlling LLVM. They were contributing a comparable amount to GCC, binutils, etc. back when they still used it and before they'd decided to migrate to LLVM. The binutils replacements were a lot more focused on macOS and Windows before caring about Linux too.
2
Replying to and
The libc project fits into the overall ambitions of LLVM beyond Google. They're very open to incubating those projects and accepting substantial code drops from big companies. LLD and LLDB are pretty good examples. Originally, it wasn't clear LLD would do serious Linux support.
2
Replying to and
No, but as another example I could easily see them making a Java AOT / JIT compiler, Java standard library implementation, debugger, etc. I could see Google being the main sponsors of that work too. I could also see them maintaining the userspace portion of GPU drivers.
1
Or, as another example, I could see LLVM having a permissive licensed alternative to QEMU. A lot of the infrastructure for software emulation of architectures with hardware acceleration is already present. It's a much broader project than a compiler. It always was to some extent.
1
So, as an example, you can write a C binding generation tool (like rust-bindgen) using libclang. You can write a debugger with liblldb as a library. It can be proprietary, since it's permissively licensed. RMS essentially sparked the whole thing. All leads back to crippling GCC.
1
I pretty strongly disagree there. RMS is an asshole in his treatment of people and ineffective in Free Software strategy, but all the stuff you cited that LLVM is making is stuff that should not have been in GCC and should not be made.
1
1
Show replies