I have a question regarding a compiling flag -fobjc-weak. Currently, I work on the project that is generated using CMake, it uses C++ mainly and some minimal objective-C code to run the app. When studying compiling flags I saw that some of the Cmake target libraries are compiled with -fobjc-weak and some does not. This is not the flag that I set in CMake so I assume it is automatically added by XCode. My question is why? Where does it come from and what is the reason and implication of this flag being there? I could have missed something but I cannot seem to find out at which stage this flag gets added.
Another piece of information is that I use a iostoolchain.cmake It is identical to this project tool chain. It has a line like this:
#Check if Xcode generator is used, since that will handle these flags automagically
if(USED_CMAKE_GENERATOR MATCHES "Xcode")
message(STATUS "Not setting any manual command-line buildflags, since Xcode is selected as generator.")
I dont really understand how Xcode end up deciding which flags are being added but that is my suspection to why I am seeing this line added when compiling.
https://github.com/leetal/ios-cmake/blob/master/ios.toolchain.cmake
Cheers!
I am looking for a way to get the command invoked to compile a specific file inside CMake as a variable. This is the same "command" as it shows up in a compile_commands.json. It is of the form:
%gcc% %bunch of -DSOMETHINGS% %bunch of -Isome/files% -o %cpp files% ... etc.
The project I am in the process of porting to CMake makes a note of the invoked compiler command inside a file, which I am changing to use the configure_file cmake mechanism. The configured file is needed prior to compiling a specific object.
While searching, I found this answer that is pretty much the same question: cmake - get the used commandline flags "-D". However, it is more than 3 years old, and only concerns retrieving a list of the "-D" flags, which the user solved by manually keeping track. I consider this suboptimal. If this command is written into compile_commands.json, I should be able to access this somehow, right? When exactly is compile_commands.json written? Any change I can get this to write that file for like, a non-functional dummy target or something, then access it and use it to configure my file in the real project?
I know this is kind of against the ethos of CMake, and I love the fact that I don't ever have to manually manage the flags myself, however I find it hard to believe there is no way to get them for a specific file, am I overlooking something?
I have looked at CMake properties on source files, and retrieving them using get_property, however I don't believe I can reconstruct the whole command from these.
I am currently generating Unix makefiles, although the mechanism should optimally also work when generating MSVC project files, which I know CMAKE_EXPORT_COMPILE_COMMANDS does not.
Any thoughts and input on this is greatly appreciated!
I am working on modifying a rather large program (NS2 network simulator), and it would be nice to be able to debug it with Eclipse. I configured the makefiles ( add -g to CFLAGS ) to make gcc generate the debugging symbols, and they are indeed generated, but Eclipse refuses to actually find the code associated with those symbols. I imported the HUGE folder of source code using the "Makefile Project with Existing Code", and when I hit "debug" it runs the program. When I tell the debugger to stop, it often stops in a method I recognize, but when i click on the method's name, it says "source not available" even though the source file where the method is defined is actually open in another tab. I do have all the sources imported into the project. Am I missing something in the make configuration?
^long confusing explanation, I know... see screenshot, :
http://imageshack.us/photo/my-images/651/zzz1fu.jpg/
Note that IPKTAgent::deBurst() from the above screenshot is declared in integrated_agent.h -- that is the file I have open in the other tab.
also, when I expand the entry for the executable I'm debugging in the project explorer, it only lists some of the files it is composed of. What gives? (see screenshot, there should be more files on the list, the ones I'm working with are missing).
screenshot: http://imageshack.us/photo/my-images/96/zzz2z.jpg/
Just tested it. Works for me. The only issue was that I forgot to add -O0 option to disable optimization; it can be an issue in your case too.
What I can suggest:
Try to disable optimization
Check that compiler options you use are really applied. You use CFLAGS, but I see c++ in tags, so it is possible that you should use CXXFLAGS (it can depend on build tools you use)
IPKTAgent::deBurst() is declared in integrated_agent.h. But where is it implemented? Check that it is implemented in header and/or you can access to the source file where it is implemented.
Check that you can debug your executable with gdb
Try to create simple automake/autoconf based project and check that you are able debug it in gdb and eclipse. You should be able.
I am compiling on windows with cdt/mingw. I like to compile warning free. I get the following warning:
auto-importing has been activated without --enable-auto-import specified
on the command line.
The following page suggests the way to deal with it is to just adding that option to the command line of ld.
4.8 ld and WIN32 (cygwin/mingw)
The question is thus, how do you change the default command line switches for the built in toolchains?
I would also like to set the warning level of gcc.
You have to send the parameter to the linker via gcc's -Wl parameter:
-Wl,option
Pass option as an option to the linker. If option contains commas,
it is split into multiple options at
the commas. You can use this syntax to
pass an argument to the option. For
example, -Wl,-Map,output.map passes
-Map output.map to the linker. When
using the GNU linker, you can also get
the same effect with
-Wl,-Map=output.map.
So, you need (and me too :)) -Wl,--enable-auto-import.
For controlling warning levels, see the official docs.
Hi so far I have found a partial solution to this problem. I have not found how I can change the default toolchain options, but I have found how to change them on a project basis.
In project->properties->C++-build->settings
It seems to make more sense if it would be in tool chain editor, but it isn't.
There you have a tab called Tool Settings and looking down there is MinGW C++ Linker->Miscellaneous.
Here on the right you can add extra linker options. Above you also have the compiler and warning settings are implemented as checkboxes which is nice.
So far at least I have gotten started, only a pity I have to do that over for every project individually.
Oh for further confusion, this is not always there, and I have some old projects from before I installed MinGW and who thus have no real toolchain installed. In that case the settings pane only has the Binary Parsers and Error Parsers tabs, so it looks completely different. The secret is in having the Tool Settings Tab. Very dynamic and for the rainforest like settings dialog of eclipse also very confusing.
I'm having trouble debugging a C++ program in Eclipse (the latest RC of Helios, updated with latest CDT from within itself) on OSX.
The program is very simple (esentially Lesson 2 from NeHe's OpenGL tutorials), consisting of one cpp file and, using OpenGL and Cocoa frameworks, and linking with libSDL.a and libSDLmain.a.
The structure of the project is very simple: the source file(s) are in a subdirectory of the project called src/ and the executable is built to the project's root directory.
The problem is that whenever I try to add breakpoints and debug it, the breakpoints seem to get hit perfectly but no source is displayed - instead I just get a "No source available for main()" error in the code window.
The compiler flags have optimisations set to none, and both the compiler and linker have the debug symbols flag set (-g).
The debugging setting in Eclipse is set to "Standard spawn progess" and the debugger is set to "gdb".
Now the strangest thing is that if I try to debug the exact same executable - ie. the exact same one that was built by Eclipse - using gdb from the Terminal (shell) then everything works fine. Breakpoints are hit, source code is displayed, no problems at all.
I've made sure that both Eclipse and the shell are using the same gdb executable, and they are (it's /usr/bin/gdb).
Now I may be wrong, but this all suggests to me that there can't be a problem with the compiler and linker flags (because the same executable is debuggable from the shell), so presumably the problem must be with how gdb is being invoked from within Eclipse? Perhaps when run from Eclipse gdb is picking up different config files or something than when it's run from the shell? (Anyone know?)
I'd really appreciate any help with this because it's slowly driving me loopy!
Please let me know if there are any other details that would be useful - exact version numbers of Eclipse/cdt/gdb, exact linker/compiler command lines, etc. - and I'll very gladly update this post with them.
Many thanks in advance,
thoughton.
--- edited # "14 hours ago" ---
I tried the "add filesystem path" (with "search sub-folders") option, but that didn't work. I also tried creating a new completely flat project, but that didn't work either.
I even tried getting a Galileo release (eclipse-SDK-3.5.2RC4 with CDT update), but that made no difference (apart from gdb being slower to launch).
And here's something else strange I noticed: once I get the "No source available" message, if I then switch Eclipse's Console to display the "gdb" console, and also turn on "Verbose console mode" so I can communicate it, I can then issue "l" and "bt" commands and have them work succesfully, showing the correct source and stack where my breakpoint was hit. Which, correct me if I'm wrong, must mean that the information is there and gdb is being invoked correctly - so why will Eclipse not see this information?
I'm getting close to giving up on Eclipse to be honest... I came to it with such high hopes, too.
Any additional help or thoughts would be hugely appreciated.
t.
This thread suggests:
-g -O0
for debug flags to be set for Eclipse CDT compilation.
Sometime, it is simple a problem of rebuilding completely the application (like here)
See also this thread describing a similar situation:
I have noticed that sometimes in Eclipse I have to go and specifically add the path to my source files using the "add filesystem path" (with "search sub-folders") in the Debug Dialog (even when they are in the same project I am debugging), but I have not noticed a pattern to when I have to do this. But it may be worth a try.
I found the answer! And it's embarrassingly simple.
The problem was that I was using the Release version of SDL instead of the Debug version! (I had 'libsdl' from MacPorts whereas I should have had 'libsdl-devel'.)
So my generic answer is: make sure the libs you're linking against were compiled with debug flags set too, it's not always enough to just make sure your own code has them set.
Here is another reason for this problem. My configuration used -g3 as the option to gcc. Changing it to -g solved the problem. There seems to be some incompatibility between gcc and gdb. I checked that gdb was the latest revision (using apt-get).
I would like to add a little new blood to this old thread.
I encountered this problem when I tried to compile and debug a gnu arm project.
I solved the problem by modifying the Makefile:
adding "-g -O0" at the end of this line "CFLAGS += -Wall -Werror -O3"
Go to project Properties, C/C++ Build -> Settings. On the first tab (Tool Settings) under Cross GCC Compiler click Debugging and set Debug Level to Maximum (-g3)
I had this issue when I compiled the latest gcc, but did not update to the most recent gdb. After the update, it worked properly.
Thought to mention, that in case you are using cmake to build the project, one approach to the solution will be to add the "debug flag" to the cmake command, i.e. -
$ cmake /path/to/main/cmake_file -DCMAKE_BUILD_TYPE=Debug
For anyone else who may experience this issue,
I installed the linuxtools/valgrind plugin last night to do some memory profiling, and it seems that this broke the normal gdb. when i removed the linuxtools plugins everything started working as normal again.
So you might like to try that.
I had a similar problem. I was using CFLAGS=-Wall -O2 -fPIC -DPIC -lm -lasound and never had problem to compile it but when I tried to debbug it on Eclipse IDE I get this error: No source available for "main() at 0x401080" then I added -g to this line and it worked well:
CFLAGS=-g -Wall -O2 -fPIC -DPIC -lm -lasound
This issue depends on how gdb is being invoked. I found I needed to manually specify the source file locations when I got that error. Even though I'd already configured that under project properties. After doing so, Eclipse no longer had a problem supplying the appropriate source.
Using the release versus debug version of a library may be your specific problem (if you were building a library from source then debugging it). If someone is using a precompiled library, they'd never be able to set breakpoints within it and so that fix wouldn't apply to them.
Encountered the same problem once. You just have to go to your Project Properties, by hitting ALT+ENTR or right click project and scroll down at the bottom and you will find Properties. Expand C/C++ build on the left. Then click on settings. Once you open the settings, then click on tool settings. In the MCU GCC Compiler, there is a debugging option. Click on debugging and add
-g -O0
in the Other debugging flags. Trying debugging the project now.
I just faced with this issue and after take some time to find it out, I realize that the Arguments and Main tab in Debug Configurations dialog are conflicting each other.
Make sure that C/C++ Application and Programs Arguments point to the same binary file.
Seems like this message can have plenty of reasons to show.
For me (in the context of micro controller debugging) it was the link-time optimization. With -flto it broke; removing -flto from the "Other Options" field fixed this for me.
In Eclipse Neon (4.6) see Project -> Properties -> C/C++ Build -> Settings -> Tool Settings -> C Compiler -> Miscellaneous -> Other options.
Add this to your CMakeLists.txt
set(CMAKE_BUILD_TYPE "Debug")
set(CMAKE_CXX_FLAGS "-g")
set(CMAKE_C_FLAGS "-g")