I'm trying to debug a C++ programme in Eclipse Indigo. The project is using autotools/configure (and the respective plugin) as build system.
After successful build I right-clicked on the binary in the project browser and chose "Debug As". Then I used the file browser to select the binary. Clicking on "Debug" then opens a dialog which just says "program is not a recognized executable".
Any ideas?
I found the answer: the binary parsers configured in eclipse were the wrong ones. Adding the correct binary parser under Project --> Properties --> C/C++ Build --> Settings solves he problem.
If you're using libtool in your project, what looks like the binary may actually be a wrapper script used to set LD_LIBRARY_PATH and stuff like that before executing the real binary (which is stored in the .libs directory). This may be what causes Eclipse to fail, but I'm not sure how you should go about fixing that.
There seem to be a bit of documentation about Eclipse CDT and libtool on the internet which may have the infos you need though: http://www.freerdp.com/wiki/doku.php?id=eclipse#debug_configuration
From OSX snow leopard on, gcc seems to build 64 bit executables by default. And those won’t be recognized from Eclipse in return. To solve the error, you’ve got to explicitly set your architecture to i386.
Enter your project properties and add the command line option “-arch i386″ for each C++ Linker, C++ Compiler and C Compiler. After a clean build, you should be clear to debug again. In Linker options make sure to NOT set it up as -Xlinker option.
Original Source
Related
I have searched all over the web and have tried everything I could to fix this problem, to no avail. So here I am making a new post, hoping to fix this terribly frustrating problem.
I have the Eclipse IDE for C/C++ Developers that on my Windows 7 computer. The version of Eclipse is Luna Service Release 2 (4.4.2) and the build ID is 20150219-0600.
I have MinGW installed onto my computer, and I downloaded all the package choices just to be safe.
I create a C++ project. The "Project type" is Executable > Empty Project and the "Toolchains" is "Cross GCC".
I select both "Debug" and "Release" in the "Configurations".
I leave the "Cross compiler prefix" blank because I don't know what to write. I then put in "F:\MinGW" as the "Cross compiler path".
I create a new source file in the project and write the infamous Hello World program (in C++, of course). When I save the project, it gives me two errors in the "Problems" tab:
Program "g++" not found in PATH
Program "gcc" not found in PATH
When I build the project, it adds on another error:
Program "make" not found in PATH
I go to Project > Properties > C/C++ Build > Tool Chain Editor and change the "Current builder" from "Gnu Make Builder" to "CDT Internal Builder".
The error Program "make" not found in PATH then disappears.
I go to Window > Preferences > C/C++ > New C/C++ Project Wizard > Makefile Project and set the "Binary parser" to "PE Windows Parser". I clear the project, save the project, and build the project, but the 2 errors remain.
If I go to Project > Properties > C/C++ Build > Environment and set the value of the "PATH" variable to "F:\MinGW\bin", still nothing happens and the two errors remain.
Now, when I attempt to run the project (ctrl + F11), it spits out the error Launch Failed. Binary not found.
In the "Project Explorer", I see a HelloWorld file that contains an "Includes" file (containing the compiler libraries?), a "Debug" folder (containing a HelloWorld.exe and a main.o), and a main.cpp file (containing my Hello World program).
Thank you in advance for taking the time to read this and for trying to help.
You need to update environment variable PATH. Check this page.
You must add C:\MinGW\bin; to your user PATH environment variable manually.
I suggest, not a solution, at least you want to make sure the following.
Recheck that the PATH is set up right. Sometime we think we did, but the computer does not. In the command line, type the following command to see the gcc installed right and PATH is set right.
gcc --version
echo $PATH
or
echo %PATH%
All things are right as you did above, but it does not work?, Then remove and reinstall mingw and eclipse CDT cleanly. Don't change and keep the default options in the Eclipse CDT. Without any option changes CDT, it should work NOWADAYS. Eclipse CDT(8.7, 8.8) is pretty much stable.
Blessings,
(a debtor)<><
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
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
I'm a new C++ programmer using Eclipse. Eclipse seems to recognize C++: It let me create a new C++ project and understands the syntax. However, whenever I try to #include anything, I get an "Unresolved include" error.
I have CDT installed. I also just installed MinGW and MySys and set the path variables correctly.
It looks like something's still missing from Eclipse though -- when I right click on my project and go to "properties -> C/C++ build -> Settings" all I can access are the "binary parsers" and "error parsers" tabs. The window should look like this...
...but I can't see the tool settings, build steps or build artifact tabs.
That's all my research has turned up so far. What should I do next?
Settings on screenshot related to build process. For correct work editor (autocomlete, includes) you need to set same dirs in the C/C++ General/Paths and symbols, includes, GNU C++. Also, if path variable containt dir with g++ ecplise should to have prepared configuration if you choose mingw toolchain while creating project.
Update for comment
Why compiling C++ in Mac always create *.dSYM directories?
Is there a way to disable that?
It's because your Xcode project is set up to build debug symbols with an external dSYM file. This is actually very handy for release builds, as it means that you can strip debug symbols from your app, and when a user sends a crashdump to you, you can use the original dSYM file to generate a proper stacktrace for debugging.
Anyways, you don't need to disable debug symbol generation in your project. Instead, just change the debug symbol type to DWARF (instead of "DWARF with dSYM File"). You can also use Stabs, but that's the old format.
Edit: Ah, I see you meant from the command line, not from Xcode. I'm not sitting in front of my mac atm, but I see from the gcc4 manpage than you can specify -gstabs to use the Stabs format.
I assume your using Xcode. Go to "Project"/"Edit Project Settings" menu item, click on build tab, under "GCC 4.0 - Code Generation" section, uncheck Generate Debug Symbols. You can type in "sym" in search field to help find it.