Clrdump (C++) error LNK2019: unresolved external s

问题:

I am using a makefile system with the pvcs compiler (using Microsoft Visual C++, 2008 compiler) and I am getting several link errors of the form:

error LNK2019: unresolved external symbol __imp__RegisterFilter@8 referenced in function _main

This is happening DESPITE using the extern "C" declaration, viz.:

extern "C" int CLRDUMP_API RegisterFilter( LPCWSTR pDumpFileName, unsigned long DumpType );

Also, in the makeexe.mak, the library is being linked in as:

$(COMPILEBASE)\lib\clrdump.lib \

To be honest, I am not an expert at makefiles, and I am changing over a system from Microsoft Visual C++ 6.0 to 2008. This change-over may have something to do with the link errors, as the system used to work before.

Any help would really be appreciated.

Thanks in Advance,

Sincerely, Joseph

-- Edit 1 --

Does anyone know how to turn verbose on in the makefile system of pvcs?

Note that the above function is already a compiler-decorated version, having

__imp__RegisterFilter@8

whereas the C++ function is just

RegisterFilter

Thanks for the help, but if anyone can post a more complete solution, that would also be very appreciated.

Sincerely, Joseph

-- Edit 2 --

Some kind person posted this, but when I signed in it disappeared:

The imp prefix indicates that this function is imported from a DLL. Check the definition of CLRDUMP_API - is it __declspec(dllimport)? See this article for more information.

There was a working link, but I've lost that, however I suppose one can always search the topic.

Thanks, whoever you were!

-- Edit 3 --

Thanks ChrisN (I'm not yet allowed to vote). Despite using the refresh button, your answer disappeared, but then re-appeared after I posted a cut-n-paste.

This is my definition of that:

define CLRDUMP_API __declspec(dllimport) __stdcall

I assume that the __stdcall is OK?

-- Edit 4 --

While I appreciate the efforts of those who answered, particularly ChrisN, at least on my particular system, the link error remains. So if anyone has any further insight, I'd appreciate it. Thanks again.

回答1:

I was creating a simple Win32 c++ application in VS2005 and I was getting this error:

LNK2019: unresolved external symbol __imp__somefunction

This application was using property sheets, hence it required this header (prsht.h).

The solution to my problem was as follows: in program Properties→Configuration Properties→Linker→General, I set Additional Library Directories to "C:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\Lib".

Also in program Properties→Configuration Properties→Linker→Command line for the Additional Options, I added ComCtl32.Lib ComDlg32.Lib.

My program is now compiling without any problems. My two cents: you need to identify all the libraries that your program requires. Hint: check all the headers you have included, you need to make sure that your linker can see them.

回答2:

The __imp_ prefix indicates that the linker expects this function to be imported from a DLL.

Is the clrdump library from this page? If so, note that extern "C" is not used in the header file supplied with the library. I confirmed this using the following command:

dumpbin /exports clrdump.lib

which produces the following output for RegisterFilter - this is a mangled C++ function name:

?RegisterFilter@@YGHPBGK@Z (int __stdcall RegisterFilter(unsigned short const *,unsigned long))

I tried creating a sample program using clrdump.lib using Visual Studio 2008. Here's my code:

#include <windows.h>
#include "ClrDump.h"

int _tmain(int argc, _TCHAR* argv[])
{
    RegisterFilter(L"", 0);
    return 0;
}

Building this produced the following linker error:

LNK2019: unresolved external symbol "__declspec(dllimport) int __stdcall RegisterFilter(wchar_t const *,unsigned long)" (__imp_?RegisterFilter@@YGHPB_WK@Z)

The code builds OK with Visual C++ 6.0.

Notice that the dumpbin output shows the first parameter to RegisterFilter as unsigned short const * but the linker error shows wchar_t const *. In Visual C++ 6.0, wchar_t is normally a typedef for unsigned short, whereas in later versions it is a distinct built-in type.

To work around the problem in Visual Studio 2008, I set the "Treat wchar_t as Built-in Type" option to "No" (specify /Zc:wchar_t- on the compiler command line), and the code now builds OK.

Sorry for the confusion with my previous answer. I hope this is more helpful!

回答3:

I recently had the same problem. I was excluding a library to avoid a collision, and all the bugs went away, except for LINK errors (just as you describe). When I swapped the library for the other one (I was excluding (ignoring) MSVCRT.lib, now I'm excluding (ignoring) LIBCMT.lib) the problem disappeared. Make sure you have not mixed libraries up somewhere. In my case, the linker was failing with "can't find imp_aligned_malloc". Of course there was no method in any of my code by that name. The compiler was prepending the imp. Exactly why I don't know, except that the problem went away when I swapped the exclude (ignore) as described above.

Try starting with a fresh project, and re-add your source & header files, and keep track of the libraries you exclude (ignore). Try various combinations. Hope that helps.

回答4:

Try turning on verbose output for your linker (typically a command-line switch). That will show you exactly how the linker is trying to resolve the symbol, so you can see if:

• the symbol's signature is what you expect
• the linker is looking in the right location for your library

I hope this helps!

回答5:

Don't know if it is your case, but the imp prefix may mean that you are compiling a x64 library in a Win32 project.

回答6:

Using a .DEF File

If you choose to use __declspec(dllimport) along with a .DEF file, you should change the .DEF file to use DATA or CONSTANT to reduce the likelihood that incorrect coding will cause a problem:

// project.def
LIBRARY project
EXPORTS
   ulDataInDll   CONSTANT

The following table shows why:

Keyword      Emits in the import library   Exports
CONSTANT     _imp_ulDataInDll              _ulDataInDll
             _ulDataInDll                  

DATA         _imp_ulDataInDll              _ulDataInDll

http://msdn.microsoft.com/en-us/library/aa271769(v=vs.60).aspx