lapack-3.0

[Max Bowsher]

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.