OpenCV 2.3 with Qt 4.3.7 - c++

I have successfully build and ran both Qt 4.3.7 and OpenCV 2.3 with Qt enabled. When I start a window using:
cvNamedWindow( "video", 0 );
I successfully load a full Qt interface! wonderful :)
However!! when I use the command
void callbackButton(int state, void* userdata){
int x;
x=3;
}
cvCreateButton(nameb2,callbackButton,nameb2,CV_CHECKBOX,0);
I get the error message
error LNK2001: unresolved external symbol _cvCreateButton
I don't understand as the Qt interface already has lots of buttons on it? could someone please explain what I am missing from the include that could cause this?
Thanks!

You use the wrong parameters for to call to cvCreateButton. According to the documentation here the signature of the function is
cvCreateButton(const char* button_name CV_DEFAULT(NULL), CvButtonCallback on_change CV_DEFAULT(NULL), void* userdata CV_DEFAULT(NULL), int button_type CV_DEFAULT(CV_PUSH_BUTTON), int initial_button_state CV_DEFAULT(0)
and sample calls are:
cvCreateButton(NULL,callbackButton);
cvCreateButton("button2",callbackButton,NULL,CV_CHECKBOX,0);
cvCreateButton("button3",callbackButton,&value);
cvCreateButton("button5",callbackButton1,NULL,CV_RADIOBOX);
cvCreateButton("button6",callbackButton2,NULL,CV_PUSH_BUTTON,1);
and the declaration of the callback function has to be:
CV_EXTERN_C_FUNCPTR( *CvButtonCallback)(int state, void* userdata));
You get a linking error and not a compiler error because cvCreateButton has extern "C" linkage - which means that parameters cannot be checked at compile time.

I solved this issue by calling the function cv::createButton instead of cvCreateButton (which is if I am correct the way to call methods in OpenCV2).

The third argument must be a void*. Change to:
cvCreateButton(nameb2,callbackButton,NULL,CV_CHECKBOX,0);
and it will work.
Edit
The statement above was given an error.
The third needed argument is a "void *" - this is compatible with anything and thus neither C nor C++ should have a problem with what you were providing. You can not raise a linker error with that.
The only reason a linker error can be raised by coding is when you don't use prototypes (forgot to use the header file) in C++ and then C++ creates a mangled name on its own that wont be part of any library. In such a case the compiler will first tell you with a warning at compile time that you are missing the prototype (for C and C++) - and then the linker will probably raise an error (for c++ only).
If you don't see a prototype warning from the compiler then that is not your problem.

This is a linking error.
Try to add the opencv .lib file (or files) to the project libraries path.
This may help : VS2010 OpenCV.
Edit
Refined problem: Even if adding any OpenCV libary to your project the linking will fail.
Reason: The symbol is often simply not there in the libraries.
Solution: You have to change a few settings and compile them on your own.
See also: openCV 2.2 createButton LNK 2019 error in Visual Studio 2010

Related

LNK2005 & LNK1169 error when use QMap between 2 dlls

I have an issue since 2days about an LNK2005 & LNK1169 error on MSVC 2015 (Qt 5.12.6)
My error is:
Core.lib(Core.dll) : error LNK2005: "public: __cdecl QMap<int,double>::~QMap<int,double>(void)" (??1?$QMap#HN##QEAA#XZ) already defined in xxx.obj
I have the error when i'm trying to compile a library (named AAA)
The library AAA use Core.dll and both use a 2nd lib named Common.dll. The type QMap<int,double> is used in each libraries.
When i'm looking xxx.obj (located in AAA), the only one usage i have of QMap<int,double>, is when i'm use a function that return a QMap and located in Core.dll
I have lot of function defined in Core and used in AAA but i never seen this error before.
I have check multiple things: trying to change the QMap with QVector, same type of error.
I don't have any "include cpp file"
I don't have the error when i'm using Clang or GCC to compile the project.
I don't have the error if i'm using a QMap<int,double>*, but i don't want to
I think it's an error related to the qmap template but i'm not sure
Do you have an idea? Thanks
Ps: i'v change the name of third lib (AAA) cause this is a code i use for my work and cannot share lot of things about it
So, i have fix my pb by replacing each usage of QMap<int, double> by another object located in a third library.
I have seen multiple definition of QMap<int, double> in the dlls by using Dependency Walker and that why the code counln't compile.
But I don't know if is a problem with the compiler (MSVC2015) or with my code.
I have used these website to help me:
https://forum.qt.io/topic/43408/error-lnk2005-when-deriving-from-qvariantmap
http://web.archive.org/web/20090323151858/https://mareq.com/2008/10/exporting-non-template-class-inherited.html

error LNK2001: unresolved external symbol (every static member of SFML library can't be loaded)

So, I have problem, when try to use any of static members of SFML Library like sf::RenderState::Default or sf::Color::Blue.
error LNK2001: unresolved external symbol "public: static class sf::RenderStates const sf::RenderStates::Default" (?Default#RenderStates#sf##2V12#B)
But when I comment lines, I have access to sf::window (it be created, but can't draw anything, because sf::Drawble has sf::RenderState::Default as standart argument).
I checked everything including linker and compiler in Solution properties in Visual Studio (I have VS19).
P.S. I use the latest version of SFML (2.5.1) and Visual C++20.
Thanks for your help.
The troubleshooting steps I would undertake in this situation go from easiest to the inverse of that.
If I check the declaration of sf::RenderState::Default, can it be found?
If I create a new project with just this feature used, does the error persist?
If I redo my linking and directory searches, is the problem fixed?
Do I have a version compatible with my compiler?
Furthermore, the amount of information you've given about your environment is not enough to speculate on what the issue could be. It might be helpful to post your version of SFML, your compiler (and kind), what your project is like (shorthand.)
SFML can be compiled from source if necessary. Sometimes, using an incompatible version on accident will not show any issues on many basic things until you run into weird errors.
See this document on compiling SFML from source:
https://www.sfml-dev.org/tutorials/2.5/compile-with-cmake.php
So, thanks for AlixianaBritmonkey, I managed with this problem. I just create new project and moved every file. I don't know why problem occured before, but my solution helped.

What / where is __scrt_common_main_seh?

A third party library in my program is trying to call __scrt_common_main_seh by way of the Microsoft library msvcrt.lib, but is defined by some unknown library and therefore gives a linker error. I don't know what this function is supposed to do or where it is defined.
I looked online for this function, but did not find any clues except for general descriptions of what linker errors are.
I believe it might be doing some setup for win32 GUI applications. The library which defines it might be configured as project dependency by Visual Studio but my project is using Bazel.
Summary
For non-console applications having error error LNK2019: unresolved external symbol main referenced in function "int __cdecl __scrt_common_main_seh(void)" try adding linker flag /ENTRY:wWinMainCRTStartup or /ENTRY:WinMainCRTStartup
For console applications having that error, make sure to implement a main() function.
Details
This answer shows that __scrt_common_main_seh is normally called during mainCRTStartup which is the default entry point for windows console applications. __scrt_common_main_seh is then (indirectly) responsible for calling main().
My program did not have a main() function, which might have prevented the compiler from generating __scrt_common_main_seh (Just speculating. I am totally clueless about who defines __scrt_common_main_seh)
I did find, however, that the library I was linking against defined a wWinMain() function. So I tried adding the linker flag /ENTRY:wWinMainCRTStartup and the linker error went away.

Error LNK2019 when building Tensorflow debug

I try make a debug build of the CPU version of the C++ API of Tensorflow 2.0 in Windows. The command I use for building is:
bazel build -c dbg --copt=/w34716 tensorflow:tensorflow.dll
But when I build this I get this error:
depth_space_ops.lo.lib(depthtospace_op.obj) : error LNK2019: unresolved external symbol "public: void __cdecl tensorflow::functor::DepthToSpaceOpFunctor<struct Eigen::GpuDevice,struct Eigen::half,1>::operator()(struct Eigen::GpuDevice const &,class Eigen::TensorMap<class Eigen::Tensor<struct Eigen::half const ,4,1,__int64>,16,struct Eigen::MakePointer>,int,class Eigen::TensorMap<class Eigen::Tensor<struct Eigen::half,4,1,__int64>,16,struct Eigen::MakePointer>)" (??R?$DepthToSpaceOpFunctor#UGpuDevice#Eigen##Uhalf#2#$00#functor#tensorflow##QEAAXAEBUGpuDevice#Eigen##V?$TensorMap#V?$Tensor#$$CBUhalf#Eigen##$03$00_J#Eigen##$0BA#UMakePointer#2##4#HV?$TensorMap#V?$Tensor#Uhalf#Eigen##$03$00_J#Eigen##$0BA#UMakePointer#2##4##Z) referenced in function "public: virtual void __cdecl tensorflow::DepthToSpaceOp<struct Eigen::ThreadPoolDevice,struct Eigen::half>::Compute(class tensorflow::OpKernelContext *)" (?Compute#?$DepthToSpaceOp#UThreadPoolDevice#Eigen##Uhalf#2##tensorflow##UEAAXPEAVOpKernelContext#2##Z)
The only thing I found regarding this issue was this GitHub issue, which wasn't solved.
Does anyone know how to solve this issue?
Facing the same necessity, I dug around in the code and actually found the source of the problem: It is contained in the following two if blocks: https://github.com/tensorflow/tensorflow/blob/v2.3.0/tensorflow/core/kernels/spacetodepth_op.cc#L129 and https://github.com/tensorflow/tensorflow/blob/v2.3.0/tensorflow/core/kernels/depthtospace_op.cc#L115.
If you are building a non-GPU version of the library in debug, it is sort of clear why the error happens: the if (std::is_same<Device, GPUDevice>::value) for the DepthToSpaceOp class, for example, parametrized with CPUDevice, would evaluate to if (false) during compile time. With any optimizations enabled, the code in the if-clause (which explicitly triggers DepthToSpaceOpFunctor with a template parameter GPUDevice - exactly the missing symbols you are getting) would not be compiled at all, and therefore not need to be linked.
In the debug build, it is still likely compiled, even though it is clear that it will never be executed. Then the linker tries to find the operator() for the DepthToSpaceOpFunctor template-parametrized with GPUDevice, and fails to do so.
A quick-and-dirty way to fix this is to comment out the entire if-clauses (if you are building a CPU-only dll) in both files mentioned above.
A more elegant solution is to avoid these linker errors via template specialization by changing the explicit references to GPUDevice to Device, since those will be in the code that is executed only when Device is GPUDevice. I will soon add a pull request to a similar issue I raised on github, hopefully, after a bit more testing.
Update: The pull request is submitted, you can find the code changes to fix this particular set of linker errors here: https://github.com/tensorflow/tensorflow/pull/42307/files#
For a GPU debug dll - I am not sure why these errors would still be there, but there are yet other linking errors in this case anyway ;)

Getting "error LNK2001: unresolved external symbol _gnutls_free" when using GnuTLS 3.1.6 from Visual Studio 2012

I am attempting to build a project in Visual Studio 2012 that uses GnuTLS. I downloaded the latest official Windows build from the website, and created a link library by running lib /def:libgnutls-28.def in the bin directory form a Visual Studio command prompt.
After adding a typedef long ssize_t, the code compiles fine, but linking fails with the following error:
source_file.obj : error LNK2001: unresolved external symbol _gnutls_free
C:\Path\to\executable.exe : fatal error LNK1120: 1 unresolved externals
I am calling gnutls_free to free some memory allocated and returned by the library. If I remove the call to gnutls_free, the project links successfully. Given that gnutls_free is just a global variable (containing a function pointer) exported by the library, I'm not sure why accessing it results in an unresolved reference to a different symbol. I have verified that gnutls_free is not #defineed to anything.
As a test, I tried doing gnutls_free_function test = gnutls_free; which also resulting in the link error. Running grep -w -r _gnutls_free . on the GnuTLS source code returns nothing, so I am at a loss.
Any ideas for getting this working would be greatly appreciated.
EDIT:
Adding __declspec(dllimport) to the declaration of gnutls_free in gnutls.h allows the link to succeed. Is there any way to accomplish this without maintaining a custom version of the header file?
There doesn't seem to be a way to have the linker or import library automatically dereference the IAT's pointer to the data item the same way that is done for functions (via a small trampoline function that is statically linked into the module importing the function). The __declspec(dllimport) attribute tells that compiler that this dereferencing needs to be done so it can insert code to perform the dereferencing of the IAT pointer implicitly. This allows exported data to be accessed and for functions allows the compiler to call the imported function via an indirect call through the IAT pointer rather than by calling the trampoline function.
See a couple of Raymond Chen's articles about dllimport for a good explanation of what goes on for function calls (he didn't discuss importing data, unfortunately):
Calling an imported function, the naive way
How a less naive compiler calls an imported function
The MS linker or import library doesn't have a mechanism to help the compiler get imported data in a 'naive' way - the compiler needs the the __delcspec(dllimport) hint that an extra dereference through the IAT is needed. Anyway, the point of all this is that it seems there's no way to import data except by using the __declspec(dllimport) attribute.
If you want to avoid modifying the gnutls distribution (which I can understand), here's one rather imperfect workaround:
You can create a small object file that contains nothing but a simple wrapper for gnutls_free(); since gnutls_free() has an interface with no real dependencies, you can have the necessary declarations 'hardcoded' instead of including gnutls.h:
typedef void (*gnutls_free_function) (void *);
__declspec(dllimport) extern gnutls_free_function gnutls_free;
void xgnutls_free(void* p)
{
gnutls_free(p);
}
Have your code call xgnutls_free() instead of gnutls_free().
Not a great solution - it requires your code to call a wrapper (so it's particularly not great if you'll be incorporating 3rd party code that might depend on gnutls_free()), but it might be good enough.