how to build gsl dll

Brian Dessent
Sun Feb 17 22:18:00 GMT 2008

Mirko Vukovic wrote:

> I am trying to build a dll for gsl.  I want to link it to clisp.

Why?  The Cygwin gsl packages already contains everything you need,
including both shared and static versions.  Install the 'gsl' package
for the runtime files (the DLL) and install 'gsl-devel' for the
developer files (headers, import library, static library, libtool
library.)  You don't have to do anything.

> On the other hand the gsl executable contains the *.a, *.dll.a and
> *.la files. Is there a way to convert them to the dll.a

That doesn't make any sense.  There is no need to convert anything, not
that that's even possible.

> Frankly, I started dealing with libraries only about a week ago, and
> while I understand the .a, .so, .dll types (I think), I'm not sure
> about dll.a and .la.

For a package 'foo' cygfoo-n.dll is the shared library, it goes in
/usr/bin since it must be in the PATH.  This is the only file that is
actually used at runtime[1], as opposed to link time.  n is the ABI
version, if present.  libfoo.dll.a is the import library for
cygfoo-n.dll and it goes in /usr/lib.  An import library is just an aide
for the linker, it contains no actual code.  libfoo.a is the static
version of the library, and also goes in /usr/lib.  Sometimes import
libraries are also named libfoo.a too but this practice is discouraged,
it's mostly legacy things like all the w32api import libs that are still
named this way.  Import libraries can also be renamed as foo.lib if they
are to be used by the MS toolchain. is the libtool library,
it's just a text file that describes aspects of the library and is used
by libtool if you use that to link.


[1] Okay technically the libtool .la file could be read at runtime if
the library is dlopened with libltdl, but that's probably not relevant

Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list