Error check in Eclipse CDT using Makefiles - c++

I'm using eclipse to develop my project, which bases on my custom makefile system. I have to use custom Makefile project because I want to tevelop LLVM porject pased on the LLVM makefile system, see: http://llvm.org/docs/Projects.html.
I created an "empty makefile" project in eclipse, I'v chosen the build location (Project->Properties->C/C++ Build->Build Location) and added every needed library sources (Project->Properties->C/C++ General->Paths and sources).
The project build and executes like it should. The problem is that a lot of lines is underscored with red colour as errors. This is obvious because eclipse chcecks for erros executing gcc and it does not executes it unless I'm using Makefiles (or maybe I am wrong ...).
Anyway - is there any way to check for syntax (and other types of) errors while using eclipse with makefiles?

Check out this question, or google "eclipse unresolved symbols". You need to add the paths of your includes to your project settings, so Eclipse editor/indexer can find them.
The question in the link is for unresolved includes, but it also applies to all unresolved symbols.

Related

C++ detours linking issue

I have problems building my code that is using static lib detours. I am trying to do an old basic CTF. For that I want to get into detours.
Whenever I try to build my .dll file I get an issue
LNK2019 unresolved external symbol _DetourTransactionBegin#0 referenced in function _DllMain#12
Now, I have built the detours library using 3 different version of the visual studio dev console.
I have tried firing 'vcvars32.bat' and then using nmake to build the library which was able to build it, but I get the above error during linking my .dll. I have also tried building it with 'vcvarsamd64_x86.bat' and then using nmake to build it which also was able to build the library, but I still get the same error as above during linking.
I have tried the usual stuff: the include folder for detours.h is added to C++/General/Additional Include Directories.
Under Linker/Additional Library Directories I added them as follows: "C:\temp\det_retry\lib.X64";"C:\temp\det_retry\lib.X86";%(AdditionalLibraryDirectories).
And also under Linker/Input/Additional Dependencies I have the following: detours.lib;%(AdditionalDependencies)
What am I missing here? This is a blocker for me for a couple of days and I am reiterating the same steps trying to figure out what's missing but I cannot see. I'd really appreciate the input.
I am sure I am using the newest version because I have downloaded (cloned) detours from the ms github page.
It appears your "Additional Library Directories" are setup incorrectly or contain invalid entries rather. They look like actual library file entries (i.e. pointing to some specific files) versus being only directories (e.g. "my/lib/path/for/my_project/"). Visual Studio's naming conventions are somewhat cryptic but they should be directory entries only. There should be an entry to whatever directory contains the detours.lib file (e.g. "MyProject/Libs/MSDetour" ... where MSDetour is a folder with the "detours.lib" in it) and then Visual Studio should find the library and link everything correctly.
As a side note, if you are using the Visual Studio developer console for building your project/solution you might want to look into CMake ... it is, in my opinion, significantly easier to work with (less "settings" digging) and maintain in the long-run.

C++ could not resolve method .open for fstream object [duplicate]

The error is as above. I have what should be all the necessary files include in the eclipse project:
/usr/include/c++/4.6
/usr/include
/usr/include/linux
/usr/local/include
etc.
I tried std::cout and using namespace std; cout but it still says unresolved.
I have imported iostream and cstdlib.
Also, I'm on Ubuntu 12.04 with eclipse 3.7.2.
Code snippet:
#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <iostream>
#include "XPLMDisplay.h"
#include "XPLMGraphics.h"
int XPluginStart(char * outName, char * outSig, char * outDesc) {
/* ... */
std::cout << "test" << std::endl;
/* ... */
}
using namespace std;
UPDATE: I had created the eclipse project from existing code. Creating a new c++ project fixes it. I'll accept an answer that explains what setting in the existing project could cause this (so I don't have to cut & paste all my projects).
Most likely you have some system-specific include directories missing in your settings which makes it impossible for indexer to correctly parse iostream, thus the errors. Selecting Index -> Search For Unresolved Includes in the context menu of the project will give you the list of unresolved includes which you can search in /usr/include and add containing directories to C++ Include Paths and Symbols in Project Properties.
On my system I had to add /usr/include/c++/4.6/x86_64-linux-gnu for bits/c++config.h to be resolved and a few more directories.
Don't forget to rebuild the index (Index -> Rebuild) after adding include directories.
To get rid of symbol warnings you don't want, first you should understand how Eclipse CDT normally comes up with unknown symbol warnings in the first place. This is its process, more or less:
Eclipse detects the GCC toolchains available on the system
Your Eclipse project is configured to use a particular toolchain
Eclipse does discovery on the toolchain to find its include paths and built-in defines, i.e. by running it with relevant options and reading the output
Eclipse reads the header files from the include paths
Eclipse indexes the source code in your project
Eclipse shows warnings about unresolved symbols in the editor
It might be better in the long run to fix problems with the earlier steps rather than to override their results by manually adding include directories, symbols, etc.
Toolchains
If you have GCC installed, and Eclipse has detected it, it should list that GCC as a toolchain choice that a new C++ project could use, which will also show up in Window -> Preferences -> C/C++ -> New CDT Project Wizard on the Preferred Toolchains tab's Toolchains box on the right side. If it's not showing up, see the CDT FAQ's answer about compilers that need special environments (as well as MinGW and Cygwin answers for the Windows folk.)
If you have an existing Eclipse C++ project, you can change the associated toolchain by opening the project properties, and going to C/C++ Build -> Tool Chain Editor and choosing the toolchain you want from the Current toolchain: pulldown. (You'll have to uncheck the Display compatible toolchains only box first if the toolchain you want is different enough from the one that was previously set in the project.)
If you added a toolchain to the system after launching Eclipse, you will need to restart it for it to detect the toolchain.
Discovery
Then, if the project's C/C++ Build -> Discovery Options -> Discovery profiles scope is set to Per Language, during the next build the new toolchain associated with the project will be used for auto-discovery of include paths and symbols, and will be used to update the "built-in" paths and symbols that show up in the project's C/C++ General -> Paths and Symbols in the Includes and Symbols tabs.
Indexing
Sometimes you need to re-index again after setting the toolchain and doing a build to get the old symbol warnings to go away; right-click on the project folder and go to Index -> Rebuild to do it.
(tested with Eclipse 3.7.2 / CDT 8)
Thanks loads for the answers above. I'm adding an answer for a specific use-case...
On a project with two target architectures each with its own build configuration (the main target is an embedded AVR platform; the second target is my local Linux PC for running unit tests) I found it necessary to set Preferences -> C/C++ -> Indexer -> Use active build configuration as well as to add /usr/include/c++/4.7, /usr/include and /usr/include/c++/4.7/x86_64-linux-gnu to Project Properties -> C/C++ General -> Paths and Symbols and then to rebuild the index.
I tried the marked solution here first. It worked but it is kind hacky, and you need to redo it every time you update the gcc. I finally find a better solution by doing the followings:
Project -> Properties -> C/C++ General -> Preprocessor Include Paths, Macros, etc.
Providers -> CDT GCC built-in compiler settings
Uncheck Use global provider shared between projects (you can also modify the global provider if it fits your need)
In Command to get compiler specs, add -std=c++11 at the end
Index->Rebuild
Voila, easy and simple. Hopefully this helps.
Note: I am on Kepler. I am not sure if this works on earlier Eclipse.
I am using Ubuntu 12.04 / Eclipse 4.2.1 / CDT 8.1.1 and I used to have the same problem for quite some time: importing a C++ project from SVN would cause these annoying "Unresolved inclusion" errors and I would instead have to create a new project and copy the files in there as a work-around (still partial, since SVN functionality would not be there!).
At last, I have just found a simple, satisfactory solution:
Go to Project -> Properties -> C/C++ General -> Preprocessor Include Paths, Macros etc. -> Providers and check Enable language settings providers for this project.
Restart Eclipse.
Hopefully that already does the trick.
I had a similar problem with *std::shared_ptr* with Eclipse using MinGW and gcc 4.8.1. No matter what, Eclipse would not resolve *shared_ptr*. To fix this, I manually added the __cplusplus macro to the C++ symbols and - viola! - Eclipse can find it. Since I specified -std=c++11 as a compile option, I (ahem) assumed that the Eclipse code analyzer would use that option as well. So, to fix this:
Project Context -> C/C++ General -> Paths and Symbols -> Symbols Tab
Select C++ in the Languages panel.
Add symbol __cplusplus with a value of 201103.
The only problem with this is that gcc will complain that the symbol is already defined(!) but the compile will complete as before.
For me it helped to enable the automated discovery in Properties -> C/C++-Build -> Discovery Options to resolve this problem.
I simply delete all error in the buttom: problem list.
then close project
and reopen project
clean project
build all
run
then those stupids errors go.
If all else fails, like it did in my case, then just disable annotations. I started a c++11 project with own makefile but couldn't fix all the problems. Even if you disable annotations, eclipse will still be able to help you do some autocompletion. Most importantly, the debugger still works!
I had the same issue using Eclipse CDT (Kepler) on Windows with Cygwin installed. After pointing the project properties at every Cygwin include I could think of, it still couldn't find cout.
The final missing piece turned out to be C:cygwin64\lib\gcc\x86_64-pc-cygwin\4.8.2\install-tool\include.
To sum up:
Right click on the project
Choose Properties
Navigate to C/C++ General > Paths and Symbols > Includes tab
Click Add...
Click File system...
Browse to the location of your Cygwin lib\gcc\x86_64-pc-cygwin\4.8.2\install-tool\include
Click OK
Here is what my project includes ended up looking like when it was all said and done:
You guys are looking under the wrong section.
I realized the difference when I installed in Linux after recently getting frustrated with Windows and the difference was immediately apparent.
In the new setup I have an includes folder in a projected that I created out of existing source. I can expand this and see a ton of includes; however, I cannot add to them.
This lead me to a hunt for where these files were being listed.
They're listed under the Project Properties > C/C++ General > Preprocessor Includes > GNU C++
CDT GCC Built-in Compiler Settings [Shared]
Under that is a ton of includes.
These settings are set by the toolchain you've selected.
I have created the Makefile project using cmake on Ubuntu 16.04.
When created the eclipse project for the Makefiles which cmake generated I created the new project like so:
File --> new --> Makefile project with existing code.
Only after couple of times doing that I have noticed that the default setting for the "Toolchain for indexer settings" is none.
In my case I have changed it to Linux GCC and all the errors disappeared.
Hope it helps and let me know if it is not a legit solution.
Cheers,
Guy.
I had this happen after updating gcc and eclipse on ArchLinux. What solved it for me was Project -> C/C++ Index -> Rebuild.
Just adding yet another bit of advice after trying a bunch of stuff myself and it not working....
I had GCC installed and the path to the includes set correctly. Had the std error as well, and couldn't get anything working for cout (and I suspect anything in the SL...)
Took me awhile to realize that g++ wasn't installed - gcc was but not g++. So just do:
sudo apt-get install g++
Restart eclipse. Assuming above mentioned details about gcc & paths to includes are fine, you should be okay now...
mine was bit easy to fig out right click >run as>run configration
check boxes include system lib,inherited mains

From where Eclipse CDT takes paths in Makefile project?

my project must be "not CDT project". I'm building it by Makefile from command line, and its build correctly. But whole project in Eclipse in many places have unresolved errors. Not all statements are unresolved. It's looks randomly on first shoot (but its not).
I'm don't know where to add paths (I knows path to unresolved files). Problem is because "not CDT" are unabled to be changed from Project/Properties.
How "not CDT" project can be configured?
Check Project->Properties->C++ General->Path and Symbols and set your include path's there. Rerun the indexer on the project afterwards.
Such a project is called a 'Makefile' project BTW, of course it's still a CDT project!

CMake And Visual Studio build errors

I've been trying to compile tulip using cmake to generate visual studio 2012 project files. It's giving me lots of trouble. I don't know how to get this to build. I've been trying to get visual studio to build this for 4 days now, and I'm extremely frustrated. Essentially, I follow the steps here, and then set the variables CMAKE_LIBRARY_PATH AND CMAKE_INCLUDE_PATH according to these instructions.
To get to where I'm at, all you have to do is download tulip, and:
Unzip it, create a separate build directory outside of this source directory
Open CMake-gui to the source and build directories
Hit configure. Check use qt5, tell it where qmake is (make sure it's qt5)
You need some dependencies as described in The Independent CMake tutorial. Grab all those dependencies
As you continue to hit configure, specify each of the directories that it asks for as it errors out. It should ask for freetype, glew, zlib and sphinx. It shouldn't ask for where libxml or libpng, or libjpeg are. I don't know why it doesn't ask for those.
Generate, and then browse to the ALL_BUILD that you've generated. Open it with visual studio
try to build it with visual studio.
In those instructions and in the process of getting CMake to generate the visual studio build files, it specifically asks for freetype's location. But in my build, it doesn't have a clue how to link the freetype library.
Here are the errors that I get
Here is my CMakeCached.txt
I know that many people aren't going to want to exactly try and go about replicating the build environment, so I've uploaded my build directory to dropbox. You can pull the entire thing down, and then open it in cmake gui and open the visual studio files in there too.
https://www.dropbox.com/sh/qsvukh9t5gb6bvt/tOfOBxWgd0
The linker errors you point to (mostly "unresolved external" errors) indicate that there are missing libraries on the link command line.
That is most likely happening because target_link_libraries calls in the tulip project are either being skipped or being called with library names that do not match the library names on disk.
Open up the solution in Visual Studio and right click the project and choose "Properties" -- look at the "Linker > Input" panel at the "Additional Dependencies" field. That should list all the libraries it wants to link to. Is there a freetype library listed there? Does that library exist in the referenced location on your disk?
There could be a mistake in the tulip project, or there could just be something wrong with your build/install of freetype...
UPDATE AFTER SOME CHAT:
Or it may be that you have some libraries built for x86 and some for x64... or maybe some for Debug and some for Release... or maybe even some with the MinGW compiler and some with the Visual Studio compiler. If that's the case, start over, from a clean slate, and build everything with a consistent compiler, configuration type and architecture. Then report back again with an update and see if the problems still remain.
I do with Dave,
You should try to fix your error 1 by 1.
The first error seems to be a link error:
Error 1 error LNK2019: unresolved external symbol gzread referenced in function "public: virtual int __cdecl gzstreambuf::underflow(void)" (?underflow#gzstreambuf##UEAAHXZ) C:\Users\kenne_000\tulip-build\tulip-build-debug\thirdparty\gzstream\gzstream.obj gzstream
gzstream is a third party lib included with tulip source in:
thirdparty\gzstream
from
thirdparty\gzstream\CMakeLists.txt
you can see that the missing symbols should be coming from ZLIB.
However your CMakeCache.txt indicate that
ZLIB_LIBRARY:FILEPATH=C:/Users/kenne_000/dependencies/zlib128-dll/lib/zdll.lib
is found.
So the question may be, was this dependency compiled with the same compiler?
Don't you have compiler-specific name mangling issue ?

cout not recognized but have correct include directories? [duplicate]

The error is as above. I have what should be all the necessary files include in the eclipse project:
/usr/include/c++/4.6
/usr/include
/usr/include/linux
/usr/local/include
etc.
I tried std::cout and using namespace std; cout but it still says unresolved.
I have imported iostream and cstdlib.
Also, I'm on Ubuntu 12.04 with eclipse 3.7.2.
Code snippet:
#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <iostream>
#include "XPLMDisplay.h"
#include "XPLMGraphics.h"
int XPluginStart(char * outName, char * outSig, char * outDesc) {
/* ... */
std::cout << "test" << std::endl;
/* ... */
}
using namespace std;
UPDATE: I had created the eclipse project from existing code. Creating a new c++ project fixes it. I'll accept an answer that explains what setting in the existing project could cause this (so I don't have to cut & paste all my projects).
Most likely you have some system-specific include directories missing in your settings which makes it impossible for indexer to correctly parse iostream, thus the errors. Selecting Index -> Search For Unresolved Includes in the context menu of the project will give you the list of unresolved includes which you can search in /usr/include and add containing directories to C++ Include Paths and Symbols in Project Properties.
On my system I had to add /usr/include/c++/4.6/x86_64-linux-gnu for bits/c++config.h to be resolved and a few more directories.
Don't forget to rebuild the index (Index -> Rebuild) after adding include directories.
To get rid of symbol warnings you don't want, first you should understand how Eclipse CDT normally comes up with unknown symbol warnings in the first place. This is its process, more or less:
Eclipse detects the GCC toolchains available on the system
Your Eclipse project is configured to use a particular toolchain
Eclipse does discovery on the toolchain to find its include paths and built-in defines, i.e. by running it with relevant options and reading the output
Eclipse reads the header files from the include paths
Eclipse indexes the source code in your project
Eclipse shows warnings about unresolved symbols in the editor
It might be better in the long run to fix problems with the earlier steps rather than to override their results by manually adding include directories, symbols, etc.
Toolchains
If you have GCC installed, and Eclipse has detected it, it should list that GCC as a toolchain choice that a new C++ project could use, which will also show up in Window -> Preferences -> C/C++ -> New CDT Project Wizard on the Preferred Toolchains tab's Toolchains box on the right side. If it's not showing up, see the CDT FAQ's answer about compilers that need special environments (as well as MinGW and Cygwin answers for the Windows folk.)
If you have an existing Eclipse C++ project, you can change the associated toolchain by opening the project properties, and going to C/C++ Build -> Tool Chain Editor and choosing the toolchain you want from the Current toolchain: pulldown. (You'll have to uncheck the Display compatible toolchains only box first if the toolchain you want is different enough from the one that was previously set in the project.)
If you added a toolchain to the system after launching Eclipse, you will need to restart it for it to detect the toolchain.
Discovery
Then, if the project's C/C++ Build -> Discovery Options -> Discovery profiles scope is set to Per Language, during the next build the new toolchain associated with the project will be used for auto-discovery of include paths and symbols, and will be used to update the "built-in" paths and symbols that show up in the project's C/C++ General -> Paths and Symbols in the Includes and Symbols tabs.
Indexing
Sometimes you need to re-index again after setting the toolchain and doing a build to get the old symbol warnings to go away; right-click on the project folder and go to Index -> Rebuild to do it.
(tested with Eclipse 3.7.2 / CDT 8)
Thanks loads for the answers above. I'm adding an answer for a specific use-case...
On a project with two target architectures each with its own build configuration (the main target is an embedded AVR platform; the second target is my local Linux PC for running unit tests) I found it necessary to set Preferences -> C/C++ -> Indexer -> Use active build configuration as well as to add /usr/include/c++/4.7, /usr/include and /usr/include/c++/4.7/x86_64-linux-gnu to Project Properties -> C/C++ General -> Paths and Symbols and then to rebuild the index.
I tried the marked solution here first. It worked but it is kind hacky, and you need to redo it every time you update the gcc. I finally find a better solution by doing the followings:
Project -> Properties -> C/C++ General -> Preprocessor Include Paths, Macros, etc.
Providers -> CDT GCC built-in compiler settings
Uncheck Use global provider shared between projects (you can also modify the global provider if it fits your need)
In Command to get compiler specs, add -std=c++11 at the end
Index->Rebuild
Voila, easy and simple. Hopefully this helps.
Note: I am on Kepler. I am not sure if this works on earlier Eclipse.
I am using Ubuntu 12.04 / Eclipse 4.2.1 / CDT 8.1.1 and I used to have the same problem for quite some time: importing a C++ project from SVN would cause these annoying "Unresolved inclusion" errors and I would instead have to create a new project and copy the files in there as a work-around (still partial, since SVN functionality would not be there!).
At last, I have just found a simple, satisfactory solution:
Go to Project -> Properties -> C/C++ General -> Preprocessor Include Paths, Macros etc. -> Providers and check Enable language settings providers for this project.
Restart Eclipse.
Hopefully that already does the trick.
I had a similar problem with *std::shared_ptr* with Eclipse using MinGW and gcc 4.8.1. No matter what, Eclipse would not resolve *shared_ptr*. To fix this, I manually added the __cplusplus macro to the C++ symbols and - viola! - Eclipse can find it. Since I specified -std=c++11 as a compile option, I (ahem) assumed that the Eclipse code analyzer would use that option as well. So, to fix this:
Project Context -> C/C++ General -> Paths and Symbols -> Symbols Tab
Select C++ in the Languages panel.
Add symbol __cplusplus with a value of 201103.
The only problem with this is that gcc will complain that the symbol is already defined(!) but the compile will complete as before.
For me it helped to enable the automated discovery in Properties -> C/C++-Build -> Discovery Options to resolve this problem.
I simply delete all error in the buttom: problem list.
then close project
and reopen project
clean project
build all
run
then those stupids errors go.
If all else fails, like it did in my case, then just disable annotations. I started a c++11 project with own makefile but couldn't fix all the problems. Even if you disable annotations, eclipse will still be able to help you do some autocompletion. Most importantly, the debugger still works!
I had the same issue using Eclipse CDT (Kepler) on Windows with Cygwin installed. After pointing the project properties at every Cygwin include I could think of, it still couldn't find cout.
The final missing piece turned out to be C:cygwin64\lib\gcc\x86_64-pc-cygwin\4.8.2\install-tool\include.
To sum up:
Right click on the project
Choose Properties
Navigate to C/C++ General > Paths and Symbols > Includes tab
Click Add...
Click File system...
Browse to the location of your Cygwin lib\gcc\x86_64-pc-cygwin\4.8.2\install-tool\include
Click OK
Here is what my project includes ended up looking like when it was all said and done:
You guys are looking under the wrong section.
I realized the difference when I installed in Linux after recently getting frustrated with Windows and the difference was immediately apparent.
In the new setup I have an includes folder in a projected that I created out of existing source. I can expand this and see a ton of includes; however, I cannot add to them.
This lead me to a hunt for where these files were being listed.
They're listed under the Project Properties > C/C++ General > Preprocessor Includes > GNU C++
CDT GCC Built-in Compiler Settings [Shared]
Under that is a ton of includes.
These settings are set by the toolchain you've selected.
I have created the Makefile project using cmake on Ubuntu 16.04.
When created the eclipse project for the Makefiles which cmake generated I created the new project like so:
File --> new --> Makefile project with existing code.
Only after couple of times doing that I have noticed that the default setting for the "Toolchain for indexer settings" is none.
In my case I have changed it to Linux GCC and all the errors disappeared.
Hope it helps and let me know if it is not a legit solution.
Cheers,
Guy.
I had this happen after updating gcc and eclipse on ArchLinux. What solved it for me was Project -> C/C++ Index -> Rebuild.
Just adding yet another bit of advice after trying a bunch of stuff myself and it not working....
I had GCC installed and the path to the includes set correctly. Had the std error as well, and couldn't get anything working for cout (and I suspect anything in the SL...)
Took me awhile to realize that g++ wasn't installed - gcc was but not g++. So just do:
sudo apt-get install g++
Restart eclipse. Assuming above mentioned details about gcc & paths to includes are fine, you should be okay now...
mine was bit easy to fig out right click >run as>run configration
check boxes include system lib,inherited mains