Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attempt to add Openblas #1377

Draft
wants to merge 10 commits into
base: main
Choose a base branch
from
Draft

Conversation

anutosh491
Copy link
Contributor

No description provided.

@anutosh491
Copy link
Contributor Author

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

@anutosh491
Copy link
Contributor Author

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

@anutosh491
Copy link
Contributor Author

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

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

cp libopenblas.a $PREFIX/lib
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@IsabelParedes
Copy link
Member

  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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants