Undefined reference compilation MITK/Qt - c++

I need to compile the project of my teacher. This project use MITK, VTK, ITK, CTK and Qt. I had some errors which I managed to correct during compilation. Now, i have an error that I don’t understand and I don’t know how correct that to finish the compilation.
The problem is that I have :
undefined reference to « operator delete(void, unsigned long)#Qt_5 »* in the library libMitkAppUtil.so
We see also it is a link error. As it is a project of my teacher and others teachers I think it is a problem with a version of Qt or something in my computer no like the version of gcc or g++ ?
When I open Qt and i open many files there are three messages nearly of the toolbar :
the code model could not parse an included file, which might lead to incorrect completion and highlighting, for example.
Multiple parse contexts are available for this file. Choose the preferred one from the editor toolbar.
This file is not part of any project. The code model might have issues parsing this file properly.
Maybe there is a link with the error on the terminal ?

do you use cmake for the build process?
e.g.
cd MITK-build;
cmake ../MITK-source ./;
make -j1
Please start the build process in single-thread mode and then attach the standard output text to your reply so that we can look into the problem.
Sometimes problems occur with the /ep/ part of the build process (e.p. = external projects), there you could 'cd ep/xxx.../; cmake ./;make -j1' to start individual builds.
HTH,

Related

How to set up C++ Testmate in VS Code

Ok, n00b question. I have a cpp file. I can build and run it in the terminal. I can build and run it using clang++ in VSCode.
Then I add gtest to it. I can compile in the terminal with g++ -std=c++0x $FILENAME -lgtest -lgtest_main -pthread and then run, and the tests work.
I install the C++ TestMate extension in VSCode. Everything I see on the internet implies it should just work. But my test explorer is empty and I don't see any test indicators in the code window.
I've obviously missed something extremely basic. Please help!
Executables should be placed inside the out or build folder of your workspace. Or one can modify the testMate.cpp.test.executables config.
I'd say, never assume something will "just work".
You'll still have to read the manual and figure out what are the names of config properties. I won't provide exact examples, because even though I've only used this extension for a short time, its name, and therefore full properties path, has already changed, so any example might get obsolete quite fast.
The general idea is: this extension monitors some files/folders, when they change, it assumes those are executables created using either gtest or catch2. The extension tries to run them with standard (for those frameworks) flags to obtain a list of test suites and test cases. If it succeeds, it will parse the output and create a nice list in the side panel. Markers in the code are also dependent on the exactly same parsed output, so if you have one, you have the other as well.
From the above, you need 3 things to make this work:
Provide correct path (or a glob pattern) for finding all test executables (while ignoring all non-test executables) in the extension config. There are different ways to do this, depending on the complexity of your setup, they are all in the documentation though.
Do not modify the output of the test executable. For example, if you happen to print something to stdout/stderr before gtest implementation parses and processes its standard flags, extension will fail to parse the output of ./your_test_binary --gtest-list_tests.
If your test executable needs additional setup to run correctly (env vars, cwd), make sure, that you use the "advanced" configuration for the extension and you configure those properties accordingly.
To troubleshoot #2 and #3 you can turn on debug logging for the extension (again, in the VSCode's config json), this will cause an additional "Output" tab/category to be created, where you can see, which files were considered, which were run, what was the output, and what caused this exact file to be ignored.
This messed with me for a while, I did as Mate059 answered above and it didn't work.
Later on I found out that the reason it didn't work was because I was using a Linux terminal inside windows (enabled from the features section) and I previously had installed the G++ compiler using the linux terminal so the compiler was turning my code into a .out file, for some reason TestMate could not read .out files.
Once I compiled the C++ source file using the powershell terminal it created a .exe file which I then changed the path in the setting.json as Mate059 said and it showed up.
TL;DR
Mate059 gave a great answer, go into settings.json inside your .vscode folder and modify "testMate.cpp.test.executables": "filename.exe".
For me it also worked using the wildcard * instead of filename.exe but I do not suggest to do that as in that might mess up something with the .exe from the main cpp file and what not.

GraphicsMagick.NET missing CORE_RL_bzlib_.lib file, C++ linker error?

I'm a long time VB programmer, and pretty good with c#, but I'm dumb as a brick when it comes to c++. But nonetheless, I need to build the source code for GraphicsMagick.NET, specifically for .net 2.0 if I can, to try to see if I can convert it to a fully managed dll, so that I can import it into Unity3D (who cares why I need to build it?).
Anyway, without posting the entire project here, I realize it might be hard for anyone here to know exactly what is causing my error. But perhaps someone can give an educated guess? Edit: you can download a zip of the full source from https://graphicsmagick.codeplex.com/SourceControl/latest if you want to see all the code I'm working with that is giving me this error.
This project, I assume, is supposed to compile without errors right out of the box. But it doesn't. It has this line of code in the include.h file:
# if defined(HasBZLIB)
# pragma comment(lib, "CORE_RL_bzlib_.lib")
# endif
and as a result of this evil line, I'm getting this evil error:
LNK1104 cannot open file 'CORE_RL_coders_.lib'
GraphicsMagick.NET.net20
C:\Users\A\Downloads\graphicsmagick-d\GraphicsMagick.NET.net20\LINK 1
Being the good VB programmer, I searched my project folder extensively, and that _.lib file doesn't exist. But in the process of searching online, I learned that c++ sometimes generates .lib files when you build a project. So perhaps this file was supposed to be built first, before it was linked, but for whatever reason it didn't get built first? You can see how clueless I am with c++.
Of course I commented out the line. But then it simply generates an error on the next line, which is another .lib file missing. I assume it will generate an error on every _.lib file in the entire include.h file, and there are a fair number of them.
Why is this project, which is supposed to build, missing so many .lib files? Can anyone give an educated guess why? am I probably missing some dependency that the author of this project forgot to mention in the installation instructions? Or would it be more likely that these .lib files are supposed to be created by me somehow, and I'm just not building it right?
In the downloaded release under GraphicsMagick there are two script files called CopyLibsFromDropbox.cmd and CopyLibsToDropbox.cmd, the first of which contains
echo You can download the library files here: https://www.dropbox.com/sh/a8krszzmo76fqkt/AAAc9Jho29Jk3iLrKhsBmw-Ma?dl=0
goto done
In that dropbox, you will find all the lib files you need. Download the whole thing as a .zip and extract the thing inside the the \GraphicsMagick directory. Should look like that now:
Once the libs are inside that folder you can actually compile the code. The scripts are for copying them from your local dropbox directory to this directory, if you choose to "save this inside my dropbox" at the dropbox download page above. In the end, you should see something like
3> GraphicsMagick.NET.Web -> C:\Users\Maxi\Downloads\graphicsmagick-d1b5b1b28f26cdedf3ceeb555b94a87609286740\GraphicsMagick.NET.Web\bin\ReleaseQ16\x86\GraphicsMagick.NET.Web-x86.dll
3> Codeanalysis is beeing executed...
3> Codeanalysis finished -- 0 Errors, 0 Warning(s)
========== Build: 2 successfull, 0 failed, 0 recent, 1 skipped ==========
(who cares why I need to build it?)
I do. You can already include managed dlls to Unity, and GraphicsMagick.NET already gives you a .NET dll which you should be able to use within Unity, or did you have any particular problems with that? Need some image processing functionality from that library?

Codeblocks cannot create output directory

I'm using Code::Blocks 12.11 in Widnows XP. I've been learning C++, so I haven't been working on any specific projects, just individual files. I'm trying to debug one of these files, but found from this question that I needed to be in a project in order to debug. So, I created a project for all of my C++ practice files. Now, when I try to debug (or run) the program, Code::Blocks gives me this error: "Can't create output directory bin\Debug.
When I remove the file from the project it still gives me this error. What can I do to try to fix this so that the program can run and debug?
Additional information:
In Settings>Compiler>Global Compiler Settings>Compiler Settings>Compiler Flags, I have enabled "Produce debugging symbols [-g]". This is something that a lot of other resources I've checked have mentioned.
Also, under Debug>Active Debuggers, I've tried using both debuggers, both of which produce the same error message.
Why don't you try to remove the entire project directory, create an empty project and then place the source files one by one into the project. Beware if you have a main() method in each of your source files.
Well, a friend of mine was getting the same error. So I decided to check it out.
I my case, the error was because of the account user name.
When I checked, the output directory while creating the file and the one in the error being shown, were different.
When I checked, I created an user account name with "$aaa$", and I got the same error.
and I noticed that the error was because of the "$" sign. (Probably).
So, I guess the problem is with the user name. Try changing the user name to something simple.

How to avoid symbols and source paths in iOS binary?

When I compile the release version of my iOS app (based on standard Apple supplied iOS app template), look into the resulting executable binary, I see all sorts of symbols and even local cpp source and header paths in there. I'm really stumped why this is (I haven't enabled RTTI*). Especially the source file paths make me feel uncomfortable sending this app across the globe (why should everyone be able to see the directory layout of my development machine?).
Here's are two (randomly picked, moderated) excerpts:
TS/../ACTORS/CActorCanvasCharPart.cpplastMeshcapVerticesOFF BOUNDSupload VERTICES: %d
20CActorCanvasCharPartgrassscrub/Volumes/Data/iOS_projects/code/MyAppName_proj/MyAppName/source/STATES/GAMES/2/CStateGame2_grass.cppbaseShadowmowerstartmowerloopmowermowerCharcutGrassChargrassStuffgrassParticles/Volumes/Data/iOS_projects/code/MyAppName_proj/MyAppName/source/STATES/GAMES/2/CStateGame2_grass.h17CStateGame2_grasssinwriteStroke/Volumes/Data/iOS_projects/code/MyAppName_proj/MyAppName/source/STATES/GAMES/2/CStateGame2_flowers.hflowerBedsandTrailclickstart3inplace2sandDrag/Volumes/Data/iOS_projects/code/MyAppName_proj/MyAppName/source/STATES/GAMES/2/CStateGame
And here are a lot of symbols for self-defined types and structs:
CAssetMgr="_vptr$CMgrBase"^^?"pMain"^{CMain}"inited"B"curveCount"S"curveSpecs"^{CCurveSpec}"gameSpecs"[23{CGameStateSpec="header"{SpecDiskHeader="type"i"version"S}"gameID"C"backgroundColor"{CRGBAcolorf="r"f"g"f"b"f"a"f}"clickPointColor"{CRGBAcolorf="r"f"g"f"b"f"a"f}"clickPointIconColor"{CRGBAcolorf="r"f"g"f"b"f"a"f}"hintColor"{CRGBAcolorf="r"f"g"f"b"f"a"f}}]"currentFont"^{CCharset}"userCharParts"^^{CCharPart}"words"{CDataSet<CName4,CCharArray>="_vptr$CObjectBase"^^?"pMain"^{CMain}"count"i"data"*"dataSize"l}"sets"{CDataSet<CName16,CCharArray>="_vptr$CObjectBase"^^?"pMain"^{CMain}"count"i"data"*"dataSize"l
Can this be avoided, how?
*UPDATE: I just found out that RTTI is on by default. So I cleaned the target, disabled RTTI (GCC_ENABLE_CPP_RTTI = NO) and recompiled. I still see a lot of symbols and source paths in the binary.
UPDATE 2: I checked a few other apps from the app store, and many of them also have their source file paths show up. Pretty scary, if you ask me:
Joined Up Lite
/Users/lloydy/Documents/Development/iPhone/ABC Joined Up/main.m
/Users/lloydy/Documents/Development/iPhone/ABC Joined Up/Classes/SettingsView.m
Crayon Physics
/Users/smproot/Desktop/unzip/CrayonPhysics/v104/Classes/crayon/src/ceng/gameutils/killspriteslowly/killspriteslowly.cpp
/Users/smproot/Desktop/unzip/CrayonPhysics/v104/Classes/crayon/src/ceng/tasks/task/sdl/mixer/ctaskaudiosdlmixer.cpp
Wall Times
/Users/fred/_WORK/ZDNDRP/WallTimes/main.m
/Users/fred/_WORK/ZDNDRP/WallTimes/Classes/SystemCategories.m
Jumbo Calculator
/Users/Christopher/Documents/Development/JumboCalculator 1.0.3/main.m
/Users/Christopher/Documents/Development/JumboCalculator 1.0.3/Classes/CalculatorFaceViewController.m
The file paths are most likely from assert macros which stringify __FILE__ as part of their failure message. iOS's implementation of assert(3) does this, as do the NSAssert macros.
You can remove asserts in release builds by defining NDEBUG (for the C asserts) and NS_BLOCK_ASSERTIONS (for NSAsserts).
In Xcode set Deployment Prostprocessing to Yes in order to trigger Xcode to call the strip command during build process. Then you don't see any source path via nm -a.
However, I still see the source paths of some m files via the strings command :/
What worked for me was setting Generate Debug Symbols to No for release builds. This is under the Apple LLVM 7.0 - Code Generation in Xcode 7.2.
Have ticked the strip debug symbols in the build settings? You can do this (or not) depending on the configuration (build/release). Also you can look into Objective-C Code Obfuscation (which is long winded). From what I gather, you cannot completely remove objective-c information as all method calls are done dynamically, so the library has to have information about your classes/method names in order to function. A useful tip here.
If you have c++ code then you can use the gcc strip utility, although I'm not sure how it like Objetive-C++, if it doesn't you could compile all you cpp into a lib, strip that and link against it in your iOS project.

VC2008 compiler errors opening sbr files (C2418 C1903 C2471)

EDIT: See my answer below for the hotfix.
ORIGINAL QUESTION:
In setting up for our boat-programming adventure I have to set up source control and fix project files for a team to use them. (the project was previously only being worked on by one person who took shortcuts with setting up the project includes, etc)
I am fixing those SLN and Proj files. When trying to do a build on an external USB drive (I have not tried it on the primary hard drive) I am getting odd errors (lots of them for various files):
fatal error C1083: Cannot open
compiler generated file:
'.\Debug\.sbr': Permission
denied
These files are referenced in the vcproj file with relative paths in double quotes:
RelativePath="..\..\Source\.cpp"
I get the same errors form within a sln file in the IDE or if I call msbuild with the sln file.
The files are kind of "shared" for a few sln files (projects).
The person who originally created the SLN files is not known for being a wizard at configuring MSDev or making things work for teams.
Is this an issue with the way the source files are referenced? Any suggestions on how to fix these?
This URL does not seem to have helpful information:
Fatal Error C1083 on MSDN
Note - there were/are still hardcoded paths in the proj file, but i don;t see them for these files. They were mostly for the include and lib dirs. I think I removed them all.
I also get these errors:
..\..\Source\.cpp : error C2471:
cannot update program database '\debug\vc90.pdb'
..\..\Source\.cpp(336) : fatal
error C1903: unable to recover from
previous error(s); stopping
compilation
..\..\Source\.cpp(336) : error
C2418: cannot delete browser file:
.\Debug\.sbr
Title: You may receive a "PRJ0008" or "C2471" or "C1083" or "D8022" or "LNK1103" or similar error message when you try to build a solution in Visual C++
Symptoms:
D8022 : Cannot open 'RSP00000215921192.rsp'
PRJ0008 : Could not delete file 'vc90.idb'.
C1083 : Cannot open program database file 'vc90.pdb'
C2471 : Cannot update program database 'vc90.pdb'
LNK1103 : debugging information corrupt.
Cause:
This problem occurs when all of the following conditions are true:
You have a solution with more than one project in it.
Two or more of the projects are not dependent on each other.
You have parallel builds enabled. (Tools -> Options: Projects and Solutions, Build and Run: "maximum number of parallel project builds" is set to a value greater than 1)
You are building on a system with multiple CPUs (cores).
Two or more of the non-dependent projects are configured to use the same Intermediate and/or Output directory.
A specific race condition in mspdbsrv.exe remains uncorrected.
Resolution:
To resolve the problem do one or more of the following:
Reconfigure the non-dependent projects to specify an Intermediate and Output directory that is different from one another, e.g. Output Directory = "$(SolutionDir)$(ProjectName)\$(ConfigurationName)", Intermediate Directory = "$(OutDir)".
Adjust your solution's project dependencies (Project -> Project Dependencies...) so that each is dependent on another.
Disable parallel builds.
Add the "/onecpu" boot option to your boot.ini file.
Change you BIOS settings to enable/use only one CPU.
File a problem report with Microsoft Technical Support and keep bugging the crap out of them until they eventually fix mspdbsrv.
Status:
The problem is a combination of both a user project configuration error as well as a race condition in Microsoft's "mspdbsrv.exe" utility that does not properly handle more than one thread calling it at the same time for the same file resulting in the file's HANDLE being left open.
Additionally Visual Studio itself and/or its build system (VCBUILD and/or MSBUILD) (or all three!) should be made smart enough to detect and alert the user of such user errors so that corrective action can be taken.
This problem has been around for a LOOOOOONG time.
Applies to:
Microsoft Visual C++ 2005
Microsoft Visual C++ 2008
Others?
Respectfully submitted:
"Fish" (David B. Trout)
fish#infidels.org
p.s:
You're welcome. :)
Hmmm.
Perhaps:
http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/0ceac3c6-62f6-4fdf-82e1-d41e1b4fcd20/
there is a hotfix from MS
http://code.msdn.microsoft.com/KB946040
http://support.microsoft.com/kb/946040
That might be my problem. I think it might only be on one machine I have.
EDIT:
I downloaded and ran the hotfix installer. It seems to have fixed it.
I get this same error when I physically remove a file from disk, but leave it in VS. In VS2005 it would give a much better : fatal error file not found. I think this is a bug in VS2008. The hotfix mentioned above didn't help me.
In my case it was my virus package (Trend Micro) causing all the problems. I added my Dev folders to the Ignore/White lists to solve the problem
delete your debug folder and build your project agian.
Occastionally my Visual Studio will suddenly decide something like this. I have found it maybe help to toggle to release, do a full rebuild, then toggle back to debug.