I'm trying to make a static library with vc++ and then use its functions from an assembly program with masm.

The static library just has a stupid test function "aFunction" taking two DWORD arguments.

I tested it by making a client program with vc++ and it works.

However then I tried using masm to create a client program for it and it doesn't work. The linker comes back saying:
error LNK2001: unresolved external symbol _aFunction@8

I ran dumpbin on the library and it came back with _aFunction being a public external function but with no @8. I tried a bunch of stuff in vc++ but I can't seem to make a library which has the @8 on the function name.

Any ideas?

Posted on 2001-12-13 11:27:38 by cmonahan
If the functions are defined with the __stdcall keyword then it works.

Surprisingly (unless I messed up and didn't actually try this correctly) the option for calling convention under the project settings dialog didn't fix it. There's a pulldown there that lets you select stdcall or fastcall or cdecl. It's under the C/C++ tab, after selecting code generation. But that didn't do it as far as I could tell.

I linked together everything and then because of some dependency in libcd.lib, it wanted main defined! So I built another dummy static library with just the one main function and it built. That main function was not called when my program executed.

If nothing else using masm makes one feel like a complete novice. (my experience anyway). (I don't mean this as a bad thing)
Posted on 2001-12-13 12:09:51 by cmonahan
Ok, when I don't have access to the source code for the library, like in the case of libc.lib, which has standard c functions and comes with vc++, how do I fix the problem from the client (asm) end of the picture?

Using strcpy as an example, when I run dumpbin on libc.lib, I get:
A36BC _strcpy

When I run l2inca on it, there is no strcpy prototype. (So that's a problem, right?)

When I add the prototype
to my asm file, then I get my old problem again:
error LNK2001: unresolved external symbol _strcpy@8

Is there a way to get around this? What call mechanism should I expect strcpy uses? How would I call the function manually with that mechanism? Is there a way to figure out for sure what call mechanism strcpy is using, based on analysis of libc.lib?

Posted on 2001-12-13 13:02:05 by cmonahan
If I keep up answering my own questions, no one will ever help me out. :)

Well, I guessed it was a C calling convention since it had a leading underscore "_strcpy", and only C or STDCALL having a leading underscore. Then I saw that by having ".model flat,stdcall", that tells masm to make a stdcall. However I read that I could override that by making my strcpy prototype:


This compiled and seemed to run correctly.
Posted on 2001-12-13 13:23:27 by cmonahan
cmonahan - glad you got it working. Just wanted to let you know it was interesting to see you tackle your own problem..and the steps you took to solve it!
Posted on 2001-12-14 07:44:06 by gscundiff