Hi Drew, all, Drew Parsons <[email protected]> writes:
>> I have a package (wsclean) the works only with the orignal, >> non-threaded version of blar. (from liblapack). I could not find out >> how I can force-link to this one [...] > > A brute-force method could be to use Depends: liblas-dev without the > alternatives (i.e. not Depends: libblas-dev | libblas.so) to strictly > build with the generic (netlib) BLAS. [...] > I think you could control what dh_shlibs generates by providing your > own shlibs file with wsclean/debian to override what libblas3.shlibs > generates. Something like > libblas 3 libblas3 | libopenblas0-serial | libblis4-serial This does not work because if openmp-blas is installed additionally, it becomes the default alternative in /etc/alternatives, overriding the one that was originally linked. And I don't want to forbid the use of the threaded variants for other tasks. Otherwise one would cripple the performance too much, specifically for radio astronomers who do a lot of linear algebra. > It feels a bit strange to me for wsclean to be strictly incompatible > with threaded BLAS, and to have to control the BLAS implementation so > carefully. If there's no way to make wsclean more flexible, then maybe > a better approach is for wsclean to internally enforce the environment > variable OMP_NUM_THREADS=1 ? That should keep any BLAS implementation > down to a single thread. 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. I however also don't understand the purpose of the alternatives system for libblas: Usually, my understanding was that it resolves the problem that some packages require dependency d1, other d2, but many can use either d1 and d2. For libblas however, setting libblas to one implementation renders all other unusable, so why don't we use Conflicts: between them? Why should one install lapacks libblas if it cannot be used anyway? As it is implemented now, the alternatives system seems not really useful here. IMO this is an implementation issue: it uses the same library name everywhere, just on different paths. If we would instead use different library names which are all in the standard search path, packages can just link to the working one if required, or use the default one if they can rely on /etc/alternatives. Best regards Ole
