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]

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.


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