ATL COM wrapper: Link Error

rbrad12345

Hello everyone, Im new to the world of ATL and COM and am trying to create a wrapper class for a eVC++ library. I had the library working fine in a simple MFC app I wrote but the Linker fails in an ATL COM project I've created. Following is the error I receive. wrapper.obj : error LNK2019: unresolved external symbol __imp__Read referenced in function "public: virtual long __cdecl CReader::InitReader(void)" (?InitReader@CReader@@UAAJXZ) I'm guessing this error is due to a mis-understanding (on my part) of how ATL and COM link in external libraries. I was able to force the same error message in my MFC app by removing the .lib in "Project->Settings->Link:Object/Library Modules" which tells me that the Linker isnt seeing the library for some reason. Any help is much appreciated!! Thanks, Ryan Bradley

Jorgen Sigvardsson

Did you __declspec(dllexport) your class from your DLL, and __declspec(dllimport) from the DLL client? :~ Good music: In my rosary[^]

rbrad12345

The library was provided to me by a vendor. Using "dumpbin.exe /exports" I can see the calls I need to make. I'm using the same .H file to __declspec(dllimport) in my ATL/COM project as with the MFC project that works. That is what is confusing me. I'd guessed there is something different about how an ATL/COM project would attempt to link. This has to be something elementary that Im just missing. Ryan Bradley

rbrad12345

Now this is interesting... The symbols the linker errors out on are slightly different between the ATL/COM and the MFC app. The ATL/COM object is looking for __imp__Read while the MFC app is looking for __imp_Read. I can open up the .lib file in notepad and see __imp_Read. Any ideas?? X| :wtf: Ryan Bradley -- modified at 18:07 Friday 9th September, 2005

Jorgen Sigvardsson

Hmm.. I think I know what it could be. IIRC, __cdecl functions are always given an _ prefix, while __stdcall aren't. Try with __cdecl or __stdcall (I'm too tired to sort out which one you need right now.. :zzz: :-D) Good music: In my rosary[^] -- modified at 18:15 Friday 9th September, 2005

rbrad12345

Thanks for mentioning that. I think it is a piece of the puzzle. __cdecl decorates names while __stdcall does not. I've added #error directives to my header to ensure that __stdcall is used and it is. I've tried using __cdecl and it simply gives additional errors. My header prototypes "__declspec(dllimport) int __stdcall Read()" Despite all this sanity checking the linker is still looking for __imp__Read and not __imp_Read as it should. Ryan Bradley

Jorgen Sigvardsson

Man, I'm suffering with you. Linking errors are not fun. :( Good music: In my rosary[^]