This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: Packaging lapack, blas, etc
- From: Igor Pechtchanski <pechtcha at cs dot nyu dot edu>
- To: "James R. Phillips" <antiskid56-cygwin at yahoo dot com>
- Cc: cygwin-apps at cygwin dot com
- Date: Tue, 18 Jan 2005 21:05:46 -0500 (EST)
- Subject: Re: Packaging lapack, blas, etc
- References: <20050119004620.37705.qmail@web13607.mail.yahoo.com>
- Reply-to: cygwin-apps at cygwin dot com
On Tue, 18 Jan 2005, James R. Phillips wrote:
> Hi,
>
> I am looking at packaging numerical libraries such as lapack and blas
> for use by a cygwin version of gnu octave. I would like some guidance
> on a couple issues:
>
> 1) I anticipate developing the libraries in a dll format, and there may
> be multiple versions, optimized for different processor architecture.
> What is the best way to support (ie select from) multiple installed
> library versions at run time? Simply make certain the correct version
> is copied to /usr/bin, or add the path to the correct version to the
> $PATH environmental string? Or something else?
I would imagine the architecture-specific libraries would go into
/usr/lib/lapack/<arch>..., and there will be a wrapper library in /usr/bin
that will select the correct libraries to load based on the (dynamically)
detected processor architecture. That way, the whole installation can be
copied over to another machine (or even shared over the network) with no
loss of functionality. One can use, e.g., /proc/cpuinfo to find out the
processor architecture, and some mechanism similar to Cygwin's autoload.cc
for the wrapper lib.
> 2) I know how to use dlltool to generate export libraries, but I'm not
> certain that is really necessary. It is difficult for me to piece
> together the bits of information from various web pages and man pages,
> but the implication is that it can all be done with gcc and ld. Is this
> so? My script to create the the blas dll from the static library
> libblas_static.a is
>
> dlltool --export-all-symbols -e libblas.exp.o -l libblas.dll.a -D libblas.dll libblas_static.a
> gcc -shared libblas.exp.o libblas_static.a -lg2c -o libblas.dll
>
> This works, but perhaps there is a technically more correct, or
> efficient, or elegant way?
You should be able to use, for example
gcc -shared -Wl,--out-implib,libblas.dll.a libblas.exp.o libblas_static.a -lg2c -o libblas.dll
HTH,
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ pechtcha@cs.nyu.edu
ZZZzz /,`.-'`' -. ;-;;,_ igor@watson.ibm.com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT