Brian Dessent wrote:
> Stephen Collyer wrote:
>
>> (And while I'm thinking about it, where does that leading
>> __imp__ in the symbol name come from ? Is that the prefix
>> used by VS when it looks in the list of symbols exported by
>> a library ?)
>
> When the compiler emits a call to a function that has been declared with
> __declspec(dllimport), the call is an indirect call. The function name
> with __imp__ prepended represents the slot in the .idata section (import
> table) that contains the address of the function through which the
> indirect call occurs.
>
> So the implication if you get a link error about missing symbols
> starting with __imp is that your headers declared those functions as
> imported from a DLL yet you're trying to link with a static version of
> the library. You either need to link with the dynamic version (i.e.
> link with the import library) or you need to define the appropriate
> symbol (e.g. CURL_STATIC) so that the headers don't declare functions as
> being imported.

OK, so if I understand you correctly, this is the situation:

1. When the code was compiled the curl function names in the
header files were declared with a __declspec(dllimport) declaration
(as expected).

2. This means that the compiler generated those symbol names with
a leading __imp__ prefix, which means that ..

3. the linker will look for an export list associated with the
DLL that it wants to link against, but it isn't finding it.

Now ISTR that the Windows linker expects to find the export list
for, say, libcurl.dll in libcurl.lib, but also that libcurl.lib
can be a static library. Now given the size of my libcurl.lib my
suspicion is that it is, in fact, a static library, and I'm
missing the "export list" version of libcurl.lib that should have
been generated at the same time as libcurl.dll.

Does that make sense ?

(I do, however, have a libcurl.exp from the same package - anyone
know what that's used for ?)

-- 
Regards
Steve Collyer
Netspinner Ltd