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. libfoo.la 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. Brian [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 here. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
