I want to use the source code of the CvCaptureFromFile(..) function as I do not want to use OpenCV library functions in my project. So I went inside the function by pressing F10,F11 and I copied the things I needed and converted them into C code. Till now everything was ok.
But when I tried to run I am getting linking error inside the function icvIntFFMPEG(void)
the errors are as follows:
Error 1 error LNK2019: unresolved external symbol
"__declspec(dllimport) void * __stdcall GetProcAddress(struct
HINSTANCE__ *,char const *)"
(__imp_?GetProcAddress##YGPAXPAUHINSTANCE__##PBD#Z) referenced in
function "void __cdecl icvInitFFMPEG(void)" (?icvInitFFMPEG##YAXXZ)
Error 2 error LNK2019: unresolved external symbol "struct HINSTANCE__
* __stdcall LoadLibrary(char const *)" (?LoadLibrary##YGPAUHINSTANCE__##PBD#Z) referenced in function "void
__cdecl icvInitFFMPEG(void)" (?icvInitFFMPEG##YAXXZ)
I copied everything as it is in the source code. Any idea where I am going wrong? How do I solve this error?
UPDATE: IF I wrap the header file (where I was coping the source code) inside an extern "C" something like this-
extern "C" {
#include "defination.h"
}
Then the first error is gone, and the error with loadLibrary changes to
error LNK2019: unresolved external symbol __imp__LoadLibrary#4 referenced in function _icvInitFFMPEG
OpenCv uses ffmpeg - which is a really big project. And ffmpeg uses some other tools behind curtains. You may want to go using ffmpeg, but to take the source code from ffmpeg itself is foolish - you will spend years fiddling with that code - really.
So, decide on a video input library - be it OpenCV, ffmpeg, Direct3D or whatever, and use it.
Do not cling yourself on the idea that 'you cannot use external libraries' because you can't go without them. It takes years to develop such a library - I am pretty sure you do not want to go that way.
Well, it seems your get unresolved calls to LoadLibrary()/GetProcAddress() functions that are inside Kernel32.dll. What IDE/project type are you using? Kernel32.lib should be linked in by default unless /NODEFAULTLIB is specified somewhere, at least as far as I remember. You can try to add #pragma comment(lib, "kernel32.lib") to the file where you copied the code, but without more info about your setup it is hard to answer what is causing this.
Related
I would like to integrate Lua into my current C++ application I build with VisualStudio 2015 (x64 mode).
I grabbed a simple Lua wrapper from here, and the Lua binaries for windows x64 from here (the lua-5.1.5_Win32_dll14_lib.zip one).
Next, I added the include and library path to the project preferences. Works so far in the IDE. However, when I try to compile the code it throws 24 errors (like these first two):
1>LuaScript.obj : error LNK2019: unresolved external symbol "lua_close" referenced in function ""public: __cdecl LuaScript::~LuaScript(void)" (??1LuaScript##QEAA#XZ)".
1>LuaScript.obj : error LNK2019: unresolved external symbol "lua_gettop" referenced in function ""public: void __cdecl LuaScript::clean(void)" (?clean#LuaScript##QEAAXXZ)".
which tells me next to nothing. Seems that the linker is unable to find the library but the includes are working and the path to library is set, too. Any suggestions what I might have missed or should look into? Any hint would be appreciated!
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'm trying to get a UDP connection working for a game I'm making, the input for the socket is read via a second thread, so the game can continue running while it's waiting for messages. I got it to work in a separate project, but when porting it over to my game code I get an Unresolved External Symbol error:
LNK2019: unresolved external symbol "void __cdecl receiveThread(void *)" (?receiveThread##YAXPAX#Z) referenced in function "public: bool __thiscall Network::setupServerUDP(void)" (?setupServerUDP#Network##QAE_NXZ)).
I've googled this and everyone says the Runtime Library should be set to Multi-threaded, which I did (In MVS 2010 I don't think it's even possible to set it to single-threaded) but it doesn't resolve the error.
I'm sure it's just some stupid option set to the wrong thing somewhere. But I just can't think of what it is.
I've included ws2tcpip.h and I've linked to the correct library: #pragma comment(lib, "Ws2_32.lib").
The only difference between my test project and the game project is that the test project was a Console application and the other is a Windows application, but I don't see why that should be any problem. Thoughts?
Thanks for your help!
Cheers,
Maxim
The unresolved function is not _beginthread, it's receiveThread. That's your function - the thread entry point that you provide as a parameter to _beginthread. Did you write that function with the right calling convention? Is it really cdecl? If you declare it as cdecl but implement without an explicit calling convention, that would cause a link error like this. For example, this code would cause a link error:
extern "C" { void receiveThread(void*); } //There's a cdecl function somewhere
//...
_beginthread(receiveThread, 0, 0); //Let's refer to it
//...
void receiveThread(void *p) //But this is not it! It's stdcall.
{
//Do something
}
To fix, make sure your implementation of receiveThread uses the cdecl convention or is declared as extern "C".
For the record, _beginthreadex expects a stdcall function, not cdecl. With _beginthreadex, you don't have to worry about conventions.
The error is telling you that the linker cannot find the implementation for the function receiveThread which I'm guessing is declared in ws2tcpip.h
If Ws2_32.lib contains the implementation, try adding it to linker -> additional dependencies -> inputs under the properties menu for the project, assuming you're using visual studio.
I've been attempting to get DirectDraw to function on a CE5.0 framework for the last week and I'm running into some very odd issues.
ddrval = DirectDrawCreate(NULL, &lpDD, NULL);
When I have this function in my code, I get "error LNK2019: unresolved external symbol _DirectDrawCreate referenced in function "bool __cdecl DirectDrawInit(struct HWND__ *)" (?DirectDrawInit##YA_NPAUHWND__###Z)"
The function itself exists in the .h, as I can jump directly to it, which makes me think I'm missing a library, but I have no idea how to check or fix this as it is being built for a remote CE5.0 device. I also run into a few other subtile hints that I am missing something such as LR_CREATEDIBSECTION and other LR constants not existing and small differences in types (HBITMAP not being liked and LPCWSTR being prefered).
Any assistance would be greatly appreciated. Just as a note, WindowsMobile5.0 code doesn't work on the device, and if I comment out the offending function the code compiles and runs (it's not being used as DirectDrawCreate is kind of important but the LNK error goes away)
You should link your program with ddraw.lib. This is the import lib for direct draw on windows mobile.
I am using a library of code from a tutorial for providing functionality for passing function points of non-static member functions to a function that expects a static function pointer, probably helps to know what I am suing, so here is the link http://www.codeproject.com/KB/cpp/thunk32.aspx This code uses the Boost library, which I have downloaded and set-up more or less everything from.
In the Thunk library, one of the header files has a section that reads
#define BOOST_PP_ITERATION_PARAMS_1 (3,(0,THUNK32_MAX_ARGS,"Thunk32_template.h"))
??=include BOOST_PP_ITERATE()
#undef BOOST_PP_ITERATION_PARAMS_1
but this gives me epic amounts of errors, which I can solve by changing it to
#define BOOST_PP_ITERATION_PARAMS_1 (3,(0,THUNK32_MAX_ARGS,"Thunk32_template.h"))
#include BOOST_PP_ITERATE()
#undef BOOST_PP_ITERATION_PARAMS_1
This code that is downloaded is included in my solution as a second project, which is able to compile and build happily. But my project that is using this code has issues linking, to save people asking, I get these error messages
1>WebCamera.obj : error LNK2019: unresolved external symbol "protected: __thiscall indev::Thunk32Base::Thunk32Base(void)" (??0Thunk32Base#indev##IAE#XZ) referenced in function "public: __thiscall indev::Thunk32<class WebCamera,void __cdecl(struct HWND__ *,struct videohdr_tag *)>::Thunk32<class WebCamera,void __cdecl(struct HWND__ *,struct videohdr_tag *)>(void)" (??0?$Thunk32#VWebCamera##$$A6AXPAUHWND__##PAUvideohdr_tag###Z#indev##QAE#XZ)
1>WebCamera.obj : error LNK2019: unresolved external symbol "protected: __thiscall indev::Thunk32Base::~Thunk32Base(void)" (??1Thunk32Base#indev##IAE#XZ) referenced in function "public: __thiscall indev::Thunk32<class WebCamera,void __cdecl(struct HWND__ *,struct videohdr_tag *)>::~Thunk32<class WebCamera,void __cdecl(struct HWND__ *,struct videohdr_tag *)>(void)" (??1?$Thunk32#VWebCamera##$$A6AXPAUHWND__##PAUvideohdr_tag###Z#indev##QAE#XZ)
1>WebCamera.obj : error LNK2019: unresolved external symbol _capCreateCaptureWindowA#32 referenced in function "public: bool __thiscall WebCamera::Init(struct HWND__ *)" (?Init#WebCamera##QAE_NPAUHWND__###Z)
I think this is trying to say that the constructor and destructor are not declared and that my WebCamera.Init()is messed up as well. I have made sure that the library that the Thunk32 project exports is included in my other project, but still I get these errors.
I would like to know if I have made the correct assumption that ??=include should have been changed to #include and if I have, what have I done wrong or failed to do that results in these linker errors. Or if you can provide me with a different way of being able to pass a function pointer to a non-static member function that would be awesome.
Thanks
??= is a "trigraph" sequence for the # character. according to the standard, trigraphs are supposed to be handled as one of the first steps in processing (in phase 1 - before the preprocessor handles directives),so:
??=include "whatever"
Should be equivalent to:
#include "whatever"
so you should be able to use that form (I wonder why the trigraph was put there in the first place - some sort of evil joke perhaps?)
However, trigraphs cause problems and confusion (probably more than they help), so compilers seem to be moving towards warning about them and/or defaulting to not handling them. The compiler in VS 2010 has trigraph processing turned off by default - you have to use the /Zc:trigraphs option to turn it on.
See Purpose of Trigraph sequences in C++? for more details.
Ah, Einar, good man. Doing flash and Sharepoint stuff these days, ouch. Norwegian, might explain the trigraphs.
Anyhoo, nothing complicated, you just forgot to tell the linker to look at some libraries. Right-click your project, Project Dependencies, tick the Thunk project. That makes sure that Thunk32.lib gets looked at and resolves the ctor and dtor.
Right-click again, Properties, Linker, Additional dependencies, add "winmm.lib". That resolves the capCreateCaptureWindow symbol.
Do you have a constructor and a destructor declared in the indev::Thunk32Base class that you forgot to define in its cpp file?
Ok, so I have managed to solve this now.
Michael Burr nicley said that ??= is basically the same as typing # but in a way that people who dont have the hash symbol can type it, see Purpose of Trigraph sequences in C++?
Hans Passant then got the ball rolling for me buy letting me know that I had not fully linked in stuff. I needed to right click on my main project, select 'Project Dependencies' and select my other project that has the thunk32 code. I also needed to tell my main project to look at where the Thunk project is saving the lib, which turned out to be in a folder in my documents (explain that one!). I also needed to add the Thunk32d.lib (note the 'd' because I was/am in debug mode. Hans said that I needed winmm.lib but it turned out (when googling the function that was giving me the error that I needed Vfw32.lib instead.
Thanks guys! I hope that by giving the full answer like this it can help some one else who has a similar problem.