search

blas-lapack-rs / openblas-src

Source of BLAS and LAPACK via OpenBLAS
Other
78 stars 48 forks source link

[openblas-build] Don't try to run openblas tests when cross compiling #117

Open ivan-aksamentov opened 9 months ago

ivan-aksamentov commented 9 months ago

This configuration runs make targets all (explicit) and libs (coming from self.make_args()), which both try to run openblas tests from test/ and utest/ directories compiled for a foreign architecture on a host machine:

https://github.com/blas-lapack-rs/openblas-src/blob/e1fd7951dc3c2a51b4c73befff23787f915b1fff/openblas-build/src/build.rs#L493-L495

Which causes errors, because the resulting test executable cannot be ran on a host arch.

It also passes unrelated env vars - whether you cross-compiling or not, while preventing users from setting TARGET for example.

Instead, only the make target shared (confusingly named) needs to run. Users should be in control of which env vars they want to set during cross-compilation, there is no point to pick and rename the vars in this crate - it only brings confusion and bugs.

This issue makes it impossible to cross-compile the library (combined with other defects), and therefore it makes it impossible to use math libraries which rely on this crate in a production environment.

Dirreke commented 5 days ago

Users should be in control of which env vars they want to set during cross-compilation, there is no point to pick and rename the vars in this crate - it only brings confusion and bugs.

I don't know why these complex environment variables were used before. However, I believe it makes sense because variables like TARGET, CC, and FC can easily influence and be influenced by other crates during the build process. Renaming them to OPENBLAS_* can help avoid such conflicts. For example, if I set CC instead of OPENBLAS_CC for the cross-compilation toolchain, the openssl crate will fail to compile.