no override found for 'vtkPolyDataMapper' - c++

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}.

Related

Random error in exe_common.inl in Debug build

I am using VS 2022 Community Edition (v17.3.3) to build wxWidgets application (v3.2.0) using C++ (v14.3 - Features from Latest C++). The windows SDK is using the latest installed (10.0.22621). The project is also using C++ modules.
The Debug build succeeds but when I run the project's exe file at random it throws the exception (Access violation reading 0xFFFFFF (ucrtbased.dll)) in exe_common.inl at the following line:
__scrt_current_native_startup_state = __scrt_native_startup_state::initialized;
After a few more compilations (by just making minor changes to trigger a compilation) it succeeds and the exe runs correctly.
I wonder if there is any settings that might be causing this random error. Btw, I am using Win11 but same thing happens on Win10 as well.
Thanks in advance.
EDIT 1:
The project is using boost libraries and at startup boost/json (boost/json is used in other parts of the project as well). Debugger shows that after the following line the above error happens:
static allocator_arg_t allocator_arg = BOOST_CONTAINER_DOC1ST(unspecified, *std_allocator_arg_holder<>::dummy);
There were a few things needed attention:
Discontinued use of wxSQLite (the library was not maintained for over a decade),
The main frame was a singleton data structure, not anymore, and not deriving from wxMDIFrame anymore.
All unnecessary (a chain of them) #include removed.
Inclusion of <boost/json.hpp> in a few files were removed and now using #include <boost/json/src.hpp> only in one .cpp file. However, the project still uses inclusion of <boost/json/value.hpp> in multiple .h files.
All uninitialized pointer variables and others were initialized.
#1 and #4 were especially pointed by the debugger. It has now been more than a few days and haven't had the problem since then.

Adding my method to OpenCV

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

Gurobi and C++- How it works together using Clion

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

maps in shared memory: Boost.Interprocess demo fails due to unmet date_time dependency

I want to create shared map objects that multiple processes can access. The most promising approach I've found is this demo code from Boost.Interprocess, which allocates map objects in a managed shared memory segment. This question will mostly be about the boost problems I'm having, but I'd also be grateful if anyone has non-boost alternative approaches.
I'm completely new to boost: it looks amazing, if huge, and I was encouraged by its claim that "often, there's nothing to build". But in this case that promise is broken in what seems to be a senseless way, and I'm failing to compile the demo because of dependency problems internal to boost.
I'm on Windows, with Visual C++ Express 2010 installed. After saving the demo code as shmap.cpp I do the following:
"%VS100COMNTOOLS%\..\..\VC\vcvarsall.bat"
cl /EHsc /I boost_1_57_0 shmap.cpp
It compiles OK, but then I get this:
LINK : fatal error LNK1104: cannot open file 'libboost_date_time-vc100-mt-s-1_57.lib'
This surprises me on a number of levels. (Q1): I didn't ask for libraries---where and how is boost leading the linker to expect them? (Q2): Why would it be asking for date_time in particular? At no point in the code is anything as functionally specific as a date or time computed, referenced or included. Is this a case of overzealous blanket dependency, and if so is there a way I can weed it out?
Regardless, the obvious first thing to try was to play the game: in the boost_1_57_0 directory I ran bootstrap.bat followed by b2. The Earth turned a good few degrees, boost was built successfully, and I retried with:
cl /EHsc /I boost_1_57_0 shmap.cpp /link /LIBPATH:boost_1_57_0\stage\lib
I still get the same linker error. This is because b2 seems to have built libs with -mt- and with -mt-gd- in their names, but not with the -mt-s- that the linker is looking for. Boost's "Getting Started" webpage tells me what these stand for but doesn't tell me (Q3): how can I change either the type of library that gets built, or the type that the linker expects?
"At no point in the code is anything as functionally specific as a date or time computed, referenced or included."
(Q2): Why would it be asking for date_time in particular?
Apparently the things you used depend on it.
E.g the mutex operations have timed_lock function
(Q1): I didn't add libraries to the project---where and how is boost leading the linker to expect them?
Boost does autolinking by default. This uses MSVC++ specific pragmas to indicate the right flavour of the right link libraries. This is an awesome feature.
You just have to make sure the import libraries are on the library path for your project.
There are ways to disable auto-linking in boost (I think it involves defining BOOST_ALL_NO_LIB)
There might be ways to
disable dependency on boost date_time (dropping features); see the autl-link description in the Getting Started guide
linking to date_Time statically (or make it header-only)
I'd refer to the documentation for this.
Here's what I've learned, in large part thanks to sehe:
Q1: It's magic---specifically, MSVC-specific magic---and it happens because it's necessary.
Q2: It becomes unnecessary---i.e. the demo can be compiled without needing to look for a binary date_time lib---if I add /DBOOST_ALL_NO_LIB to the compile flags. But it's unclear whether that will still be true once I start to use additional IPC functionality like time-dependent mutexing.
Q3: Strings from the "Boost.Build option" column of this table can be passed to b2, so the way to create *-mt-s-*.lib is to say b2 runtime-link=static. This finally lets me compile without the /DBOOST_ALL_NO_LIB flag, and discover that date_time is the only library the demo seems to need.
I also discovered that the dependencies can be tracked with the bcp tool, and (eventually) also how to build bcp in the first place, as follows:
build:
cd boost_1_57_0
bjam tools\bcp
cd ..
report:
boost_1_57_0\dist\bin\bcp.exe --boost=boost_1_57_0 --report --scan shmap.cpp report.html
The result is that the maps-in-shared-memory demo needs 1421 files from boost 1.57.0.

Unable to add defines to boost build

I am trying to build a debug build of boost serialization/filesystem/system using boost buildsystem. Here is what I use:
b2 serialization filesystem system variant=debug link=static threading=multi
runtimelink=static define=_HAS_ITERATOR_DEBUGGING=0 toolset=msvc-11.0
However, when I include the library in my debug visual studio projects I still get errors like this:
(basic_iarchive.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in Game.obj
Which leads me to belive that my 'define' in the boost build did not have any effect. What is the proper syntax? I cannot find any examples, and the documentation dosnt say anything else on the matter.
EDIT: I would like to enforce that I want to define _HAS_ITERATOR_DEBUGGING=0 in my boost build
Adding define=_ITERATOR_DEBUG_LEVEL=0 works for me, as Igor commented.
_HAS_ITERATOR_DEBUGGING is then defined by the MS-headers based on the above setting, so you shouldn't try to set it directly.
Setting it to 0 improves debug performance dramatically in some cases (real-time 3d) so there are definitely use cases that speak for it, even though the pain of recompiling all DLLs that expose STL-containers/iterators in their interfaces.
_ITERATOR_DEBUG_LEVEL is not boost's thing but part of standard library implementation that ships with MSVC. You must take greatest care to compile everything in your build with a consistent value of this setting. In many cases a violation it's diagnosed by the linker like the message you quote, unfortunately it can go undetected. As it changes the size and layout of most std collections and related stuff, guess what follows.
By default it is not set to anything, and when you include some standard header it looks for _DEBUG and sets itself to 2. Good way if nothing in the system ever sets it and you consistently use _DEBUG.
With boost I'm not familiar, but would guess the setting you quote would force the macro with value 0. If so, no wonder you have a discrepancy. Set it to 2, or if you mean 0, go ahead and use that in all your projects.