Change:
enableParallelBuilding = true; <ins> # Julia's tests require read/write access to $HOME preCheck = '' export HOME="$NIX_BUILD_TOP" ''; doCheck = true; checkTarget = "test"; </ins> postInstall = '' # Symlink shared libraries from LD_LIBRARY_PATH into lib/julia, # as using a wrapper with LD_LIBRARY_PATH causes segmentation

Discussion:
Describe the bug The julia15 derivation does not pass the official julia test suite, including a number of BLAS errors where numerical results are incorrect. This bug report is a followup to and in particular To Reproduce This bug seems to only manifest on certain hardware configurations. All of the results I'm presenting were run on an AWS c5.2xlarge instance running NixOS 20.09.3301. (Nightingale). Steps to reproduce the behavior: in the nixpkgs repository. test failures. Expected behavior The test suite to pass. Screenshots n/a Additional context We know that the patched official binaries from julia upstream do not have the same test failures, so this appears to be an issue with nixpkgs version of or that the julia-custom BLAS patches are relevant and that we should be using their vendored blas in the build process. As I proposed in , I think we should add the test suite to run in the derivation and then either mark it as broken or find a fix. Of course we can mark as broken and then always find a fix later and update it. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- other interested parties: Metadata Please run and paste the result. Maintainer information:
See also for a sense of what these errors look like.
After poking around at this for a few hours I am truly stumped. I began with the assumption that was to blame. So I proceeded by letting julia vendor in its own version of BLAS, and dropping the dependency on the nixpkgs . That didn't work, so I proceeded to one-by-one vendor in each dependency that has anything to do with numerics: blas, lapack, openlibm, mpfr, fftw, fftwSinglePrec, openspecfun. That leaves only libunwind, readline, utf8proc, zlib, curl, libgit2, and pcre2 as non-vendored dependencies. And yet still it fails the tests... Here's what I ended up with for anyone who's curious: So I think we just mark as broken and move on with our lives. has a sick 1.6 derivation that does pass all the tests anyhow so people ought to just use that instead.

If anyone has any other ideas, do let me know! I'd be really curious to get to the bottom of this.
Odd, not seeing anything obvious apart from encouraging you to use rather than as the former usually gets rid of a few spurious failures. If you do have a log I could have a look, although just like you I am inclined to think that we are better off leaving marked as broken and moving to correct the state of things with a “clean” expression. If you are truly dedicated to get to the bottom of this, you could hypothetically grab my Julia fork [1] and apply my BinaryBuilder patch on to to see if you can build the whole thing from source. Just beware that if you run you are likely to get at least some failures for and friends depending on your network setup, but I guess we are mainly interested in the linear algebra portions anyway. [1]: