Stephen Collyer wrote:

> it's a static library. (My nm crashes when I try to look at it, so I
> can't run your test)

You need a PE-targeted nm, i.e. from binutils built for i686-pc-mingw32
or i686-pc-cygwin. A linux targeted nm won't work, as linux is ELF and
that's a totally different object format.

> You're right. I've run this on the libcurl.lib in question and
> it reports it as having multiple .idata sections, but also a .text,
> .rdata and .data sections whereas a .lib that I know to be an import
> library has only .idata sections. I think that implies that it must
> be a static library, though I'm not sure what the .idata sections
> are for in this case.

Yes, anything with .idata is an import lib. The import lib also has
objects with .text sections, which consist of thunks which amount to
copies of the following for each function in the DLL:

_foo:
        call *__imp__foo

This is for the benefit of ancient compilers, or for the case where you
didn't declare the function dllimport but still linked it against the
import lib: a normal call to foo() links with this thunk that does the
equivalent of what a __declspec(dllimport) call to foo() would have
done. This leads to another solution to the problem: just don't use
__declspec(dllimport), and everything will work out for both static and
shared without having to explicitly -DFOO_STATIC. However this does
result in a very small size and performance penalty as all calls to the
DLL go through these thunks.

Aside from that, however, there is no actual code in an import library
which is why it is usually tiny.

Brian
Received on 2008-04-23