I've converted a project to VS2010. It includes a googletest based unit test project. When I use the macro EXPECT_EQ, I get the following linker error:
LNK2019: unresolved external symbol "class testing::internal::String
__cdecl testing::internal::StrStreamToString(class std::basic_stringstream,class
std::allocator > *)" (?StrStreamToString#internal#testing##YA?
AVString#12#PAV?$basic_stringstream#DU?$char_traits#D#std##V?
$allocator#D#2##std###Z) referenced in function "public: class
testing::internal::String __thiscall
testing::Message::GetString(void)const " (?
GetString#Message#testing##QBE?AVString#internal#2#XZ)
When I use EXPECT_TRUE, everything works fine. Does anybody know about this issue?
Thank you
EXPECT_EQ attempts to convert your data values into strings for display purposes; EXPECT_TRUE does not.
Without seeing your code, it would appear that you are testing a user type for which this functionality can be compiled but not linked ie is not implemented.
This is a common problem. If EXPECT_TRUE works, you might just want to stick to it.
Related
So I have been trying to learn Vulkan lately, and while trying to get the validation layers to work, I got error LNK2019:
1>Renderer.obj : error LNK2019: unresolved external symbol vkCreateDebugReportCallbackEXT referenced in function "private: void __cdecl Renderer::_InitDebug(void)" (?_InitDebug#Renderer##AEAAXXZ)
Now the odd thing is that every other function in vulkan.h works perfectly.
I have vulkan-1.lib linked, and I run the AMD implementation of vulkan. The library is from the Vulkan SDK.
The debugging functions from debug_report_ext are not part of the Vulkan core. You need to dynamically load them from the instance via vkGetInstanceProcAddr after making sure that it's actually supported:
PFN_vkCreateDebugReportCallbackEXT CreateDebugReportCallback = VK_NULL_HANDLE;
CreateDebugReportCallback = (PFN_vkCreateDebugReportCallbackEXT)vkGetInstanceProcAddr(instance, "vkCreateDebugReportCallbackEXT");
See my Vulkan debugging helper unit for details.
I have been stuck with a MFC-related problem for quite some time now. I have read through many forums, VTK-Users posts, etc. without any luck.
My basic problem is that vtkMFC.lib is not getting built; no matter how I build my project or configure it.
These are the steps I have followed:
Generate VTK.sln using CMake 2.8.9 with VTK_USE_GUISUPPORT, BUILD_SHARED_LIBS, VTK_USE_MFC, BUILD_EXAMPLES turned ON and VTK_USE_VIDEO_FOR_WINDOWS turned OFF.
Open VTK.sln on VS-2008 and build ONLY vtkMFC.sln.
Build entire solution.
{I have also tried with points 2 and 3 inter-changed with no result}
There are 6 erros; of which 3 are to do with the fact that vtkMFC.lib isn't there (for the examples. obviously). The rest are regarding a couple of resolved external symbols,
error LNK2019: unresolved external symbol "__declspec(dllimport) public: static class vtkDataSetReader * _cdecl vtkDataSetReader::New(void)" (_imp_?New#vtkDataSetReader##SAPAV1#XZ) referenced in function "protected: __thiscall CSampleDoc::CSampleDoc(void)" (??0CSampleDoc##IAE#XZ) in SampleDoc.obj
error LNK2019: unresolved external symbol "__declspec(dllimport) public: class vtkDataSet * _thiscall vtkDataSetReader::GetOutput(void)" (_imp_?GetOutput#vtkDataSetReader##QAEPAVvtkDataSet##XZ) referenced in function "public: virtual int __thiscall CSampleDoc::OnOpenDocument(char const *)" (?OnOpenDocument#CSampleDoc##UAEHPBD#Z) in SampleDoc.obj
The files generated in Debug/bin for vtkMFC solution are vtkMFC.dll, vtkMFC.idb, vtkMFC.ilk, vtkMFC.pdb.
I have also added vtkIO.lib to the projects that generated the error and the same erros continue along with another which says that vtkIO.lib isn't found.
Any help in this regard would be much appreciated.
Best,
Sarthak
Answer as of February 2013:
Turns out, there is some issue with VTK 5.10.1. Using 5.8.0 solved the problem.
Certain things to be kept in mind while building VTK from CMake:
If BUILD_SHARED_LIBS is selected (i.e., you want DLLs to be generated), then make sure all flags are set to /MD. If BUILD_SHARED_LIBS is unselected (i.e., you don't want DLLs to be generated and are linking via static libs), then make sure all flags are set to /MT.
I have C++ code running well with XULRunner from 7 up to 11 versions:
nsRefPtr<gfxWindowsSurface> targetSurface = new gfxWindowsSurface(hDC, gfxWindowsSurface::FLAG_FOR_PRINTING);
nsRefPtr<gfxContext> ctx = new gfxContext(targetSurface);
But when I tried to compile it with XULRunner 12 and later, it cause linkage errors:
error LNK2019: unresolved external symbol "public: __thiscall gfxContext::gfxContext(class gfxASurface *)" (??0gfxContext##QAE#PAVgfxASurface###Z)
error LNK2019: unresolved external symbol "public: __thiscall gfxWindowsSurface::gfxWindowsSurface(struct HDC__ *,unsigned int)" (??0gfxWindowsSurface##QAE#PAUHDC__##I#Z)
I've make dumpbin for xul.lib and found that there are no any exports for THEBES API now. They were removed when SDK change version from 11 to 12.
Is it way to use gfxWindowsSurface and gfxContext in binary XPCOM in the latest xulrunner sdk`s?
Thanks,
Serge
The relevant change is bug 683891, also see bug 718985 for extended discussion. It seems that allowing third parties access graphics code directly is no longer considered desirable. So the answer to your question is: no, you can no longer do this with the stock XULRunner. So you can either look for alternative ways to achieve your goal (e.g. higher level drawing surfaces like <canvas> as suggested in the bug) or you can create your own XULRunner build with this particular patch reverted.
I have a problem with SHGetFolderPathA in Visual Studio 2010 (Windows Forms).
I included to project ShlObj.h and added for button this code:
char SciezkaCookies[MAX_PATH];
HRESULT hr = ::SHGetFolderPathA(0, CSIDL_APPDATA, 0, SHGFP_TYPE_DEFAULT, SciezkaCookies);
But when i try compile my project, Visual return errors:
error LNK2028: unresolved token (0A000012) "extern "C" long stdcall
SHGetFolderPathA(struct HWND *,int,void *,unsigned long,char *)"
(?SHGetFolderPathA##$$J220YGJPAUHWND__##HPAXKPAD#Z) referenced in
function "private: void __clrcall VoxPopuli::Form1::start_Click(class
System::Object ^,class System::EventArgs ^)"
(?start_Click#Form1#VoxPopuli##$$FA$AAMXP$AAVObject#System##P$AAVEventArgs#4##Z)
and
1>VoxPopuli.obj : error LNK2019: unresolved external symbol "extern
"C" long stdcall SHGetFolderPathA(struct HWND *,int,void
*,unsigned long,char *)" (?SHGetFolderPathA##$$J220YGJPAUHWND__##HPAXKPAD#Z) referenced in
function "private: void __clrcall VoxPopuli::Form1::start_Click(class
System::Object ^,class System::EventArgs ^)"
(?start_Click#Form1#VoxPopuli##$$FA$AAMXP$AAVObject#System##P$AAVEventArgs#4##Z)
I'm looking for solutions in google, but all examples is not working ;/
Thanks for help!
Calling native winapi functions like SHGetFolderPath() is fine from C++/CLI, that's what the language is good at, but you do have to keep the linker happy yourself. Use the MSDN Library article for the function (not today, site has been down all week). At the bottom of the article it lists "Header", that's how you found out that you needed to tell the compiler about shlobj.h. It also lists "Import library", that's what you need to tell the linker. The import library tells the linker what DLL needs to be loaded at runtime to call the function.
Project + Properties, Linker, Input, Additional Dependencies. Add "shell32.lib"
Or you do it in your source code with a #pragma, a way to pass link instructions to the linker:
#include <shlobj.h>
#pragma comment(lib, "shell32.lib")
It should be said, this is definitely one api function that you really want somebody else to have to deal with. Note how the MSDN Library article also says that the function is deprecated. There's been a lot of flux in standard folder paths across Windows versions. You have the "someone else" readily available in a .NET app, Environment::GetFolderPath() does this for you. Also saves you from the hassle of having to deal with different string types.
You must have declared it yourself to avoid including the Windows headers- not that I blame you for doing that- but you have mangled the name, so the linker cannot resolve it from the native library.
Oh, you're in C++/CLI? Maybe the compiler flat out won't like the native call into managed code, then.
I'd avoided using native functions if .NET solution is possible. Try to use
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData));
Both native and .NET approaches are discussed here:
http://bytes.com/topic/c-sharp/answers/269259-my-documents-path-c
I am trying to use PhysX character kinematic, but I got to problem right at start. When I create the controller manager like this:
nxManager = PxCreateControllerManager( *nxFoundation );
which is at the end of my PhysX initialization function, but I get error:
LNK2019: unresolved external symbol __imp__PxCreateControllerManager referenced in function "void __cdecl InitPX(void)" (?InitPX##YAXXZ)
I do have PhysX3CharacterKinematic.lib linked in, I have tried rebuilding it from the SDK with various options (debug, release, ...) but I still can't get it to work. Any idea what might be wrong there? I am running PhysX SDK 3.1.2