Question: Can rustc use llvm_latest instead of llvm9?

[doronbehar]

I'm hunting down usages of multiple versions of the same library in the packages that I use. So for example, a week ago or so, I discovered that frei0r, is built with opencv2 while the latest opencv4 is also supported. Unfortunately, this pattern is a bit common in Nixpkgs (Ahm Python) and the downside of it is that it can increase closure size if you have certain packages installed at the same time. For example, frei0r is a dependency of ffmpeg, and opencv4 is a dependency of some gst-plugins. This means that if you have them both installed, you get two different opencv derivations in your store but it doesn't have to be that way.

After reaching for feedback on discourse I learned that our policy regarding this should be to make libfoo point to the latest libfoo, and not to libfoo2 if there's e.g a libfoo3 available.

I've had a successful "sprint PR" for making opencv point to the latest version at #86808 and I tested that all of the dependent packages were still building with the newer opencv.

"Renaming" llvm to point to llvm_latest cannot be covered in a single PR like with opencv, so I'm hunting down packages 1 by 1. The biggest bite is for rustc:

nixpkgs/pkgs/development/compilers/rust/rustc.nix

Line 3 in 39b92f6

, llvm_9, darwin, cmake, rust, rustPlatform

I hope it's OK to ask here the maintainers - @madjar, @cstrahan, @globin, @Havvy : Is there a particular reason that you chose to use llvm_9 and not llvm_latest? It seems upstram doesn't have any constraint on that, according to: https://rustc-dev-guide.rust-lang.org/building/suggested.html#building-with-system-llvm

And, it seems that even @rust-lang's fork of llvm is also updated against the current latest llvm which is 10 according to: https://github.com/rust-lang/llvm-project/tree/rustc/10.0-2020-05-05

[Gaelan]

FWIW, upstream is currently using LLVM 9. Their PR to switch to 10 (rust-lang/rust#67759) was opened on Dec 31 and looks like it's getting close to merging now. That 4.5-month delay seems like a pretty good sign that immediately switching to new LLVMs is likely to cause regressions, so maybe best to wait?

It's worse on Darwin, by the way, where rustc alone requires LLVM 5 (see #87443), two copies of LLVM 7 (blame stdenv, see #87583), and LLVM 9.

[doronbehar]

so maybe best to wait?

Thanks for the quick reply :). rust-lang/rust#67759 is the answer to my question - it certainly won't worth the risk. I've subscribed to that issue and I hope I'll remember after it'll merge to make sure our rustc is using llvm_latest or llvm_10.

Thanks!