This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

cygwin packaging approach for atlas3.6 and lapack3


All,

I'm looking at ways to package lapack3 and atlas3.6 for cygwin, in support of
an octave package eventually.  These are numerical libraries; lapack3 is a
fortran matrix arithmetic library package that is implemented in terms of calls
to something called a blas (basic linear algebra system) library.  It comes
with a generic fortran blas implementation, which is expected to be replaced if
possible by a tuned blas implementation optimized for the machine lapack runs
on.

atlas is capable of providing that optimized implementation; however, it needs
to be compiled from source on the machine in which it will run in order to be
most effective.  It would be possible to provide different binary packages for
different processor architectures (Debian does this), however; this probably is
a more complex project than I can handle at this point.

Accordingly, I am considering building a combined lapack/atlas package, with a
makefile switch that determines whether it is built with the generic blas
package or whether it builds an optimized blas package from atlas source.  The
binary package would be built and distributed with the generic blas library;
but instructions in the source package would be provided to facilitate build
and installation of an optimized blas library.

I guess the obvious question is why the packages need to be combined.  The
atlas library builds not only an optimized blas, but also optimized versions of
some of the basic lapack routines.  So if atlas is built, it needs to replace
both lapack and blas libraries.  There isn't a clean split between the
libraries provided.  See [1]. The libraries would be implemented as dll's, not
as static libraries.

I am soliciting comments and suggestions on the approach I have outlined here. 
At a minimum, I'd like to know whether the core maintainers would in principle
be willing to approve a package built in this way, i.e. with a default binary
configuration which could be replaced with an optimized configuration if the
source package is installed.

Thanks for your time,

Jim Phillips


[1]http://www.octave.org/mailing-lists/help-octave/2001/1332


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]