1. 5
  1. 7

    The fundamental problem here is the original sin of libc: it conflates two fundamentally different functions. On the one hand, it’s the userspace interface to the (Unix) operating system, on the other hand it’s the C standard library. It makes no sense for a single library to combine both functions, but that’s what was originally done for expediency and we’ll be stuck with it forever since it’s codified de jure in POSIX and de facto in Linux.

    1. 1

      The obvious alternative to how this could have turned out better was Windows making libc completely external to system APIs and thus up to the compiler vendor to provide one (or not). Of course, that gets you into new problems (do you static or dynamic link it? are you shipping libc with your application, as a redist, or assumed? what if you mix multiple libcs in an address space? mismatch libc’s malloc/free?)

    2. 3

      There’s a fundamentally different philosophy between LLVM and the GNU ecosystem. The GNU project is building an OS. LLVM is building a set of components. For example, in FreeBSD, we use LLVM’s libc++ but with libcxxrt as the foundation layer, rather than LLVM’s libc++abi. Libc++ can also use GNU’s libsupc++ (which is normally statically linked to libstdc++). Each of these components can be built separately with LLVM’s build system and a number of toolchains for other platforms take a similar mix-and-match approach. This is the kind of pattern that LLVM was always designed for and it goes even deeper: you can just grab the libraries for building a Clang AST without any LLVM IR generation, or just pull in the LLVM back end without most of the optimisers, or even (as a bunch of Apple frameworks do internally) just use the LLVM AST libraries without any of the real compiler / toolchain bits. All of these are supported use cases because the more people using bits of LLVM the more contributors LLVM will get.

      In contrast, it’s almost impossible to build GNU libstdc++ without building the G++ compiler as part of the same build invocation. Glibc is nominally more separate, because downstream consumers had a strong desire to update the toolchain independently of the libc, but the projects are still very tightly coupled. The expectation is that they’re used to build a GNU system (with coreutils, binutils, gcc, glibc, and so on). If they’re useful in other contexts, then that’s an added bonus, but the primary goal is to produce a complete Free Software system.

      1. 2

        Is it worth it to fix glibc (and other projects which support only GCC) to build with LLVM? Is it better to just replace them with alternatives already supporting LLVM? Is it best to use both GCC and LLVM, each for their respective supported projects?

        Why not replace projects which support only LLVM with alternatives already supporting GCC?

        My understanding — which could be wrong — is that the only reason LLVM exists is because Apple wish to restrict their users’ freedom. Why not stick with the project whose goal is to maximise user freedom?

        1. 1

          at what cost and when does the glibc + LLVM cost exceed the time & effort required to use a different libc

          Are there other C libraries that are ABI compatible with glibc? I thought the issue here is that if glibc can’t be built with Clang, then it becomes impossible to build a distribution that can run Steam (or substitute your choice of binary code) without GCC. From an LLVM point of view, that seems like a problem. What I’m not clear on from this post is whether the FSF is actively opposing efforts to make glibc usable with LLVM since they have an interest in promoting GCC.