Le lundi 10 juillet 2023 à 22:01 +0200, Andreas Tille a écrit : > Hi Sébastian, > > Am Sat, Jul 08, 2023 at 10:01:15AM +0200 schrieb Sébastien Villemot: > > > > So, given all that, I’m inclined to (try to) remove atlas during the > > trixie development cycle. > > Sounds reasonable. > > > Any thought on this? > > I've checked my responsibility for the dependencies and stumbled about > emmax > > > emmax.c:10:10: fatal error: clapack.h: No such file or directory > 10 | #include <clapack.h> > | ^~~~~~~~~~~ > compilation terminated. > > > and noticed > > $ apt-file search clapack.h > libatlas-base-dev: /usr/include/x86_64-linux-gnu/clapack.h > ... (other instances are not blas related) > > which was probably the reason why I've picked libatlas-base-dev > originally. I would not say that emmax is important and its > also a not maintained upstream any more. However, I vaguely > remember that this > #include <clapack.h> > in some code pieces of Debian Med was the reason to actually > pick this blas implementation. Any hint how to deal with such > cases?
clapack.h is apparently an early attempt at providing a C interface to some LAPACK functions (which are in Fortran). It indeed looks ATLAS- specific. The modern solution for that problem is to use LAPACKE (note the final “E”), which is provided by liblapacke-dev. It is a standardized and maintained C interface to all LAPACK routines. I guess it should be feasible to adapt emmax to make it work with LAPACKE. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ https://www.debian.org
signature.asc
Description: This is a digitally signed message part
