search

emscripten-forge / recipes

Recipes to build the packages for the emscripten-forge distribution
BSD 3-Clause "New" or "Revised" License
56 stars 49 forks source link

Attempt to add Openblas #1377

Open anutosh491 opened 1 month ago

anutosh491 commented 1 month ago

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

anutosh491 commented 1 month ago

The idea being used here is this (https://github.com/OpenMathLib/OpenBLAS/issues/3640#issuecomment-1144029630)

anutosh491 commented 1 month ago

@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.

IsabelParedes commented 1 month ago
  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 commented 1 month ago

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 commented 1 month ago

@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

  1. 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