LINK : error LNK2020: unresolved token (0A0000AB) sscanf

[Eric Twietmeyer]

Hello,

I am running into something very strange. I am writing a .NET assembly
using managed c++ (VS.NET 2003) and in this project when I attempt to make a
call to sscanf (from stdio.h) I get the error indicated in the subject line
when compiling.

Strangely, if I create a new "Hello World" application that is completely
stripped down I can successfully link when there is a call to sscanf. I
duplicate the project settings from my main assembly when doing this (except
of course creating an exe rather than a dll).

Also very strangely, in my real assembly, I can compile and link
successfully with calls to random other functions defined in stdio.h (I
tried tmpfile and tmpnam for instance), but not others (_snscanf, others).
Also I can link successfully with calls to functions defined in other
headers, for instance inserting a call to _fpreset() compiles and links fine
as well.

I assume I am seeing something strange having to do with link order? My
assembly uses various System dlls and various other assemblies that we have
written locally. I have no idea how the linker attempts to resolve these,
but the sscanf symbol is clearly located in the msvcrt(d).lib library,
against which I am linking.

Does anyone know what might be going on? It would be very painful to
attempt to break apart the assembly to determine which piece under which
circumstances will not link.

Thanks in advance,

Eric Twietmeyer

 

[Guest]

This isn't a problem with link order. Instead it is a problem with identity. For some reason, the compilier is marking sscanf as a .Net style function. Non-.Net functions will give a LNK2001 error when they can't be found

I have, in my limited experience, successfully mixed stdio and .Net in the same project, but not the same file. Perhaps there is an incompatibility. One thing to try is move the #include <stdio.h> so that it comes before the #using <mscorlib.dll>. Another thing is to write a wrapper in a seperate file that doesn't use mscorlib.dll

Are you using stdio in any .Net class libraries? I've noticed that doing this will promote some functions from __cdecl to __clrcall. I'm still working on this one myself

Make a post if you figure out the problem so others might be able to search for it.

 

[Eric Twietmeyer]

Hello,

Yes, I am successfully using stdio in other .Net class libraries. As I
mentioned, even in my existing .Net class library with which I have the
problem with sscanf I can successfully link when inserting calls to other
stdio.h functions (tmpfile, tmpnam for instance).

I just tried moving around the order in which the #using and #include
directives are arranged, with no difference.

At this point I will use DllImport, I can't spend a bunch of time tracking
this down.

If, as you say, you think that the __cdecl is changing to __clrcall, that
would obviously be a major problem and would clearly cause the link error.
Pretty strange.

If I come up with something else I'll post. Thanks for your reply.

-Eric Twietmeyer

This isn't a problem with link order. Instead it is a problem with

identity. For some reason, the compilier is marking sscanf as a .Net style
function. Non-.Net functions will give a LNK2001 error when they can't be
found.

I have, in my limited experience, successfully mixed stdio and .Net in the

same project, but not the same file. Perhaps there is an incompatibility.
One thing to try is move the #include <stdio.h> so that it comes before the

Are you using stdio in any .Net class libraries? I've noticed that doing

this will promote some functions from __cdecl to __clrcall. I'm still
working on this one myself.

Make a post if you figure out the problem so others might be able to

search for it.