Re: build-depends on atlas, which is obsolete and scheduled for removal

2023-11-29 Thread Andreas Tille 
Control: tags -1 help

[Ritika Ramani in CC to inform that Debian tries to get rid of Atlas
 which also affects phast. see https://bugs.debian.org/1056681]

Hi,

I tried to replace clapack by LAPACKE.  Unfortunately this is not a
drop-in replacement.  As you can see in the raw(! normal log is to
long!) build log on Salsa[1] when seeking for the string
  too few arguments to function
you see

...
phast_eigen.c: In function 'mat_diagonalize':
phast_eigen.c:62:3: error: too few arguments to function 'dgeev_'
   62 |   dgeev_(, , , tmp, , wr, wi, vl,
  |   ^~
In file included from /usr/include/lapack.h:11,
 from 
/builds/med-team/phast/debian/output/source_dir/src/../include/phast/external_libs.h:43,
 from 
/builds/med-team/phast/debian/output/source_dir/src/../include/phast/vector.h:19,
 from 
/builds/med-team/phast/debian/output/source_dir/src/../include/phast/matrix.h:18,
 from 
/builds/med-team/phast/debian/output/source_dir/src/../include/phast/eigen.h:18,
 from phast_eigen.c:18:
/usr/include/lapack.h:1828:6: note: declared here
 1828 | void LAPACK_dgeev_base(
  |  ^
phast_eigen.c: In function 'mat_eigenvals':
phast_eigen.c:199:3: error: too few arguments to function 'dgeev_'
  199 |   dgeev_(, , , tmp, , wr, wi, NULL,
  |   ^~
...


Seems the LAPACKE function is differently defined than the clapack
function.  Any help is really appreciated.

Note: There might be a chance to define SKIP_LAPACK and by doing so do
not build with some performance drain.  However, I'd prefer if we could
provide phast with the speed users might expect.

Kind regards
   Andreas.
[1] https://salsa.debian.org/med-team/phast/-/jobs/4979980/raw

-- 
http://fam-tille.de

Help for emmax needed (Was: Removing ATLAS?)

2023-11-29 Thread Andreas Tille 
Control: tags -1 help

Hi,

Am Fri, Jul 14, 2023 at 01:40:22AM +0200 schrieb Sébastien Villemot:
> Le lundi 10 juillet 2023 à 22:01 +0200, Andreas Tille a écrit :
> > 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 
> >   |  ^~~
> > compilation terminated.
> > ...
> 
> 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.

I tried to do so in Salsa.  Unfortunately LAPACKE is not a drop in
replacement and I'm lacking the necessary knowledge about all these
LAPACK implementations.  For instance I have no idea how to fix the
error you can see in Salsa CI[1] which has

...
emmax.c: In function 'dsyevd':
emmax.c:1633:17: error: conflicting types for 'dsyevd_'; have 'void(char *, 
char *, int *, double *, int *, double *, double *, int *, int *, int *, int *)'
 1633 |   extern  void  dsyevd_ (char *JOBZp, char *UPLOp, int *Np,
  | ^~~
In file included from /usr/include/lapack.h:11,
 from emmax.c:10:
/usr/include/lapack.h:17096:6: note: previous declaration of 'dsyevd_' with 
type 'void(const char *, const char *, const int32_t *, double *, const int32_t 
*, double *, double *, const int32_t *, int32_t *, const int32_t *, int32_t *, 
size_t,  size_t)' {aka 'void(const char *, const char *, const int *, double *, 
const int *, double *, double *, const int *, int *, const int *, int *, long 
unsigned int,  long unsigned int)'}
17096 | void LAPACK_dsyevd_base(
  |  ^~
emmax.c: In function 'dsyevr':
emmax.c:1652:17: error: conflicting types for 'dsyevr_'; have 'void(char *, 
char *, char *, int *, double *, int *, double *, double *, int *, int *, 
double *, int *, double *, double *, int *, int *, double *, int *, int *, int 
*, int *)'
 1652 |   extern  void  dsyevr_ (char *JOBZp, char *RANGEp, char *UPLOp, int 
*Np,
  | ^~~

Looking at the last line of this snippet (line 901 in the linked CI
log[1]) the parameter char *RANGEp is not part of the declaration of
LAPACK_dsyevd_base given in line 17096 of /usr/include/lapack.h.

I admit this is hard to solve for me and I would love if someone
with some knowledge of LAPACK could provide some patch.  A similar
issue exists for dgetrf.

Any help would be appreciated.

Kind regards
   Andreas.

[1] https://salsa.debian.org/med-team/emmax/-/jobs/4977705#L901

-- 
http://fam-tille.de