julia_110{,-bin}: 1.10.4 -> 1.10.8

[NickCao]

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[NickCao]

@ofborg build julia_110 julia_110-bin

[thomasjm]

Hmm, I wanted to run the julia.withPackages tests but I ran into a problem in the check phase of julia-bin-1.10.7:

       > The global RNG seed was 0x93690267f30d697b4000d0323f78fd24.
       >
       > Error in testset LinearAlgebra/blas:
       > Test Failed at /nix/store/rglc4g306vagny8pdn7581kdxpi409aw-julia-bin-1.10.7/share/julia/stdlib/v1.10/LinearAlgebra/test/blas.jl:712
       >   Expression: BLAS.axpy!(α, a, copy(b)) ≈ α * a + b
       >    Evaluated: ComplexF64[1.9330187934128453 - 8.970730564994865im, -0.6963896877405945 + 0.8611170231579576im, -0.6963896877405945 + 0.8611170231579576im, -0.6963896877405945 + 0.8611170231579576im, -0.6963896877405945 + 0.8611170231579576im, -0.6963896877405945 + 0.8611170231579576im, -0.6963896877405945 + 0.8611170231579576im, -0.6963896877405945 + 0.8611170231579576im, -0.6963896877405945 + 0.8611170231579576im, -0.6963896877405945 + 0.8611170231579576im] ≈ ComplexF64[-0.4334488396252506 - 0.12206773565732487im, -0.4334488396252506 - 0.12206773565732487im, -0.4334488396252506 - 0.12206773565732487im, -0.4334488396252506 - 0.12206773565732487im, -0.4334488396252506 - 0.12206773565732487im, -0.4334488396252506 - 0.12206773565732487im, -0.4334488396252506 - 0.12206773565732487im, -0.4334488396252506 - 0.12206773565732487im, -0.4334488396252506 - 0.12206773565732487im, -0.4334488396252506 - 0.12206773565732487im]
       >
       > ERROR: LoadError: Test run finished with errors
       > in expression starting at /nix/store/rglc4g306vagny8pdn7581kdxpi409aw-julia-bin-1.10.7/share/julia/test/runtests.jl:95
       For full logs, run 'nix log /nix/store/4p2p3zckhzl05k32rr1pqih72br5qyji-julia-bin-1.10.7.drv'.

[NickCao]

Likely another openblas bug, I used to hit these on specific cpu models without avx, it went into a broken code path causing incorrect floating point calculations.

[thomasjm]

Gotcha. The julia-1.10.7 build took a bit longer but it also just crashed on the same test.

This is a 13th Gen Intel(R) Core(TM) i9-13900K.

[NickCao]

The upstream issue: OpenMathLib/OpenBLAS#4176

[thomasjm]

The thing is, my CPU flags include avx, so this makes me wonder if this is connected to another issue I saw recently--

I found that on my i9-13900K machine with NixOS, Julia was detecting the CPU microarchitecture incorrectly as "goldmont" when it should be Raptor Lake. This seems to be related to the LLVM used to compile Julia. So maybe there is some CPU detection problem going on. You can check this by running versioninfo() and looking at the LLVM: row, or looking at Sys.CPU_NAME. In fact, here are the versions I see currently:

attr	LLVM
julia_110	LLVM: libLLVM-15.0.7 (ORCJIT, goldmont)
julia_110-bin	LLVM: libLLVM-15.0.7 (ORCJIT, goldmont)
julia_111	LLVM: libLLVM-16.0.6 (ORCJIT, alderlake)
julia_111-bin	LLVM: libLLVM-16.0.6 (ORCJIT, alderlake)

Could the microarchitecture be getting baked in by whatever Hydra machine compiled LLVM, and then when my machine downloads that, it confuses the CPU version checks on my machine?

Julia's Sys.CPU_NAME field is ultimately derived from here:

https://github.com/JuliaLang/julia/blob/2590e675885b97579a7531c343a546f6f5bbcbe5/src/processor.cpp#L974-L977

[NickCao]

On my machine:

attr	LLVM
julia_110	libLLVM-15.0.7 (ORCJIT, znver3)
julia_110-bin	libLLVM-15.0.7 (ORCJIT, znver3)
julia_111	LLVM: libLLVM-16.0.6 (ORCJIT, znver4)
julia_111-bin	LLVM: libLLVM-16.0.6 (ORCJIT, znver4)

So that's not the case.

[thomasjm]

Hmm, but you might have built LLVM yourself rather than getting it from cache. Does your Sys.CPU_NAME show the same results? Your system can't be both znver3 and znver4...

[NickCao]

Hmm, but you might have built LLVM yourself rather than getting it from cache.

Nah, these are freshly fetched from the cache.

Does your Sys.CPU_NAME show the same results? Your system can't be both znver3 and znver4...

Same, I guess it's just the older llvm versions don't recognize znver4 yet thus falling back to znver3.

[thomasjm]

Makes sense, I can confirm that's the case by running nix run .#clang_15 -- --print-supported-cpus.

However, doing the same with .#clang_16 shows support for raptorlake. My machine is raptorlake, and yet Sys.CPU_NAME is showing alderlake. A bit weird but I'm satisfied about why I'm hitting this AVX bug on LLVM 15.x versions 👍

[MisileLab]

julia 1.10.8 released: https://github.com/JuliaLang/julia/blob/v1.10.8/NEWS.md

[NickCao]

The zlib related bug is still present on 1.10.8, we have to live with it.

[thomasjm]

I didn't know about this zlib issue. I can build 1.10.8 with your branch but I can't start it on my NixOS machine since it fails to find a system libz.so.1. How are we to live with this?

The old 1.10.4 on master works for me on NIxOS.

[thomasjm]

Could we patchelf libunwind to use the Nix-provided zlib?

[NickCao]

Let's attempt another solution: reverting the offending commit. I don't know why changes to the llvm build system would affect the build of libunwind, but it is what it is.....

[thomasjm]

Okay, that makes things much better:

• julia_110: 0 failures on top 500 packages (100% success)
• julia_110-bin: 0 failures on top 500 packages (100% success)

[thomasjm]

LGTM. Hopefully upstream will fix this zlib issue soon?

[NickCao]

LGTM. Hopefully upstream will fix this zlib issue soon?

I think it's half a nixpkgs issue, haven't got time to dig deeper, see JuliaLang/julia#55617 for prior discussions.