(OT?) addressing and calling convention

[cpisztest]

Not sure if this is OT or not, but I am getting unresolved externals which I suspect to be from addressing and calling convention differences.

I am not really sure how linkage works when a library is compiled with cdecl vs stdcall and is attempted to be linked into an executable that uses the other.

Is there a tool somewhere that can be used to examine addressing and calling convention for static libs?

 

[Ian Collins]

Not sure if this is OT or not, but I am getting unresolved externals
which I suspect to be from addressing and calling convention
differences.

I am not really sure how linkage works when a library is compiled
with cdecl vs stdcall and is attempted to be linked into an
executable that uses the other.

Is there a tool somewhere that can be used to examine addressing and
calling convention for static libs?

You should ask on a windows focused group.

The standard C++ answer is to use functions declared extern "C" for any
code shared between C++ and C or built with different C++ compilers.

 

[Dombo]

Op 30-May-14 1:02, (e-mail address removed) schreef:

Not sure if this is OT or not, but I am getting unresolved externals
which I suspect to be from addressing and calling convention
differences.

It might be just a matter of a missing extern "C" declaration around the
C function declarations. To support function overloading most, if not
all, C++ compilers mangle the function names. When calling a C function
from C++ code, the C++ compiler has to know that it shouldn't mangle the
names, otherwise the linker would look for a mangled name in the C
library which doesn't exist, which in turn would lead to a "unresolved
external" error.

I am not really sure how linkage works when a library is compiled
with cdecl vs stdcall and is attempted to be linked into an
executable that uses the other.

I'm not entirely sure, but I don't think the calling convention affects
linking. I.e. if the calling side is compiled with the cdecl calling
convention whereas the library implementing the function uses the
stdcall calling convention I would expect that the linker happily links
those. Not that that is a good thing as it would result in obscure
behavior when actually running the code.

Is there a tool somewhere that can be used to examine addressing and
calling convention for static libs?

Since your are talking about stdcall and cdecl calling conventions
(which is not topical for this newsgroup), I assume you are using the
Microsoft development environment. In that case the dumpbin tool might
give you a clue what is going on.

 

[Nobody]

I'm not entirely sure, but I don't think the calling convention affects
linking. I.e. if the calling side is compiled with the cdecl calling
convention whereas the library implementing the function uses the stdcall
calling convention I would expect that the linker happily links those. Not
that that is a good thing as it would result in obscure behavior when
actually running the code.

It most definitely affects linking.

stdcall functions have their symbols decorated, e.g. "func@4", where the
number is the size of the argument list in bytes. If the call was compiled
on the assumption that the function uses cdecl but it actually uses
stdcall (or vice versa), linking will fail.

Normally this should be taken care of by the headers; stdcall functions
will have a "__stdcall" qualifier between the return type and the function
name. However, this can be buried beneath multiple layers of macros,
meaning that both sides need the same preprocessor definitions.

If you try to provide your own declarations instead of using the library's
associated headers, you're asking for trouble.