This is the mail archive of the cygwin-apps 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 (OpenGL and ncurses maintainers please take note)


--- 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


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