Add openblas with flang

[anutosh491]

No description provided.

[anutosh491]

Doing this for scipy.
Not sure if we need libopenblas.a or libopenblas.so or both. I'll try libopenblas.a I guess.

[anutosh491]

The idea being used here is this (OpenMathLib/OpenBLAS#3640 (comment))

[anutosh491]

@DerThorsten @IsabelParedes

Though the above recipe passes I have quite some doubts (or improvements that can be done here)

1. When we host any blas/lapack variants what are we interested in ..... the ".a" file or the ".so" file (I see Isabel's lapack recipe generating liblapack.a and libblas.a) ... so even this above recipe was catered to generate libopenblas.a
   But initially this recipe used

PYODIDE_PACKED=$RECIPE_DIR/openblas-0.3.23.zip
# unzip
unzip $PYODIDE_PACKED
# copy libopenblas.so to
mkdir -p $PREFIX/lib
cp libopenblas.so $PREFIX/lib

2. Talking about the important flags the main ones I see are these
   NOFORTRAN=1, NO_LAPACKE=1, NO_LAPACK=1 , NO_CBLAS = 1 and ONLY_CBLAS = 1

I haven't used any right now but I guess we would want to focus on some (pyodide uses NOFORTRAN=1, NO_LAPACKE=1)

3. Also other flags are NO_SHARED = 1 and NO_STATIC = 1

I had initially started with emmake make shared libs .... and ended up with this error and ended up using the NO_SHARED = 1 flag. Initially the patched flang compiler was being involved but after using no_shared not sure we use flang-new for anything.

Would be great if y'all can guide me here.

[anutosh491]

We might not need to do this

mkdir -p $PREFIX/lib
cp libopenblas.a $PREFIX/lib

Cause the file we are interested is libopenblas_riscv64_generic-r0.3.28.a I suppose (obviously the name can be changed LIBNAMESUFFIX and we can set it to whatever we want)

[anutosh491]

For some context we use RISCV64_GENERIC as the target as mentioned by one of OpenBlas' maintainers. Pyodide also uses the same.

[IsabelParedes]

1. When we host any blas/lapack variants what are we interested in ..... the ".a" file or the ".so" file (I see Isabel's lapack recipe generating liblapack.a and libblas.a) ... so even this above recipe was catered to generate libopenblas.a
   But initially this recipe used

PYODIDE_PACKED=$RECIPE_DIR/openblas-0.3.23.zip
# unzip
unzip $PYODIDE_PACKED
# copy libopenblas.so to
mkdir -p $PREFIX/lib
cp libopenblas.so $PREFIX/lib

For R, I think we would want libopenblas.so so that users can replace libRblas.so with other BLAS libs. But this is optional.

For scipy, it might be better to only have libopenblas.a so that it doesn't need to be added as a run dependency.

It would be nice to have both options, if possible.

[IsabelParedes]

I had initially started with emmake make shared libs .... and ended up with this error and ended up using the NO_SHARED = 1 flag. Initially the patched flang compiler was being involved but after using no_shared not sure we use flang-new for anything.

If flang-new is not used, does anything fail if it's not installed? I'm assuming flang is probably only used when building lapack if it's needed.

[DerThorsten]

@DerThorsten @IsabelParedes

Though the above recipe passes I have quite some doubts (or improvements that can be done here)

1. When we host any blas/lapack variants what are we interested in ..... the ".a" file or the ".so" file (I see Isabel's lapack recipe generating liblapack.a and libblas.a) ... so even this above recipe was catered to generate libopenblas.a

For lapack I believe we need the shared library, but there is no harm in also having the static one

2. Talking about the important flags the main ones I see are these
   NOFORTRAN=1, NO_LAPACKE=1, NO_LAPACK=1 , NO_CBLAS = 1 and ONLY_CBLAS = 1

I haven't used any right now but I guess we would want to focus on some (pyodide uses NOFORTRAN=1, NO_LAPACKE=1)

Whatever is needed for the downstream projects