unresolved external error

unresolved external error

• furjaw

  You can check that both functions have the same decorated by using dumpbin /SYMBOLS.

  Run it on the object file with the unsatisfied reference (tryagain.objin your case).

  You should see a symbol with an UNDEF section index with your symbol name. The rightmost is the decorated symbol name.

  You should see a corresponding definition for the .lib file with external binding. Can you post back with both names

  Possibly causes for clashes are the linkage (C vs. C++) and the calling convention (cdecl,stdcall,fastcall).

  -hg

  
  

• Hongqin

  it appears to be searching the correct library (twice actually).  at least the library comes up as one being searched.  i don't understand why it is not found in the library. 

  this is a function written in C but that shouldn't matter if it is in the library right

  Thanks!

  
  
  

• David Botz

  i am unfamiliar with the dumpbin /SYMBOLS. how do i run this

  Thanks!

  
  
  

• nonamehero

  ok i think i have found my problem. the command furnsh_c does not have an object in the library. its weird because it is the only one not in there.

  thanks for the help. i really appreciate it!

  
  
  

• Ken Fleming

  i think so, i just recently recomplied them so it should have been done with the visual studio 2005 complier.

  does it matter that the function i am calling is C code

  thanks!

  
  
  

• GAG1

  Are the lib and the exe compiled using the same version of the compiler
  
  

• jbkcmouli

  ok thanks. here is what i came up with: running dumpbin on the object file

  018 00000000 UNDEF notype () External | _furnsh_c

  i ran it also on my library but the output exceeding my window size and i could not find the fuction funsh_c in what was on the sceen

  thanks!

  
  
  

• Zaracattle

  Looks ok. You should still use dumpbin as I wrote before to see binding is global (Extern) and the names match.

  -hg

  
  

• George2

  The first one is expected. It lists a reference to symbol named _furnsh_c (which is the mangled name for furnsh_c with C linkage a __cdecl calling convention).

  If you don't find the definition in your library it simply means the function is not included in your library.

  A .lib is just an archive containing several object files. One issue would be that your library is missing the object that implements the function or that object file does not provide the function.

  You can use lib /LIST yourlib.lib (again a command line utility) to list the object files contained in the .lib.

  You can then extract the particular member object file with LIB /EXTRACT:object_file_defining_furnsh_c yourlib.lib and run dumpbin /SYMBOLS on the object file to see what's in there.

  If you have really included the file I can only think of a preprocessor macro expansion getting in the way or you might have declared the function static (static functions are only emitted when referenced - but even when emitted the linker does not consider symbols with static binding to satisfy global references).

  Can you show us the source code for your implementation of furnsh_c Are you sure there are no macros hiding it You can always generate a preprocessed file to see what the preprocessor does by using /EP (select C/C++ -> Preprocessor -> Generate Preprocessed File in the IDE) and look for the sourcefile.i file.

  -hg

  
  

• Julibalu

  i do in fact have it declared as an external like this:

  #include <stdafx.h>

  #include <stdio.h>

  #include <SpiceUsr.h>

  #include <SpiceZfc.h>

  #include <SpiceZmc.h>

  extern "C" {

  void furnsh_c ( ConstSpiceChar * file );

  }

  void main()

  { ..........

  furnsh_c("merged.tls");

  ............}

  
  
  

• fender46

  It's a command line utility. You can open a command line prompt with the correct path set via the Windows start menu:

  Programs->Microsoft Visual Studio 2005->Visual Studio Tools->Visual Studio 2005 Command Prompt

  just run:

  dumpbin /SYMBOLS tryagain.obj

  and

  dumpbin /SYMBOLS yourlib.lib

  and look for the lines with the offending symbol names.

  -hg

  
  

• Long Xue

  Oh, didn't read your message carefully. If the function is implemented in C it has C linkage. When you want to use it from C++ it must be declared with C linkage (extern "C"). That's why you typically see things like

  #ifdef __cplusplus
  extern "C" {
  #endif
  ... /* declarations go here */
  #ifdef __cplusplus
  } /* extern "C" */
  #endif

  in header files targeting both C & C++.

  -hg

  
  

• kidwidahair

  Try using the linker /verbose switch to see if you are indeed linking to the desired lib.

  Thanks,

  Ayman Shoukry

  VC++ Team

  
  
  
• unresolved external error