I'm seeing the following error message when attempting to link
a library in one project against another in the same solution:
CPTemplate.obj : error LNK2019: unresolved external symbol "public: long __thiscall MPADOFieldList::GetField(wchar_t *,struct Field * *)" (?GetField#MPADOFieldList##QAEJPA_WPAPAUField###Z) referenced in function "public: virtual long __stdcall CCPTemplate::GetRootStorage(struct IMPRootStore * *)" (?GetRootStorage#CCPTemplate##UAGJPAPAUIMPRootStore###Z)
Using 'dumpbin /symbols' on the static library that I'm linking
against reveals a different symbol for the 'GetField' method:
?GetField#MPADOFieldList##QAEJPA_WPAPAUADOField###Z (public: long __thiscall MPADOFieldList::GetField(wchar_t *,struct ADOField * *))
Clearly the difference is 'Field' vs. 'ADOField'. 'Field' is defined
in a referenced header :
typedef interface ADOField Field;
The declaration of the 'GetField' method is as follows:
HRESULT GetField( BSTR bstrFieldName, Field** rpField );
This is almost certainly down to one of two things, eitherthe typedef being conditional, and for the lib it takes one branch while in the main project it takes the other. However, as the type resolves Field in the main project I have a more plausible theory. The header that contains the GetField declaration has a forward declaration for Field, the typedef however is not seen in this TU at all so it's assumed to be a type which will be defined elsewhere ( causing the first link ). In the library however the typedef is seen and correctly resolved to ADOField, causing the mismatch. The solution is to make sure that the typedef is seen in the TU that contains the definition for CCPTemplate::GetRootStorage.
Related
I am trying to link a dll library to my current project. The library is linked and read but when i am trying to call this specific function its giving me a linker error specifying the input parameter is unsigned uchar * whereas i have BYTE* as the input parameter in the function and also on the call.
error LNK2019: unresolved external symbol "public: void __thiscall C_projectApp::
detect(unsigned char *,struct _tagInfo *)"
whereas the function definition is
void detect(BYTE* inp_ , Blob_Info*_info)
Any suggestions about it ?
Disclaimer: there is a high chance this is very specific to Unreal Engine, but I haven't got an answer there so I thought I'd try a more general query here. Sorry if this is considered off topic/too specific
I am getting a link error compiling the following code in Unreal Engine 4:
RHISetRenderTarget(TextureRenderTarget->GetRenderTargetTexture(), NULL);
This is being called within a macro (ENQUEUE_UNIQUE_RENDER_COMMAND_TWOPARAMETER) but the link error happens even if you don't.
The error itself is:
MaterialToTextureRenderer.cpp.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) void __cdecl RHISetRenderTargets(unsigned int,class FRHIRenderTargetView const *,class FRHITexture *,unsigned int,class FRHIUnorderedAccessView * const *)" (__imp_?RHISetRenderTargets##YAXIPEBVFRHIRenderTargetView##PEAVFRHITexture##IPEBQEAVFRHIUnorderedAccessView###Z) referenced in function "void __cdecl RHISetRenderTarget(class FRHITexture *,class FRHITexture *)" (?RHISetRenderTarget##YAXPEAVFRHITexture##0#Z)
Compressed for readability:
unresolved external symbol: void RHISetRenderTargets(unsigned int, FRHIRenderTargetView const *,FRHITexture *,unsigned int,FRHIUnorderedAccessView * const *)
referenced in: void RHISetRenderTarget(FRHITexture *,FRHITexture *)
(The method the unlinked method is referenced in is the method I am calling).
And 4 other simillar link errors.
I'm not by any stretch of the imagination a C++ expert, but my understanding is a link error is caused when the header file is correctly included but then it can't actual find an implementation of the method to point to.
What I don't understand is, the method whose implementation it can't find, is within the Unreal Engine (which I am assuming doesn't actually have missing method implementations etc!).
Further, both the method I am calling, and the method it is calling (and can't link) are both defined inline in the same header file. The only thing I can see that could be wrong is the method that is being used is declared and implemented further down the header file, but I don't believe that could be a problem (certainly not a link problem).
Be sure that you include RHI and RenderCore in your .build.cs for your target like this
PublicDependencyModuleNames.AddRange(new string[] { "Core", "CoreUObject", "Engine", "InputCore", "RHI", "RenderCore", "ShaderCore" });
I have a third party libs. (msvc10) a MT/MD (Static cfgs's) and dynamic DLL cfg.
I have qt + msvc10 express + win sdk.7
Ok , I use the existing examples offered, (using the libs) I can't compile ..... I have 4 unresolved external errors of the same lib.
(But I have zero errors for the others)
I have not support for these lib...... (but they are legal, I am a member without rights)
Which are the steps to investigate a possible fix? Where I have to look ?
Thanks.
Edit 1:
The errors was:
TD_ExamplesCommon.lib(ExHostAppServices.obj) : error LNK2019: unresolved external symbol __imp__RegEnumValueW#32 referenced in function "public: virtual bool __thiscall ExHostAppServices::ttfFileNameByDescriptor(class OdTtfDescriptor const &,class OdString &)" (?ttfFileNameByDescriptor#ExHostAppServices##UAE_N ABVOdTtfDescriptor##AAVOdString###Z)
TD_ExamplesCommon.lib(ExHostAppServices.obj) : error LNK2019: unresolved external symbol __imp__RegCloseKey#4 referenced in function "public: virtual bool __thiscall ExHostAppServices::ttfFileNameByDescriptor(class OdTtfDescriptor const &,class OdString &)" (?ttfFileNameByDescriptor#ExHostAppServices##UAE_N ABVOdTtfDescriptor##AAVOdString###Z)
TD_ExamplesCommon.lib(ExHostAppServices.obj) : error LNK2019: unresolved external symbol __imp__RegQueryValueExW#24 referenced in function "public: virtual bool __thiscall ExHostAppServices::ttfFileNameByDescriptor(class OdTtfDescriptor const &,class OdString &)" (?ttfFileNameByDescriptor#ExHostAppServices##UAE_N ABVOdTtfDescriptor##AAVOdString###Z)
TD_ExamplesCommon.lib(ExHostAppServices.obj) : error LNK2019: unresolved external symbol __imp__RegOpenKeyExW#20 referenced in function "public: virtual bool __thiscall ExHostAppServices::ttfFileNameByDescriptor(class OdTtfDescriptor const &,class OdString &)" (?ttfFileNameByDescriptor#ExHostAppServices##UAE_N ABVOdTtfDescriptor##AAVOdString###Z)
..\exe\OdaQtApp.exe : fatal error LNK1120: 13 unresolved externals
During this post I have received a solution: I have to link with Advapi32.lib...
My question is : how can I know this ?
I have tried the dependencyywalker, but it cant use the .lib's....
During this post I have received a solution: I have to link with Advapi32.lib... My question is : how can I know this?
When you get an "unresolved external" error from the linker, that means that it was looking for a match for a function or variable name that some object file needs and the linker was unable to find that name defined in one of the object files or libraries.
Start by looking at the first of these errors (I've reformatted it a bit to make it slightly more readable - I encourage yo to do the same next time you come across one of these):
TD_ExamplesCommon.lib(ExHostAppServices.obj) : error LNK2019: unresolved external symbol
__imp__RegEnumValueW#32 referenced in function
"public: virtual bool __thiscall ExHostAppServices::ttfFileNameByDescriptor(
class OdTtfDescriptor const &,class OdString &)"
(?ttfFileNameByDescriptor#ExHostAppServices##UAE_N ABVOdTtfDescriptor##AAVOdString###Z)
There's a lot of stuff in that error message (much of it may look like garbage). Fortunately, much of it can be ignored in most cases. The most important item is that the linker is looking for the symbol __imp__RegEnumValueW#32 The name has some gunk on it, but fortunately it's pretty recognizable anyway.
the __imp__ prefix indicates it's looking for a DLL import. In nearly all cases that can be ignored for your purposes.
the #32 suffix is something the Microsoft compiler adds to function names for certain calling conventions. It's also generally not important for your purposes (for the record it indicates that the function expects 32 bytes of argument data)
So we're left with the fact that the linker is looking for RegEnumValueW. That looks a lot like the name of a Win32 API.
If you look at the docs for RegEnumValueW (or RegEnumValue, since many Win32 APIs have both an A and a W variant to handle ANSI/UNICODE builds) we'll find in the documentation this bit of information:
Requirements
Minimum supported client Windows 2000 Professional
Minimum supported server Windows 2000 Server
Header Winreg.h (include Windows.h)
>> Library Advapi32.lib
DLL Advapi32.dll
Unicode and ANSI names RegEnumValueW (Unicode) and
RegEnumValueA (ANSI)
That's how you know you need advapi32.lib.
So in the future, when you get an "unresolved external" error from the linker, just ignore most of the gunk in the error message and concentrate on the symbol it says it can't find - that should lead you to the library, object file or other item you might be missing.
Just for the record, advapi32.lib will be needed by most Windows applications of any complexity.
you can try to use dependencywalker to see the list of dependencies for your dlls and see what it's missing.
have you entered the *.lib file in the linker options? (input --> additional dependencies"), and in addition the path to the .lib in libraries directories option?
HI I'm an internship student and my job is porting a program from linux c to visual c.
I've to use Berkeley DB and Visual C++.
after trying for a while, i get the linking error
berkeleyDB.obj : error LNK2019: unresolved external symbol "int __cdecl database_select_end(unsigned int,unsigned int,struct chunk * const,int)" (?database_select_end##YAHIIQAUchunk##H#Z) referenced in function "void __cdecl op_ds_bulk(unsigned int,unsigned int *,int)" (?op_ds_bulk##YAXIPAIH#Z)
berkeleyDB.obj : error LNK2019: unresolved external symbol "void __cdecl database_sync(void)" (?database_sync##YAXXZ) referenced in function "void __cdecl op_ds_bulk(unsigned int,unsigned int *,int)" (?op_ds_bulk##YAXIPAIH#Z)
berkeleyDB.obj : error LNK2019: unresolved external symbol "void __cdecl database_insert_bluk(struct chunk *,int)" (?database_insert_bluk##YAXPAUchunk##H#Z) referenced in function "void __cdecl op_ds_bulk(unsigned int,unsigned int *,int)" (?op_ds_bulk##YAXIPAIH#Z)
berkeleyDB.obj : error LNK2019: unresolved external symbol "int __cdecl database_open(int,char *)" (?database_open##YAHHPAD#Z) referenced in function _main
no idea what are those,
pls help me
They're C++-mangled (or 'decorated') function names. C++ allows function overloading - multiple functions with the same name but with different parameter signatures - and so it needs to encode the parameters etc. into the function name to differentiate the multiple overloads at link time. Most likely your DB library was built as C and won't have decorated names.
Try wrapping your db.h include in an extern "C"
extern "C"
{
#include <db/db.h>
}
to tell the compiler to treat the API as C functions, not C++.
(It looks like you've got a typo in there too: database_insert_bluk not _bulk.)
Alternatively, it looks like Berkeley DB ship a C++ interface #include <db/db_cxx.h> you could use instead, although if you're porting code it may be easier to stick to the C interface. The difference is probably that the Linux code you're porting was compiled as C whereas here you're compiling it as C++.
From the other comment you've posted: if your problem is that you're actually not linking in Berkeley DB at all then you'll need to go into project settings (right-click on the project name), the C++ link tab, and then add the .lib file to the list of libraries to link into your project. You may need to specify the path to find this too, and you should do this for both debug and release modes (the drop down at the top of the settings).
I'm not very experienced in C++, and when I have to work with another library and I get link errors, I'm completely in the dark on what the compiler is trying to tell me (other than it can't find something reference somewhere).
Are there any good links that describe, in detail, the meaning of the symbols and characters in a link error message? Or how to trouble shoot such errors?
For example, this is a link error I received recently:
testproj error LNK2019: unresolved
external symbol "public: __thiscall
google::protobuf::internal::GeneratedMessageReflection::GeneratedMessageReflection(class
google::protobuf::Descriptor const
*,class google::protobuf::Message const *,int const *
const,int,int,int,class
google::protobuf::DescriptorPool const
*,int)" (??0GeneratedMessageReflection#internal#protobuf#google##QAE#PBVDescriptor#23#PBVMessage#23#QBHHHHPBVDescriptorPool#23#H#Z)
referenced in function "void __cdecl
testproj::protobuf_BuildDesc_def_2eproto_AssignGlobalDescriptors(class google::protobuf::FileDescriptor const
*)" (?protobuf_BuildDesc_def_2eproto_AssignGlobalDescriptors#testproj##YAXPBVFileDescriptor#protobuf#google###Z)
The symbols are the "mangled" versions of the function names. Basically because of c++ overloading (2 functions with different signatures can have the same name). The signature information is encoded into the name.
The message you pasted has both the encoded and plain text versions.
public: __thiscall google::protobuf::internal::GeneratedMessageReflection::GeneratedMessageReflection(class google::protobuf::Descriptor const *,class google::protobuf::Message const *,int const * const,int,int,int,class google::protobuf::DescriptorPool const *,int)
?0GeneratedMessageReflection#internal#protobuf#google##QAE#PBVDescriptor#23#PBVMessage#23#QBHHHHPBVDescriptorPool#23#H#Z)
are the same thing, just the later is mangled.
Notice that the mangled version starts with:
?0GeneratedMessageReflection#internal#protobuf#google
which corresponds nicely with:
google::protobuf::internal::GeneratedMessageReflection
Because the first few lines give you the relevant information, you can pretty much ignore the mangled versions. The plain text versions of the signatures are sufficient to fix the linker error.
Unresolved externals mean you are trying to call a function in another DLL, but you haven't linked to that DLL's LIB file.
It is usually pretty simple figuring out how to resolve these linker errors. The error message tells you exactly what you need to know:
google::protobuf::internal::GeneratedMessageReflection::GeneratedMessageReflection(class
google::protobuf::Descriptor const
*,class google::protobuf::Message const *,int const *
const,int,int,int,class
google::protobuf::DescriptorPool const
*,int)"
This looks like you are trying to use a class named "GeneratedMessageReflection" in a google library. Find out what library provides this class and then go in to your compilers linker settings & add an "Additional Reference" to that library's LIB file.