|
From: | Earnie Boyd |
Subject: | Re: MinGW libtool DLL failure |
Date: | Thu, 10 Oct 2002 13:06:18 -0400 |
User-agent: | Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 |
Earnie Boyd wrote:
Earnie Boyd wrote:Bob Friesenhahn wrote:On Thu, 10 Oct 2002, Boehne, Robert wrote:The only thing that troubles me about the link line Bob posted is that a .dll is specified in the link, not the corresponding .lib. I'm not a Windows guru, but I thought that you never link to a dll directly, but to the .lib that is created when the dll is.This, of course, is possible via the wonders of libtool. Libtool should hide the fact that a .lib or .a (or whatever) is actually used under the covers. In fact, Microsoft compilers, Cygwin, and MinGW appear to use different naming schemes for these link libraries.Both Cygwin and MinGW should use .dll.a for shared import library and should use .a for static library. Both Cygwin and MinGW will find foo.lib for -lfoo as a last resort if it exists in the library search path. Both Cygwin and MinGW will find foo.dll to satisfy -lfoo if nothing libfoo.dll.a, libfoo.a or foo.lib doesn't exist and foo.dll is in the library search path.I should also mention that a static library can be used to resolve symbols for the .dll file.
And to complicate it more, static objects (i.e.: objects that aren't exported from the dll) can be stored in the same library as the import objects for the dll. The libcygwin1.a library contains such objects for an example. In this case the name should be reflective toward the static members, in other words libfoo.a.
Earnie.
[Prev in Thread] | Current Thread | [Next in Thread] |