LLVM 14.0.2 Released With The Compiler Moving To Bi-Weekly Releases

[brad0]

14.0.3 is now also released!

Just fixing the minor version forgetting to be bumped in a few spots resulting in wrong version in some directory paths.

[discordian]

Yeah, I know, Ubuntu Jammy has llvm-11, llvm-12, llvm-13, and llvm-14 packages all available

My impression is the Arch packagers don't think that's a clean approach. And I agree with them.

There are very few libraries with perfect forward compatibility, much less those of LLVM's immense size, I would trust only libc, libstdc++ for that, and even there are incompatible jumps (libc5 -> libc6) and breaking bugs now and then. Not having a contingency plan for that is not a matter of opinion, but a lack of foresight.

[oibaf]

14.0.3 is now also released!

[sp00nz]

You can have multiple llvm versions installed concurrently, i typically have some older stable libs which are used for GPU drivers an mostly everything, and a new(ish) version for development.

Yeah, I know, Ubuntu Jammy has llvm-11, llvm-12, llvm-13, and llvm-14 packages all available

My impression is the Arch packagers don't think that's a clean approach. And I agree with them.

[discordian]

Not just that, but the C++ API isn't stable between LLVM versions. So all of those packages that depend on LLVM potentially need to be updated for the latest version. And sometimes those updates aren't trivial.

You can have multiple llvm versions installed concurrently, i typically have some older stable libs which are used for GPU drivers an mostly everything, and a new(ish) version for development.

[sp00nz]

I think the solution is to provide multiple versions, like Qt5 and Qt6.

I'm not sure it's quite the same thing. There are applications that simply cannot be upgraded to Qt6 because Qt6 is missing functionality that exists in Qt5. For LLVM, they literally change the API every 6 months and it can be a lot of work (a lot of hard work) to fix the application.

Shipping multiple LLVM versions seems highly undesirable and a latch ditch effort sort of thing. But Arch apparently caved and is shipping an llvm11 since I guess wasmer still hasn't updated their LLVM usage.

[scottishduck]

Great to see the change allowing for timely bug fixes. As for toolchain maintenance, gentoo continues to lead the way…

[Grinch]

OpenBSD 7.1 shipped with 13.0 LLVM then?

LLVM 13.0 was massively delayed, probably because of them fixing the most critical bugs before releasing it.

BTW, hasn't there been any benchmark between Clang/LLVM 14 and Clang/LLVM 13 yet ? I had a look around Phoronix and couldn't find one.

[babali]

VCPKG also takes a lot of time to update.
I think the solution is to provide multiple versions, like Qt5 and Qt6.

[kylew77]

I don't think you can blame the Arch maintainer in this case. A lot of important packages rely on LLVM at this point, and the initial major version Clang/LLVM release is pretty much always riddled with bugs, so you don't want to expose the user to those.

The fact that we've already had two bugfix point releases for LLVM a just month after release of version 14 is quite telling of how many bugs there were (which of course is the reason for this switch to a new release schedule). Hopefully LLVM 14.0.2 fixes enough of them so that Arch can upgrade.

If the first release of each LLVM branch is so buggy then how come OSes like OpenBSD 7.1 shipped with 13.0 LLVM then? Do they modify it enough that they fix most of the bugs? Why not ship with say 13.0.1? Genuinely curious?