This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: lapack-3.0
James R. Phillips wrote:
All,
Based on the recent discussion regarding an approach to packaging lapack,
I
have put together a trial package for evaluation by core maintainers. As
noted in the previous discussions, lapack is hardly worth the trouble
without an optimized blas, but this is only available via an installation
of atlas from source.
What sort of factors affect the optimization? Does the optimized library
actually perform _worse_ than the non-optimized one if its binaries are
copied to another computer?
Accordingly, I have merged the upstream lapack-3.0 and atlas-3.6.0
upstream
sources for this lapack-3.0-1 package. The binary distribution and the
normal build from source create a lapack library and a non-optimized
reference implementation blas library from lapack source. Instructions
are
included in the CYGWIN-PATCHES subdir of the source distribution which
allow building of locally optimized versions of these libraries using the
lapack base plus the atlas source. The resulting dlls are then to be
installed by hand in the /usr/local/bin subdirectory. This insures two
things: 1) they will be loaded at run time instead of the nonoptimized
dlls
due to /usr/local/bin occuring before /usr/bin in the path set by
/etc/profile; 2) they will not be overwritten by an upgrade or
reinstallation of the binary distribution, which installs its dlls in
/usr/bin.
Point 1) is valid only for executables not installed in /usr/bin themselves.
Is it likely that we would ever want to accept packages which use
lapack/atlas into the Cygwin distribution? If so, the above is not a
wonderful solution.
Max.