error LNK2001: unresolved external symbol . . .

[JFG]

Can somebody explain what kinds of coding errors - or other errors - make the linker give the general line

  something.obj : error LNK2001: unresolved external symbol _SomeSymbolName

I'm pretty sure that there's various different things that can lead to this, but defining the symbols that the linker complains about just like all other symbols are defined doesn't solve the problem.  For a DLL I am writing, I get the output:

  Microsoft (R) Incremental Linker Version 5.12.8078
  Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

     Creating library IO.lib and object IO.exp
  IO.obj : error LNK2001: unresolved external symbol _CoCreateInstance@44
  IO.obj : error LNK2001: unresolved external symbol _CLSID_DirectDrawFactory
  IO.obj : error LNK2001: unresolved external symbol _IID_IDirectDrawFactory
  IO.obj : error LNK2001: unresolved external symbol _IID_IDirectDraw2
  IO.dll : fatal error LNK1120: 4 unresolved externals

except that the first symbol (without the leading underscore of course) should be defined in ole32.inc and ole32.lib, which I include, and the latter three symbols (also without the leading underscore) are defined in other files that are also included, specifically within the data segment.  Got any ideas?

[OceanJeff32]

I am not an expert by any means, but from my personal experience, this is what needs to happen for a library to be linked in:

<*.inc> files should be included, this provides the prototype for how to make the function calls, parameter sizes and names, function names, prefixes, postfixes...what have you.

<*.lib> files should be included AND these are the function definitions.

The .INC files can be hard coded or included, but the .lib files contain actual compiled code that can't be hard coded unless you are the original maker of the .lib file.  So the .lib file is the key.

IF you are linking in the proper .lib files, I noticed that some of your includes are for direct x, you might not be calling the functions properly.  Direct X functions operate through interfaces which need to be exposed and referenced for all function calls.. . I never succeeded in doing this with assembly language, but I know it involves the use of virtual function tables, which is like an array of pointers to function within interfaces...hope that isn't too confusing for you...well, it was for me, so I opted not to pursue Direct X with Assembly Language.

As a consequence to the new OpenGL Forum on here, I am pursuing that, and enjoying every minute, I might add.

Good luck, hope this helps you,

Jeff C
:U

P.S. If you are using Direct X, and can get past the Virtual Tables dilemma, just be sure the .inc and .lib files that you are using (i.e. your SDK) match the version of Direct X you have on your system.  OR make sure that your SDK is less advanced than the runtime you've got.  But you probably already know that... :U

[JFG]

Thanks for the reply, OceanJeff32.

As far as I can tell, I did call the functions properly.  At least according to the ddtest example in the MASM32 package, MSDN 98 documentation, and DirectX 7 SDK documentation, everything is as it should be.  The include and library files are all there too, like I said, being stuck into the data segment declarations.  By what I can tell, all the necessary symbol definitions are there too.  I put them all in there myself, except for what goes in the Microsoft .lib files of course, and it puzzles me that it was only those particular symbols, and not others that are defined the same way (e.g. IID_IDirectDrawSurface2).  I studied thoroughly the COM interface macros and this whole business of how COM interfaces (and GUIDs) are defined and used, as far as it concerns DirectX, and I'm pretty certain that the problem is not some bizarre issue with how symbols are being used there.  (Note it's not function names that are being identified as unresolved external symbols.)  In case someone else checks this out, might the problem be some mischievous and conflictive EXTERNDEF declaration I left somewhere?  Well, I'll be checking for that, though I'm pretty sure I took all those out.  In case that turns out to be the problem I suppose I'll post that here for anybody else who comes across this kind of problem.