--- Charles Wilson wrote: > From the original post where I raised the issue: > http://www.cygwin.com/ml/cygwin-apps/2003-04/msg00305.html > > > Basically, a package to be installed under /opt creates an entire tree: > /opt/<package>/bin
Thanks for the info. > > > However, I have no objections if you want to use /usr/lib/lapack/ > instead. I assume the "roll your own optimized DLLs from -src package" > procedure will end up putting the new DLLs in... > > /usr/bin ? > No, /usr/local/bin. This is more compatible with fhs, since these are local libraries built from source. > Will that also replace the import libs (and pseudo-staticlib symlinks to > them) in /usr/lib/ ? Or is the DLL interface absolutely unchanged by > this recompile, so that the "old" import libs are "still good"? Yes, the import libs will be in /usr/lib, and will still be good (by design). I've tested this by building octave, linking against the old import libs, but running with the optimized dll's. Works quite well. The build process for the optimized libraries creates import libraries, but it is not necessary to install them. The atlas compile process also creates (and requires) cblas libraries, but I link those in statically. There are no cblas entry points exposed in the optimized dll's. The import libs are liblapack.dll.a and libblas.dll.a. I provide symlinks for liblapack.a and libblas.a, pointing back to the import libs. This seems to be adequate for autoconf to find the libs; at least it is for building octave. This in effect only provides support for shared libraries. I suppose I could provide a separate package with static libs. I haven't noticed an overwhelming demand for it. ;) > so I know the trouble it can often be to get this beastie to compile > correctly -- and optimally. Kudos for taking on this task!! > Thanks. The nice thing about this package is, once we get it right, it won't need to be updated very often. Jim Phillips
