Add libjulia 1.4.2

[fingolfin]

No description provided.

[fingolfin]

Still a build issue on Darwin (and for Linux on 32bit arm, but I am willing to skip that). Will now compared with the results for libjulia@1.5 at https://dev.azure.com/JuliaPackaging/Yggdrasil/_build/results?buildId=5860&view=results to see if I can spot a hint

[fingolfin]

Regarding lapack, here is the core of the issue: on macOS, USE_SYSTEM_BLAS=1 means something slightly different; to quote Make.inc:

ifeq ($(USE_SYSTEM_BLAS), 1)
ifeq ($(OS), Darwin)
USE_BLAS64 := 0
USE_SYSTEM_LAPACK := 0
LIBBLAS := -L$(build_libdir) -lgfortblas
LIBBLASNAME := libgfortblas
else
LIBBLAS ?= -lblas
LIBBLASNAME ?= libblas
endif
else
LIBBLAS := -L$(build_shlibdir) -lopenblas
LIBBLASNAME := libopenblas
endif

So in particular, it expects a BLAS versions which does not contain LAPACK, which is why it tries to build it. This then leads to an issue because lapack 3.5.0 (the version used by Julia 1.4.2) insists on running a few testbinaries at the end of its build&install process; which of course doesn't work in a cross compiler. In lapack 3.9.0 (used in Julia 1.5) this has been abolished.

So there are several ways forward for dealing with the macOS issue

1. play a bit around with USE_SYSTEM_BLAS and other settings to see if we can convinced Julia to use the OpenBLAS we provided it anyhow
2. patch Julia's Make.inc so that USE_SYSTEM_BLAS uses OpenBLAS on macOS, too (since we really only are interested in the Julia headers and linking against libjulia.so/.dylib/.dll during build time the BLAS version really shouldn't matter
3. patch lapack 3.5.0 to just not run those test binaries (but that requires patching a file the Julia build process downloads, which is a bit awkward

I played with option 1 and it actually worked (I think Julia just download the OpenBLAS BinaryBuilder binaries itself -- a slight inefficiency, but I don't think it matters).

[fingolfin]

I removed this in an earlier attempt to get things working, but that made no difference... Now I wonder if this might break the Julia 1.5 build? Perhaps I should adjust this PR to also update libjulia 1.5, just to verify it still works right? (could also update it to 1.5.2 -- although there really isn't much of a point, as we only care about the headers and ABI, and want to use libjulia_jll only as a build dependency).

[fingolfin]

I am giving up on the ARM 32bit version for now. If somebody is interested in this, we can still add it later.

[fingolfin]

One last caveat: I've been (ab?)using the julia_version feature @staticfloat added some time ago, to help select the correct package versions. But I just realized that this seems (?) to affect the "platform string". So perhaps this is a bad idea and I should try again without it (I can always go back to this version if I can't do it without). Thoughts?

[fingolfin]

OK to merge into this?

[vchuravy]

Is this necessary?

[fingolfin]

Yes. Doesn't make a difference on Linux and fixes macOS

[vchuravy]

Then we should only do this for 1.4.2, since it did work for 1.5

[fingolfin]

Actually, I think this will even work with 1.5.x ?

But I've now changed it to restrict this change to macOS, where using USE_SYSTEM_BLAS=1 has the same issue as on 1.4.x: it does not use OpenBLAS, but rather the BLAS shipped with the OS by Apple, period. And that is missing lapack, so it then ends up downloading and building that (even in Julia 1.5); the only reason it works in 1.5 is that the lapack there is newer and more cross compilation friendly. But there is a download in any case. By not setting USE_SYSTEM_BLAS=1, we get Julia on macOS to use its own BLAS binaries, which works well even on macOS and with Julia 1.4 and 1.5 equally.

[fingolfin]

@vchuravy does that sound plausible / acceptable? I've applied a corresponding change to this PR now.

In any case, I think it would be useful to verify this PR doesn't break Julia 1.5.x builds. I could push a commit which edits the Julia 1.5 builder, to trigger a build of that, and then later drop that commit again once 1.5 builds (again). Alternatively, I could do that in a separate PR. Thoughts?