When can glibc be built with Clang? | Hacker News Reader

When can glibc be built with Clang?

maskray.me

100 pointszdw28 comments

Glibc has always been a whole rigamarole of nasty GCC-isms. I've been interested in building entire GNU/Linux systems with Clang for years, but I have always found a general lack of interest from both maintainers and the community.

It's nice to see that finally something is moving, especially now that Linux is also finally buildable with LLVM.

A lot of the GNU tools have had dependencies on GNU-specific versions of classic tools because, for decades, the non-GNU versions sucked. Lots of hard-coded arbitrary limits (line lengths, file sizes, command line option counts), quadratic behaviours, crashes, weird corner cases.

Edit - also, lack of updates. POSIX added a new feature to a tool 5 years ago? Well, the built-in tool that came with your classic Unix probably still doesn't support it yet. The GNU tool does though.

If your build system effectively relies on GNU `make` because 75% of the other `make` implementations out there either barf on your makefile, or don't run the build steps correctly, despite it being valid according to the spec; and GNU `make` has a bunch of features that are really powerful and would allow you do some complex things more easily, or even do them at all; then why not just actually rely on GNU `make` and use the extensions?

Similarly, the bundled `cc`s with classic Unices (if they were provided at all) frequently had weird bugs or poor code generation that would go unfixed for years. If `gcc` was the only compiler you could rely on a) your users having access to, and b) to correctly compile your code; and it has a bunch of really cool features that make your code smaller or faster or cleaner, it's hard to resist that. Your code is still portable, because `gcc` is portable, and Free.

> Similarly, the bundled `cc`s with classic Unices (if they were provided at all

It has been a generation since it was common for people to pay for Unix, and then pay more for shitty developer tools.

That gcc has gone from savior to legacy in that time is a huge testament to the value the open source world has created. But I think people forget the bad old days pretty quickly.

HP-UX, Aix, Solaris and mainframes POSIX environments are still around.

Additionally, embedded also has plenty of POSIX like OSes that arent' Linux based.

AIX is doing a lot better than HP-UX and Solaris are. In relative terms.

> That gcc has gone from savior to legacy in that time is a huge testament to the value the open source world has created

I hope GNU can turn itself around, but because having n+1 competing FOSS implementations is a huge boost. I just fear it is not a sustainable situation.

libgccjit and the new rust backend is a good sign.

That's exactly an illustration that a few competitors is unhealthy for the ecosystem, and llvm isn't going to evolve as fast as it did.

If LLVM vanquishes GCC, you mean?

The thing is, you didn’t pay more for shitty developer tools. You paid more for good tools. The system compiler existed solely to enable kernel rebuilds prior to the advent of loadable kernel modules on most vendor UNIX platforms.

Sad to say there are still tons of those ancient systems in production use.

I looked and didn't see any answer to... is there a difference in performance of the gcc vs llvm compiled kernel?

They're different compilers so I assume the answer would be yes.

If it isn't possible to build currently I expect minimal clarifying changes wouldn't have much impact on runtime performance (where it compiled previously), but as mentioned in another post would lower the risk of bugs and maintenance burden with clearer code.

Portability, validation, across multiple platforms is one way of exposing bugs and weaknesses in logical description.

> They're different compilers so I assume the answer would be yes.

They have highly similar designs (at least in the middle-end which is the important part), or did, but gcc's remaining large customers care most about optimizations so it's still somewhat ahead there.

Those are not necessarily comprehensive benchmarks, but it seems clang is doing very well in many workloads:

https://www.phoronix.com/scan.php?page=article&item=clang-lt...

GCC with max optimization still generally produces faster binaries than clang, but clang is constantly improving and in a few years they will probably be very similar.

Is that still true though? It was definitely the case some 5-10 years ago, but last time I checked they were pretty comparable, losing some, winning others.

clang wins on some benchmarks, but gcc wins on over 50% of benchmarks, at least this always seems to be the case whenever I look it up.

If I were writing a program that needed to be really fast I would just compile with both on max optimizations and pick whichever was best. Most software isn't the linux kernel and will work fine with both compilers

These benchmarks also don't reflect how good are the backends for different CPU architectures in GCC and LLVM.

For instance, GCC is by far the dominant compiler on GNU/Linux on x86, while LLVM has a almost total monopoly of AArch64 (think about Android NDK + iOS + macOS). I think it would be quite natural for the GCC AArch64 backend to get less focus compared to its x86 counterpart. It's a complicated landscape that is always full of gotchas, and that's why I don't like these kinds of benchmarks a lot.

source? llvm 13?

It's still true. Basically it's even as makes no difference except for ones where GCC is still way ahead. Real world code has to be measured for each to decide.

The key takeaway is that GCC is still an extremely good compiler.

That's why they said since 5 years. My experience was that clang seems longer compiling but due to the fact i did not compiled the same program with clang and gcc i would not take it as a rule.

I was referring to performance of the compiled program, not the time it takes to compile it.

A lot of people who use terms like “GNU/Linux” see the spread of GNU-isms in code as a way to preach their gospel and entrench their politics in codebases. Fortunately the LLVM ecosystem implemented a lot of those, so they couldn’t be used as an excuse not to use LLVM-based tools.

These types of cleanups are great for identifying confusing code (the first example is a perfect one where the compiler can figure it out but the maintainer may not realize what's being done).

Zig builds its own copy of glibc with clang on a whole bunch of architectures: https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

Are you sure about that?

> And finally, we certainly do not ship the build system of glibc with Zig! I manually inspected, audited, and analyzed glibc's build system, and then by hand wrote code in the Zig compiler which hooks into Zig's caching system and performs a minimal build of only these start files, as needed.

It sounds to me like they build glibc using its own build system, but they use Zig to build the statically-linked glue code necessary to dynamically link to a system glibc. This allows cross-compiling to a glibc target without having glibc installed locally. Certainly very impressive.

You’re right - Many thanks for the clarification.

https://www.canglibcbebuiltwithclangyet.com/ anyone?

Reply on news.ycombinator.com