Hacker News Reader

Comment by overflyer | Hacker News Reader

I start taking LLVM serious when they give easy to follow documentation on how to compile LLVM completely GCC/binutils/gnu libc independent. I mean a single go to point with easy instructions.

You have to Google everything and then you find out about EXPLICIT_LIBGCC_OPT_IN and you read unofficial responses to issues that describe how to use libunwind and compilert to replace libgcc_s. But all that stuff is out of date fast and never works. Even Rene Rebe who developed T2 ranted about this in 2019 and he couldn't completely figure it out without doing a shitton of workarounds and patches. You need to be fucking Stallmann or Torvalds or whatever computer scientist genius themselves to achieve this. Or Google who did this for Android and Fuchsia. My point is it is rocket science at this point. Fucking make that straightforward already dear LLVM project.

View on HN

Regardless of whether you take LLVM seriously, it's a serious project in serious commercial use in many environments.

> Fucking make that straightforward already dear LLVM project.

Much of what you are asking for can be enabled by not-rocket-science changes to the driver. Give it a try.

The LLVM project is much more "bazaar" than other high profile Open Source projects, so I think you'd have a relatively easy time convincing folks to accept your changes provided they don't break existing tests.

It's "ok" along these axes, a bootstrap for gcc isn't all that straightforward either, the main difference being that if you've already done "apt install build-essential" or similar it just so happens that "it's done" - albeit entirely non-hermetically and the bounds of "it" is probably entirely unknown to the user. I had this discussion with a kernel engineer once who insisted gcc had almost no external dependencies, and he believed this for this reason.

The parts that make it only "ok" are largely cmake derived problems - yes there's sometimes incomplete docs and so on, but largely the confusing parts come from the multi-project split and cmake reconstitution. I'm particularly excited for a future when llvm-libc has made some more progress, at which point a very hermetic build will get quite a bit easier.

The thing is that if you're cross-building this is really the answer, cross building with the deeply intertwined gcc chains is an equally awful experience. I'll take a static clang tool build I can zip up and give to everyone (except nix, because they decided loader hell should only be played on max difficulty) over a fragile distro intertwined mess any day.

> I start taking LLVM serious when they give easy to follow documentation on how to compile LLVM completely GCC/binutils/gnu libc independent. I mean a single go to point with easy instructions.

That's a very niche use-cases. Most people don't care about being "completely GCC/binutils/gnu libc independent".

It's fine to care about your niche use case, but to claim a project is not "serious" because this one thing isn't supported is ridiculous.

> Most people don't care about being "completely GCC/binutils/gnu libc independent

Then what is the point of llvm ?

Is this another "make" ("we don't use make for our project but use cmake to generate makefiles and make to build") ?

https://github.com/dzbarsky/static-clang should let you build it in a reproducible way with a single command.

compiling on mac is very easy/fluent experience for me. I guess OSX is still kinda first-class citizen for LLVM so maybe it does not count?

macOS LLVM is a bit of a special distribution. It's nice that there's a mostly well built LLVM distribution there, but the pain in the ass is that they ship a custom linker and _don't ship lld_, which means you can't readily use their distribution for a lot of common cross build targets - you need to go build at least an lld to get over the line.

Reply on news.ycombinator.com