Earlier this week, Siva Chandra, Google LLVM contributor asked all LLVM developers on their opinion about starting a libc in LLVM. He mentioned a list of high-level goals and guiding principles, that they are intending to pursue. Three days ago, Rich Felker the creator of musl libc, made his thoughts about libc very clear by saying that “this is a very bad idea.”
In his post, Chandra has said that he believes that a libc in LLVM will be beneficial and usable for the broader LLVM community, and may serve as a starting point for others in the community to flesh out an increasingly complete set of libc functionality.
Read More: Introducing LLVM Intermediate Representation
One of the goals, mentioned by Chandra, states that the libc project would mesh with the “as a library” philosophy of the LLVM and would help in making the “the C Standard Library” more flexible. Another goal for libc states that it will support both static non-PIE and static-PIE linking. This means enabling the C runtime and the PIE loader for static non-PIE and static-PIE linked executables.
Rich Felker posted his thoughts on the libc in LLVM as follows:
- Writing and maintaining a correct, compatible, high-quality libc is a monumental task. Though the amount of code needed is not that large, but “the subtleties of how it behaves and the difficulties of implementing various interfaces that have no capacity to fail or report failure, and the astronomical “compatibility surface” of interfacing with all C and C++ software ever written as well as a large amount of software written in other languages whose runtimes “pass through” the behavior of libc to the applications they host,”. Felkar believes that this will make libc not even of decent quality.
- A corporate-led project is not answerable to the community, and hence they will leave whatever bugs it introduces, for the sake of compatibility with their own software, rather than fixing them. This is the main reason that Felkar thinks that if at all, a libc is created, it should not be a Google project.
- Lastly Felkar states that avoiding monoculture preserves the motivation for consensus-based standard processes rather than single-party control. This will prove to be a motivation for people writing software, so they will write it according to proper standards, rather than according to a particular implementation.
Many users agree with Rich Felkar’s views.
A user on Hacker News states that “This speaks volumes very clearly. This highlights an immense hazard. Enterprise scale companies contributing to open-source is a fantastic thing, but enterprise scale companies thrusting their own proprietary libraries onto the open-source world is not. I’m already actively avoiding becoming beholden to Google in my work as it is already, let alone in the world where important software uses a libc written by Google. If you’re not concerned by this, refer to the immense power that Google already wields over the extremely ubiquitous web-standards through the market dominance that Chrome has.”
Another user says that, “In the beginning of Google’s letter they let us understand they are going to create a simplified version for their own needs. It does mean they don’t care about compatibility and bugs, if it doesn’t affect their software. That’s not how this kind of libraries should be implemented.”
Another comment reads, “If Google wants their own libc that’s their business. But LLVM should not be part of their “manifest destiny”. The corporatization of OSS is a scary prospect, and should be called out loud and clear like this every time it’s attempted”
While there are few others who think that Siva Chandra’s idea of a libc in LLVM might be a good thing.
A user on Hacker News comments that “That is a good point, but I’m in no way disputing that Google could do a great job of creating their own libc. I would never be foolish enough to challenge the merit of Google’s engineers, the proof of this is clear in the tasting of the pudding that is Google’s software. My concerns lie in the open-source community becoming further beholden to Google, or even worse with Google dictating the direction of development on what could become a cornerstone of the architecture of many critical pieces of software.”
For more details, head over to Rich Felkar’s pipermail.
