I want to add new method in OpenCV library. I made my_funct.cpp whose code is as simple as:
#include "precomp.hpp"
#include <stdio.h>
void cv::my_funct(){
printf("%s\n","Hello world!");
}
and I added header CV_EXPORTS_W void my_funct(); to files C:\opencv\build\include\opencv2\imgproc\imgproc.hpp and C:\opencv\sources\modules\imgproc\include\opencv2\imgproc\imgproc.hpp. Then I used CMake to build new binaries for whole library, but when I make a new project in which I use my_funct() I get an error:
The procedure entry point _ZN2cv8my_functEv could not be located in
the dynamic link library path_to_this_project\project.exe.
Other opencv functions work just fine. I'm using mingw32 to compile library and the version of OpenCV is 2.4.9. Can you tell me what am I doing wrong?
This looks like an MinGW run-time error. So going by the assumption that you didn't get any compiler or linker errors while building project.exe, your executable most likely doesn't find the matching .dll to your .dll.a import library (which must have included the my_funct() definition).
I would recommend during developments phase - not talking about the install() scripting - to add a post-build step using add_custom_command() and generator expressions to copy the right DLL next to your project.exe:
add_custom_command(
TARGET project
POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy
"<... path to matching DLL ...>"
"$<TARGET_FILE_DIR:project>"
)
Certainly you could also let CMake find the matching DLL, but before I could go into details there I would need to see your project.exe CMake script.
Maybe also good idea - if you are in the process of extending OpenCV code - would be to use ExternalProject_Add() to include OpenCV into your project.
References
MinGW-w64 - for 32 and 64 bit Windows - Wiki: Procedure entry point OpenProcessToken? could not be located in the dynamic link library kernel32.dll
MinGW "The procedure entry point libiconv could not be located ..."
Getting started with OpenCV 2.4 and MinGW on Windows 7
Related
I try to get tests generated by the cxxtest framework working under a MinGW environment managed by mysys2. The tool generates C++ files with absolute paths. However, gcc seems to be unable to resolve this absolute paths.
Here is a minimal example to demonstrate the problem:
// file1.h
#include <iostream>
inline void hallo() { std::cout << "Hallo\n"; }
// main.cpp
#include "/home/phil/example/file1.h"
int main()
{
hallo();
return 0;
}
The file exists (at least the msys2 shell resolves the path):
$ ls /home/phil/example/file1.h
/home/phil/example/file1.h
... but calling g++ results in this error:
$ g++ main.cpp
main.cpp:1:38: fatal error: /home/phil/example/file1.h: No such file or directory
#include "/home/phil/example/file1.h"
^
compilation terminated.
Same error with clang.
Under a full Linux environment, the example works. It also works if I replace the absolute path by a relative one (#include "file1.h").
So, I assume the problem lies in the layer over Windows that is responsible to resolve paths. Not sure whether I should report it as a bug to the msys2 project, or whether it is a known problem. If it is a known problem, are there any workarounds (like setting -I options)?
(If possible, I would like to avoid replace the absolute paths, as they are in generated code by the cxxtest framework. Technically, running a postprocessing step on the generated files would be possible but seems like a hack in the long run.)
Since you are running compilers that use MinGW-w64 as their runtime environment, they don't recognize POSIX-style paths like that. I think they actually interpret the root directory "/" to be "C:\". Other than that, they would only recognize native Windows-style paths.
I recommend that you pass the argument -I/home/phil/example to your compiler from some program running in the msys-2.0.dll POSIX emulation runtime environment (e.g. /usr/bin/bash or /usr/bin/make). The msys-2.0.dll runtime will then convert that argument to use a native Windows path so the compiler can understand it, and statements like #include <file1.h> will work. Alternatively, you might try putting a Windows-style path in your source code, e.g. the path should start with C:\.
Note however that having absolute paths in source code or build scripts is a bad idea since it makes it harder to build the code on a different computer. You could consider using environment variables or relative paths.
Try using the MinGW compiler that Cygwin provides as a package. (In other words, forget the MSYS environment; work under Cygwin, but build the code as before, in the MinGW style.)
Then you should be able to have include references /home/phil; it will just resolve to C:\Cygwin\home\phil or wherever your Cygwin root is.
Actually, it might be possible under MSYS also (which, after all, is just the descendant of an old for of Cygwin). You just have to figure out what /home/phil is referring to, create that tree and work under there.
First of all I am complete new to C++, so if you know the answer please be patient with me ;). Here my problem:
I wanna solve an IP with Gurobi in a C++ Code. The Code itself seems fine since there are no expression marked as errors. However when I run the Code I get the following error report:
Undefined symbols for architecture x86_64:
and many lines like that:
"GRBLinExpr::GRBLinExpr(GRBVar, double)", referenced from:
bridge_problem::max_flow_lp(time_expanded_network&, lemon::ListDigraph&, lemon::DigraphExtender<lemon::ListDigraphBase>::ArcMap<int>&, lemon::DigraphExtender<lemon::ListDigraphBase>::ArcMap<int>&, lemon::DigraphExtender<lemon::ListDigraphBase>::NodeMap<int>&) in bridge_problem.cpp.o
I suppose that the mistake is in my CMakeList.txt file. This file was automatically created since I am using Clion and for including gurobi I entered those additional lines:
include_directories(/Library/gurobi604/mac64/include)
link_directories(/Library/gurobi604/mac64/lib/libgurobi_c++.a)
link_directories(/Library/gurobi604/mac64/lib/libgurobi60.so)
Any help is greatly appreciated and if you need any more information just let me know. (In case it is important I using a mac).
EDIT: I changed my make code since I found this one:
https://github.com/joschu/trajopt/blob/master/cmake/modules/FindGUROBI.cmake
I changed the version since I have gurobi604 but it still does not work. My new error message is:
fatal error: 'gurobi_c++.h' file not found #include "gurobi_c++.h"
I don't get it since I thought by
find_path(GUROBI_INCLUDE_DIR
NAMES gurobi_c++.h
PATHS "$ENV{GUROBI_HOME}/include"
"/Library/gurobi604/mac64/include"
"C:\\libs\\gurobi604\\include"
)
that should be easy to find. Any suggestion?
From the small excerpt of your CMakeLists.txt, I expect you should be using target_link_libraries rather than link_directories.
I'd normally recommend linking to the static version of any library rather than the shared if possible (i.e. in this case prefer "libgurobi_c++.a" over "libgurobi60.so" assuming they're the same library, just compiled differently).
So, if your exe is called MyExe, you could do:
target_link_libraries(MyExe /Library/gurobi604/mac64/lib/libgurobi_c++.a)
Also, it's almost always best to avoid specifying hard-coded paths in your CMakeLists.txt. Although your copy of "libgurobi_c++.a" lives in "/Library/gurobi604/mac64/lib/", that won't be the case for other users, or on different platforms.
You can avoid this by having CMake "find" the library, for example by calling find_library:
find_library(Gurobi NAMES gurobi_c++)
if(NOT Gurobi)
message(FATAL_ERROR "Failed to find Gurobi lib. Try setting CMAKE_PREFIX_PATH")
endif()
target_link_libraries(MyExe ${Gurobi})
Then, when you run CMake, you just need to tell it where the Gurobi library is. I'm not sure how you do that in CLion, but for example if you were running CMake from the command line, you'd do:
cmake . -DCMAKE_PREFIX_PATH=/Library/gurobi604/mac64
Whenever I try to compile this code it always ends up with this error:
In file included from /usr/include/wchar.h:6:0,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/cwchar:44,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/bits/postypes.h:40,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/iosfwd:40,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/ios:38,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/ostream:38,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/iostream:39,
from test.cpp:1:
/usr/include/sys/reent.h:14:20: fatal error: stddef.h: No such file or directory
#include <stddef.h>
^
compilation terminated.
The code I was trying to compile is:
#include <iostream>
using namespace std;
int main()
{
cout << "Hello World! :D";
return 0;
}
The error is because your gcc-core package and gcc-g++ are not of the same version. Either downgrade one of them to solve the problem or update both the libraries. Updating both the libraries is the recommended way.
I had this error on a fresh MinGW install, it had nothing to do with the installed packages mentioned in the current accepted answer by "Prasanth Karri". In my case the issue was caused by -nostdinc in my Makefile. I actually only needed that compiler flag when building for a different target platform (not when using MinGW) so I fixed the issue by removing that flag from MinGW builds.
When I was incorporating a software library written in C into an existing demo project(used a C++ mbed library) I encountered this problem. The demo project would compile just fine, but after I replaced the existing main file by my own, this error occurred.
At this point I hadn't yet thought about the fact that the mbed library that I needed was written in C++. My own main file was a .c file that #include the mbed header file. As a result I used my normal C source as if it was a C++ source. Therefore the compiler that was used to compile my main file was the C compiler.
This C compiler then encountered a #include of a module that actually does not exist (within its scope), as it's not a C++ compiler.
Only after I inspected the output of the build log I realised the various source C and C++ files were compiled by more that 1 compiler(the c++ compiler). The project used used compilers arm-none-eabi-c++ and arm-none-eabi-gcc (for embedded systems) as seen below.
Compile log:
Building file: ../anyfile.cpp
Invoking: MCU C++ Compiler
arm-none-eabi-c++ <A lot of arguments> "../anyfile.cpp"
Finished building: ../anyfile.cpp
Building file: ../main.c
Invoking: MCU C Compiler
arm-none-eabi-gcc <A lot of arguments> "../main.c"
In file included from <Project directory>\mbed/mbed.h:21:0,
from ../main.c:16:
<Project directory>\mbed/platform.h:25:19: fatal error: cstddef: No such file or directory
compilation terminated.
Of course in a C++ environment cstddef exists, but in a C environment cstddef doesn't exist, in stead it's just C's implementation of stddef.
In other words, cstddef does not exist in the C compiler.
I resolved this problem by renaming my main.c file to main.cpp and the rest of the code compiled smoothly too.
TLDR/Conclusion: When building a C++ project, avoid mixing C files with C++ files(sources and headers). If possible rename .c files to .cpp files to use the C++ compiler in stead of the C compiler where required.
In order to update it, follow below.
If you are on Windows, just run these on command prompt or powershell
Update the package list: mingw-get update
After updating the package list, run: mingw-get upgrade
Source: How to update GCC in MinGW on Windows?
This problem was solved for me as I installed codeblocks with mingw compiler then I copied the mingw folder from codeblocks to C drive and added
C\mingw\bin to the environment variables.
If you try to compile and see a message like, "fatal error: stddef.h: No such file or directory", the error is because your gcc-core and gcc-g++ packages are not of the same version. Rerun the Cygwin install and make sure that you select the highest numbered versions of gcc-core and gcc-g++.
After installing the C++ compiler with MinGW I encountered this problem as well. Apparently, you have to also install mingw32-base. Go to C:/MinGW/bin/mingw-get.exe (my path) and check it for installation at the Basic Setup tab.
I built Qt from source (dlls) and am trying to build an application that uses the Qt dlls. I don't have a lot of experience with C++ so I'm running into what I'm sure is a very basic issue.
My builds are failing on the includes with errors like so:
Fatal error: QNetworkProxy: No such file or directory
Here is the g++ command I am using (I also used -L to add the correct folder to the lib path, but that also didn't work):
g++ -l..\..\wkqt\bin\QtCore4.dll -l..\..\wkqt\bin\QtNetwork4.dll -l..\..\wkqt\bin\QtWebKit4.dll -I..\include -Ishared -Ipdf -Ilib -Iimage -o ..\bin\wkhtmltopdf.exe pdf\*.cc lib\*.cc image\*.cc shared\*.cc
I tried in Visual Studio as well (assuming it wouldn't build, but I wanted to see if I could at least include the Qt dlls from there properly) and I am getting the same errors. Am I doing something wrong with the way I am compiling with g++? If I am linking with the Dlls properly then what is the proper way to use Qt functions from my code?
To clarify, I am not looking for how to properly use Qt. My question is: what is the proper way to use functions defined in any Dll from native C++ code? I apologize if this is a very basic question, but I'm unable to find a clear answer on Google and I don't have any experience with C++ and including third party libraries for use from C++ code.
DLLs can be used by dynamicly loading them and calling their used functions.
to call the exposed functions first define their syntax in the begining
suppose function is syntax is
BOOL MyFunction(int a,char* pszString)
then define syntax
#typedef BOOL (WINAPI *PMYFUNCTION)(int a,char* pszString)
then make object
PMYFUNCTION pfnMyFunction;
and get valid pointer by calling GetProcaddress after loadlibrarycall
HMODULE hlib= Loadlibrary("c:\\Mylib.dll");
if(hlib)
{ pfnMyFunction = (PMYFUNCTION)Getprocaddress(hlib,"MyFunction"); }
Hope this helps...
I'm trying to use vtk in my code, but I'm having problems running an example. I have almost no clue about the reasons since it's the first time I'm using it and I'm not very experienced.
I'm using visual studio 2012 and x64 platform.
Since I don't really know which libs should I use I added all of them to the "Additional Dependencies".
The example is given in this link.
The problem is that when I run it, the window shows this message
Generic Warning: In C:\location\VTK6.0.0\Rendering\Core\vtkPolyDataMapper.cxx, line 27
Error: no override found for 'vtkPolyDataMapper'.
which corresponds to this line
// Return NULL if no override is supplied.
vtkAbstractObjectFactoryNewMacro(vtkPolyDataMapper)
And the error that visual studio shows is
First-chance exception at 0x000007F7AA106C8F in Test.exe: 0xC0000005: Access violation reading location 0x0000000000000000.
Does anyone know how to solve this problem or at least what does this error mean?
I too was getting this error. The error means that the linker can't find the definition for the vtkPolyDataMapper method. One has to note which vtk rendering backend they used, during build. It will probably be either vtkRenderingOpenGL, or vtkRenderingOpenGL2. Go to your build/lib folder and search for either one of these. I have VS 2015 Community and had the vtkRenderingOpenGL2, with vtk-7.1 built on Windows 8.1, x86_64 Platform, Release configuration.
I fixed the issue by inserting the 3 following lines at the very top of my source files, before any other preprocessor directives:
#include "vtkAutoInit.h"
VTK_MODULE_INIT(vtkRenderingOpenGL2); // VTK was built with vtkRenderingOpenGL2
VTK_MODULE_INIT(vtkInteractionStyle);
This initializes the specified VTK modules. CMake includes these by default, but other compilers such as VS do not.
The last two lines can be combined into the following:
#define vtkRenderingCore_AUTOINIT 2(vtkRenderingOpenGL2, vtkInteractionStyle)
According to the VTK migration guide, if you are not using CMake to compile your code, you need to add some #defines. For VTK 6.0, these lines need to go before any other VTK #includes:
#define vtkRenderingCore_AUTOINIT 4(vtkInteractionStyle,vtkRenderingFreeType,vtkRenderingFreeTypeOpenGL,vtkRenderingOpenGL)
#define vtkRenderingVolume_AUTOINIT 1(vtkRenderingVolumeOpenGL)
You are missing include(${VTK_USE_FILE}) in your CMakeLists.txt file.
Assuming your are using OpenGL2, you should initialise the vtkRenderingOpenGL2 module, ensuring its object factory is correctly registered:
VTK_MODULE_INIT(vtkRenderingOpenGL2)
You should call this macro in the global scope (ex. main.cpp) as documented in the source code:
Initialize the named module, ensuring its object factory
is correctly registered and unregistered. This call must be made in
global scope in the translation unit of your executable (which can
include a shared library, but will not work as expected in a static
library).
#include "vtkAutoInit.h"
VTK_MODULE_INIT(vtkRenderingOpenGL);
The above snippet if included in the global scope will ensure the
object factories for vtkRenderingOpenGL are correctly registered and
unregistered.
How do you know which module to include?
The easiest method is to search in the VTK build folder for "vtkClassThatNeedsAnOverride", i.e. "vtkPolyDataMapper" in your case (note the use of quotes ".) and looking for a *ObjectFactory in your search results:
Rendering/OpenGL2/vtkRenderingOpenGL2ObjectFactory.cxx:
this->RegisterOverride("vtkPolyDataMapper",
"vtkOpenGLPolyDataMapper",
"Override for vtkRenderingOpenGL2 module", 1,
vtkObjectFactoryCreatevtkOpenGLPolyDataMapper);
It may be even more beneficial to look for RegisterOverride("vtkPolyDataMapper".
Which object factories exist?
To obtain a list of all existing modules that you could initialise, you can search for _AutoInit_Construct. *_AutoInit_Construct is the method that is called by VTK_MODULE_INIT.
As an alternative, you can look at all classes that derive from vtkObjectFactory.
A second alternative is to look for all calls to RegisterOverride.
Further information
VTK 6 Migration: Factories now require defines
Build System Migration: You do not need to call VTK_MODULE_INIT manually using cmake by calling include(${VTK_USE_FILE}) in your CMakeLists.txt
Note that I originally wrote this answer for a duplicate question, but I think the general information about solving this problem may be of interest for other people with the same error message.
I would recommend following the guide here, with the VTK_MODULE_INIT macro being the most reliable, with the guide here providing a high level overview of the changes needed. You must link to vtkRenderingOpenGL for example to get most of the standard overrides. If you use CMake then specifying it on the COMPONENTS argument to find_package would cause it to be added to VTK_LIBRARIES, and including VTK_USE_FILE would cause the correct compiler definitions to be added.
I had the same issue at my platform;
Visual Studio 2015
Windows 7
VTK 6.3
I followed VTK/Build System Migration from Marcus D. Hanwell's post, and it works. My additonal lines are;
#include <vtkAutoInit.h>
VTK_MODULE_INIT(vtkRenderingOpenGL);
VTK_MODULE_INIT(vtkInteractionStyle);
on the top of preprocessor. The difference from RestlessC0bra's post is probably OpenGL version.
When using ParaView's Catalyst libraries you have to add the following in addition to include("${PARAVIEW_USE_FILE}"):
set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS ${VTK_DEFINITIONS})
A quick hack solution: In CMakeList.txt file, replace vtkRendering${VTK_RENDERING_BACKEND} with vtkRenderingOpenGL2. The reason why we need this is because Cmake does not know where the rendering core is. By specifying it, we can use the rendering core to override the proper method.
The proper solution should be replace the whole find_package paragraph with:
find_package(VTK REQUIRED COMPONENTS vtkCommonCore)
find_package(VTK COMPONENTS
vtkFiltersSources
vtkInteractionStyle
vtkRendering${VTK_RENDERING_BACKEND})
The first find_package lets the CMake know where to find the packages, then second find_package would know where to find vtkRendering${VTK_RENDERING_BACKEND}.