Fix build from source on alpine linux

[tkelman]

carrying patches from:

• llvm-mirror/llvm@ae8900a
• llvm-mirror/llvm@32028c8
• Rework __GLIBC_PREREQ checks to avoid breaking non-glibc builds OpenMathLib/OpenBLAS#1257

[quinnj]

Nice. do you have docker images somewhere based on alpine working?

[ararslan]

If there's an appropriate Docker image available we should be able to add Alpine to our CI testing on CircleCI, which would arguably be more valuable than having redundant glibc Linux builds.

[tkelman]

Something like https://github.com/tkelman/julia-alpine/blob/master/Dockerfile seems to be working so far. Can collapse that down, do a make install and remove build-only deps once it's done if you want a small image for deployment purposes.

[ararslan]

Good to merge?

[JeffBezanson]

Cool. Is there a released version of llvm/openblas including these changes, that we're likely to upgrade to?

[tkelman]

See the makefile comments - llvm 6.0.0 will include llvm-mirror/llvm@ae8900a, llvm 5.0.0 should already include llvm-mirror/llvm@32028c8, openblas 0.2.21 was supposed to be a hotfix that already included OpenMathLib/OpenBLAS#1257 (and worth noting that upstream tests against alpine on their dev branch CI now) but ref OpenMathLib/OpenBLAS#1258, xianyi is kinda MIA and no one knows what the exact release plan is there.

I'm also somewhat curious whether this also works on a non-edge release of alpine but haven't tested that yet.

[ViralBShah]

Yes the OpenBLAS release schedule is unclear. I believe we need another matvec perf fix that @simonbyrne reported too - but digressing here. Do we need to run Package Evaluator on this, since these are LLVM patches that are late in the release cycle?

[tkelman]

The large patch should be an llvm-internal enum renaming rather than externally visible, but maybe clang or llvm.jl are worth testing to be sure this doesn't cause any problems there. It's also entirely possible that I missed something or made a mistake when rebasing those, so might also be good to verify it's not noticeable on nanosoldier if that's working properly right now

[ararslan]

cc @maleadt for LLVM.jl

@nanosoldier runbenchmarks(ALL, vs=":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan

[maleadt]

Works fine with (what's currently covered by) LLVM.jl.

[ViralBShah]

Seems like there is quite a bit of regression on some of the perf tests. Should we wait to see how the llvm 6 stuff pans out and then do what's necessary? I suspect we could do the openblas stuff right away.

[KristofferC]

I am quite sure none of those "regressions" are from this PR. They are very spread and most of the groups with regressions also have improvements, just showing that they are noisy.

@nanosoldier runbenchmarks(ALL, vs=":master")

[ararslan]

@nanosoldier runbenchmarks(ALL, vs=":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan

[ararslan]

Bump. Anything else needed here?

[ViralBShah]

Should we wait to see the situation on llvm 6 before deciding here?

[tkelman]

Why? LLVM 6 almost certainly will break more than this would.

[vchuravy]

LGTM

[KristofferC]

Rerunning CI because it was 9 days ago last time.

[ararslan]

Needs a rebase now but should be good to go after that.

[vchuravy]

Patch: llvm-D28476-musl-targetlibraryinfo_3.9 breaks compilation with BUILD_LLVM_CLANG=1

/home/vchuravy/src/julia/deps/srccache/llvm-3.9.1/tools/clang/lib/CodeGen/BackendUtil.cpp:256:14: error: ‘Func’ is not a member of ‘llvm::LibFunc’
     LibFunc::Func F;
              ^~~~
/home/vchuravy/src/julia/deps/srccache/llvm-3.9.1/tools/clang/lib/CodeGen/BackendUtil.cpp:258:38: error: ‘F’ was not declared in this scope
       if (TLII->getLibFunc(FuncName, F))