"M. Zhou" <[email protected]> writes: > On Mon, 2026-02-23 at 10:21 +0100, Ole Streicher wrote: >> I talked to upstream and the reason seems that wsclean uses a different >> threading system on some places, and that doesn't work together well >> (heave performance problems). Also he mentions that setting the >> environment variable in the program is too late because then the libblas >> is already loaded. > > BLIS is single threaded unless an environment variable is specified. > > If your program is an ELF binary, you may add the following path as > the RPATH to force override the BLAS to single threaded implementation > regardless of the alternatives system: > > /usr/lib/x86_64-linux-gnu/blis-serial/ > > If it is a script or can be wrapped with script, LD_LIBRARY_PATH and > LD_PRELOAD > with the correct blas implementation will also work.
The implementation that is supposed to work is the one from lapack. I added -DCMAKE_INSTALL_RPATH="/usr/lib/$(DEB_HOST_MULTIARCH)/blas" (and more) to the flags, but it doesn't help. Checking with chrpath -l /usr/bin/wsclean shows that RPATH is indeed set, but ldd still reports that it is linked to the openmp variant if that is installed, and running wsclean shows the error from my first message. Even preloading with LD_PRELOAD=/usr/lib/x86_64-linux-gnu/blas/libblas.so wsclean doesn't help. Having multiple libraries with the same name installed at the same time seems not very robust when one needs to select one of them. I am now out of ideas. Cheers Ole
