undefined reference to `cblas_daxpy'
it seems cblas should be linked to the library (using netlib blas here):
cmake -DHIPO=ON -DBLA_VENDOR=Generic
...
-- Specified BLA_VENDOR: Generic
-- Using BLAS library: /usr/lib/libblas.so
...
[ 98%] Linking CXX shared library ../lib/libhighs.so
[ 98%] Built target highs
[ 99%] Building CXX object examples/CMakeFiles/call_highs_from_cpp.dir/call_highs_from_cpp.cpp.o
[ 99%] Building CXX object app/CMakeFiles/highs-bin.dir/RunHighs.cpp.o
[ 99%] Linking CXX executable ../bin/call_highs_from_cpp
/usr/bin/ld: ../lib/libhighs.so.1.12.0: undefined reference to `cblas_daxpy'
this is version 1.12.0, on archlinux
Is there a reason you want to use Generic blas? The performance is very poor and we strongly recommend using OpenBLAS instead.
Did you install it with
sudo apt update
sudo apt install libblas-dev
Some libblas.so are just wrappers, may only have fortran and may not include the CBLAS (C interface to BLAS) functions like cblas_dax_py, and then you may have to link cblas explicitly. But you would still get inferior performance, so it is best to use openblas instead:
sudo apt update
sudo apt install libopenblas-dev
I'm refraining from using openblas since I found some severe performance issues recently:
- https://github.com/OpenMathLib/OpenBLAS/issues/5402
- https://github.com/OpenMathLib/OpenBLAS/issues/5404
@filikat I guess HiPO would not be affected by these issues
These issues appear to be related to multi-threaded OpenBLAS. HiPO uses OpenBLAS only in single-threaded mode. I would expect OpenBLAS to outperform the BLAS reference implementation by orders of magnitude in general.
what do you mean by single-threaded mode ? do you explicitely restrict the number of openblas threads to 1 ?
Yes, we call openblas_set_num_threads(1). We parallelise some of the large matrix-matrix productst by hand and there is other parallel stuff happening in HiPO. Using more than one thread for OpenBLAS seems to degrade performance, perhaps due to too much contention for the resources.
it could also be the same openblas throwing all available threads to small matrices kind of issue
highs should still link to cblas regardless
OK, so can you confirm that cblas is available on your machine and not just the fortran modules?
yes, as if I manually add -lcblas linker flag it works (it would have failed earlier if the cblas headers were not present anyway)
I just merged this into latest too: cblas should be linked explicitly. Please let me know if you still get issues.