By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,044 Members | 1,291 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,044 IT Pros & Developers. It's quick & easy.

VC++6 to VC++2003 - linking troubles

P: 21
Hi All,
I successfully ported an application from VC++6 to VS2003.
Solved compiling issues but now I am sticking with serious Linking troubles.


I got a bunch of:

SgmTestUtil error LNK2001: unresolved external symbol "__declspec(dllimport) public: int __thiscall CSgm2500::GetEepromString(unsigned char,class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > > *)" (__imp_?GetEepromString@CSgm2500@@QAEHEPAV?$CStrin gT@DV?$StrTraitMFC_DLL@DV?$ChTraitsCRT@D@ATL@@@@@A TL@@@Z)


I tried to rebuild the dll in VS2003 (it was developed by my company so I have access to the source), in debug and release, so I used the new dlls and it worked just fine for the release mode (errors are gone and app runs), but I CAN'T make them disappear in debug mode.

I am new to application porting and DLLs so I don't exactly where to look for an answer. Probably the debug dll is in some way different from the other one, but the source is the same, so dunno what to think.

Any hint?

Thanks in advance for your help,

Giovanni
Aug 10 '07 #1
Share this Question
Share on Google+
7 Replies


weaknessforcats
Expert Mod 5K+
P: 9,197
You are using a DLL as a static library.

You need to include the .lib for the DLL in the build as an addtional linker dependency. You will also need to set the path to this .lib.

Use your project settings to make these changes.
Aug 10 '07 #2

P: 21
Thanks for your answer,

I included all .dll and .lib files in additional dependencies of the linker, and I do have all the dlls and libs in the path folder of additional library directories.

The strange thing is that I did the same thing for the release build and it's working fine, so I suppose the dll I am linking in debug (which is different) is someway broken (it was working fine on VC++6) in the new environment.

Any idea? I am not sure if it is a linking problem or if I need to recode something in the dll source for the debug build.

Thanks for your help,

Giovanni
Aug 10 '07 #3

weaknessforcats
Expert Mod 5K+
P: 9,197
Any idea? I am not sure if it is a linking problem or if I need to recode something in the dll source for the debug build.
Usually, the debug version of a DLL has a different name so your .lib would also have a different name for the debuig version.

Are you certain you are using the correct names? A release .lib might not work with a debug DLL since I think the name of the DLL is inside the .lib (don't quote me on this as I haven't checked this out).

Using release libraries in a debug build is not recommended but itshould work as long as the library names and paths are correct. What will happen is that you won't be able to debug into the library code.
Aug 10 '07 #4

P: 21
I double checked dlls names, there's a extra 'd' standing for debug at the end of the regular names, so I am pretty sure everything is in the right place.

The linking errors are about three functions in one of the dlls, so I know which dll is not linking/functioning.

Weird thing I noticed is the following:

I tried to take off from the path folder my debug dlls, obviously the linker asks for them so I start putting them back one by one: it stops asking for the dlls and presents the errors before I put the guilty dll back in place; so it probably doesn't even start to link it, and that's probably the problem.

When I build in release mode and I don't have any of my dlls in my path folder it starts asking for them and the first one it asks for is the 'guilty one' and everything goes fine.

I tried then to build in debug mode putting th guilty the release dll (changing the name in additional dependencies) and it builds without errors, BUT it starts yelling for entry points not found in libraries etc.

I hope this means something to you!

thanks,

Giovanni
Aug 10 '07 #5

P: 21
double checked dlls names, there's a extra 'd' standing for debug at the end of the regular names, so I am pretty sure everything is in the right place.
Actually I double checked both dlls and libs names!
Aug 10 '07 #6

weaknessforcats
Expert Mod 5K+
P: 9,197
The linking errors are about three functions in one of the dlls,
Can you call these functions using the return GetProcAddress()??
Like maybe using this code:

Expand|Select|Wrap|Line Numbers
  1. #include <iostream>
  2. using namespace std;
  3.  
  4. #include <windows.h>
  5.  
  6.  
  7.  
  8. int main()
  9. {
  10.  
  11.  
  12.  
  13.     cout << "Calling functions from a dll" << endl;
  14.  
  15.     //First, load the dll into memory
  16.     HMODULE theDll = LoadLibrary(TEXT("C:\\Scratch\\ClassDemos\\ADll\\Debug\\ADll.dll"));
  17.     if (!theDll)
  18.     {
  19.         cout << "The dll failed to load" << endl;
  20.         return 1;
  21.     }
  22.  
  23.     //Second, get the address of the desried function from the dll
  24.     FARPROC addr = GetProcAddress(theDll, "DisplayFromDll");
  25.     if (!addr)
  26.     {
  27.  
  28.         //Look up the error in the system errors list
  29.         unsigned int what = GetLastError();
  30.         if (what == ERROR_PROC_NOT_FOUND)
  31.         {
  32.             cout << "Function not found in the dll" << endl;
  33.         }
  34.         else
  35.         {
  36.             cout << "Error: " << what << endl;
  37.         }
  38.         return 2;
  39.     }
  40.     cout << "The function has been located in the dll" << endl;
  41.     //Declare a function pointer that can accept the address of the function.
  42.     //You will need to know the function prototype to do this.
  43.     //Dll function prototypes should be provided by the vendor of the dll
  44.     void (__stdcall *DisplayFromDll)();
  45.     //Type-cast the address returned from GetProcAddress to the function pointer type
  46.     DisplayFromDll = reinterpret_cast<void (__stdcall *)()>  (addr);
  47.     //Now use the function pointer to call the function:
  48.     DisplayFromDll();
  49. return 0;
  50. }
  51.  
Aug 10 '07 #7

P: 21
Thanks for your support!
I'll try the code as soon as I can (got all the stuff at work).

Cheers,

Giovanni
Aug 10 '07 #8

Post your reply

Sign in to post your reply or Sign up for a free account.