[libflame] Initial build scripts.

[jd-foster]

Build scripts for libflame

Addresses #7660

Currently MacOS is omitted until linking errors can be resolved cf. flame/libflame#100

[imciner2]

Why is it split into a build_tarballs and a common? This looks simple enough we should just keep it all in a single build_tarballs to make updating the recipe simple.

[jd-foster]

Yes, that also occurred to me after the initial commit. Will reduce to a single build_tarball

[jd-foster]

So clearly libflame.1.dll !== libflame-1.dll !== libflame.dll ...

[ Info: Checking lib/libflame.1.dll with RPath list String[]
[ Info: Ignored system libraries msvcrt.dll, KERNEL32.dll
┌ Warning: lib/libflame.1.dll should be in `bin`!
└ @ BinaryBuilder.Auditor /cache/julia-buildkite-plugin/depots/e2fd9734-29d8-45cd-b0eb-59f7104f3131/packages/BinaryBuilder/L8tBh/src/Auditor.jl:233
┌ Warning: Simple buildsystem detected; Moving all `.dll` files to `bin`!
└ @ BinaryBuilder.Auditor /cache/julia-buildkite-plugin/depots/e2fd9734-29d8-45cd-b0eb-59f7104f3131/packages/BinaryBuilder/L8tBh/src/Auditor.jl:244
[ Info: Normalising timestamps in import library /cache/build/yggy-amdci7-15/julialang/yggdrasil/L/libflame/build/x86_64-w64-mingw32/NiP3KxjS/x86_64-w64-mingw32-libgfortran5-cxx11/destdir/lib/libflame.dll.a
[ Info: Checking license file
[ Info: Found license file(s): LICENSE
[ Info: Found a valid dl path libatomic-1.dll while looking for libflame
[ Info: Found a valid dl path libblastrampoline-5.dll while looking for libflame
[ Info: Found a valid dl path libflame.1.dll while looking for libflame
[ Info: Found a valid dl path libgcc_s_seh-1.dll while looking for libflame
[ Info: Found a valid dl path libgfortran-5.dll while looking for libflame
[ Info: Found a valid dl path libgomp-1.dll while looking for libflame
[ Info: Found a valid dl path libquadmath-0.dll while looking for libflame
[ Info: Found a valid dl path libssp-0.dll while looking for libflame
[ Info: Found a valid dl path libstdc++-6.dll while looking for libflame
[ Info: Found a valid dl path libwinpthread-1.dll while looking for libflame
[ Info: Could not locate libflame inside ["/cache/build/yggy-amdci7-15/julialang/yggdrasil/L/libflame/build/x86_64-w64-mingw32/NiP3KxjS/x86_64-w64-mingw32-libgfortran5-cxx11/destdir/bin"]
┌ Error: Built libflame but libflame still unsatisfied:
└ @ BinaryBuilder /cache/julia-buildkite-plugin/depots/e2fd9734-29d8-45cd-b0eb-59f7104f3131/packages/BinaryBuilder/L8tBh/src/AutoBuild.jl:946
ERROR: LoadError: Cannot continue with unsatisfied build products!

[jd-foster]

Note: now that it's working on mingw32, we should see if it's possible to upstream the configure script patches, which are based on the newer BLIS scripts anyway.

[imciner2]

I see that it is currently building the static library. In general, we do like to avoid having those in the main JLLs because they can really eat up space (the artifact here shows it is 15MB on Linux). Can we disable the static library build?

Also, are we sure the aarch64 macos build is working properly? I downloaded the artifact to check, and the dylib it makes is extremely tiny compared to the static library (and also compared to the size it is on Linux):

$ ll libflame.v5.2.0.x86_64-linux-gnu/lib/
/home/im1716/dev/julia/binary
Permissions Size User   Group  Date Modified Date Created Name
.rw-r--r--@  15M im1716 im1716  1 Jan  1970  20 May 10:07 libflame.a
lrwxrwxrwx@    - im1716 im1716  1 Jan  1970  20 May 10:07 libflame.so -> libflame.so.1.0.0
lrwxrwxrwx@    - im1716 im1716  1 Jan  1970  20 May 10:07 libflame.so.1 -> libflame.so.1.0.0
.rwxr-xr-x@ 8.7M im1716 im1716  1 Jan  1970  20 May 10:07 libflame.so.1.0.0

$ ll libflame.v5.2.0.aarch64-apple-darwin/lib/
/home/im1716/dev/julia/binary
Permissions Size User   Group  Date Modified Date Created Name
.rwxr-xr-x@  17k im1716 im1716  1 Jan  1970  20 May 10:07 libflame.1.0.0.dylib
lrwxrwxrwx@    - im1716 im1716  1 Jan  1970  20 May 10:07 libflame.1.dylib -> libflame.1.0.0.dylib
.rw-r--r--@ 7.9M im1716 im1716  1 Jan  1970  20 May 10:07 libflame.a
lrwxrwxrwx@    - im1716 im1716  1 Jan  1970  20 May 10:07 libflame.dylib -> libflame.1.0.0.dylib

Can someone on macos confirm what is in this dylib?

[jd-foster]

$ nm libflame.v5.2.0.x86_64-apple-darwin/lib/libflame.dylib
                 U dyld_stub_binder

[jd-foster]

@imciner2 I think I've done as much as I can here with what I know. What do you think should be next steps?

[imciner2]

I don't know how to get the mac build to use the static library to compile the shared library. The best fix would be to have it just compile the shared library using each individual object file again, since then the linker won't remove anything, however I see that upstream says there is a command-line length issue when doing that - hence this solution.

[ViralBShah]

Since the build is all green, is it ok to merge, or is mac still broken?

[imciner2]

The macOS dylib is still tiny compared to the static library - 17.2kB vs. 7.9MB, so I think it is still broken.

[jd-foster]

I think we should try to port over how BLIS does it, since the make script is a downstream improvement on libflame.

[ViralBShah]

Just wondering if there is a new upstream release that fixes the issue and gets this over the line.

EDIT: I see the last release was 6 years ago - so perhaps not worth putting too much effort in here.

[ChrisRackauckas]

The use case here doesn't care about Mac. Can we just make it no-op on Mac and merge?

[ChrisRackauckas]

I was trying this out SciML/LinearSolve.jl#660 but it seems to have some issues with OpenMP. But more importantly, we were trying to get this as something we could have hardcoded to BLIS 😅, like how we have a way to just load mkl_jll and use the binary instaed of requiring global BLAS changes. However, this library seems like it's built to support LBT. Could it be reasonable to have a version of libflame that is just directly built with BLIS?