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.
Related
I get source of LLVM and make a project on Visual Studio as guiding in https://clang.llvm.org/get_started.html
I would like to debug clangCodeGen to know how IR is generated or Code Generation do in LLVM. However there is no main() method or something like this in clangCodeGen project.
Do you have any suggestion for me ?
The clangCodeGen project is a static library, so it doesn't have main function and you can't debug it right away.
What you need to do is:
Come up with clang invocation you want to debug. For instance, clang test.c.
Append -v flag and look at the command's output. It should contain large clang command starting with "full\\path\\\\to\\clang.exe" -cc1 ...
Choose whatever project you like in your solution, open its Properties windows and go to Debugging tab.
Set Command field to "full\\path\\\\to\\clang.exe" and Command Arguments to the rest of clang -v output.
Build the solution.
Right-click on the chosen project and select Start debugging.
The code on a sample project looks like this:
errors include:
Unresolved inclusion: <iostream>
Symbol 'std' could not be resolved
Symbol 'cout' could not be resolved
however, running the project successfully outputs:
!!!Hello World!!!
I guess the auto completion portion of it is not looking at the correct files, any idea how to fix this?
You may simply need to rebuild your index, but otherwise you just need to set up the IDE "discovery" options.
I can't tell you how to do that without knowing what Eclipse you have, what toolchain, and all the other unknowns. Clearly your compiler does know where these things are, and that's the important thing.
Anyway, if you look in your project properties, under "C/C++ General", you should find the relevant options in "Preprocessor Includes" and/or "Paths and Symbols".
In particular, "Preprocessor Includes" -> "Entries" -> "C" should list the locations it thinks are right. If they're not, try fiddling with the "Providers" and find some settings that do give the right locations. You may have to run a build for some providers to detect the locations.
instructions by languitar fixed my problem:
Eclipse Juno with CDT Doesn't Add Built-in Include Directories
hes says,
Please
Open the Eclipse Preferences dialog (Windows | Preferences).
Open C++ | Build | Settings.
Open the Discovery tab.
Select the built-in compiler settings entry.
Press the Clear Entries button.
Afterwards eclipse should request the defaults again from the
compiler.
On Arch Linux I had to do this after each GCC version change, because
in that case the locations for the defaults changed as the version is
encoded in the folder name, and eclipse does not notice this.
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
I've got a makefile based project set up that builds my code on multiple platforms. On my Mac I want to use Xcode for debugging though. I've set up an Xcode as an External Build Project I can run the application from within Xcode. The output is shown in Xcode and if the app crashes it drops in to the debugger, but when running the debugger cannot locate the source files, so I just see assembly output. How can I tell Xcode where to locate the source?
I also cannot set breakpoints, but I think that this is all the same problem.
I was able to fix the issue of not stopping at breakpoints by setting a custom working directory for the executable.
Before this change I was able to build successfully using the external scons system from Xcode 4. My code would run when called from XCode but breakpoints would be ignored.
Then in XCode,
Go to Product -> Edit Scheme...
CHeck 'use custom working directory'
and I set this to the same directory as the executable.
Breakpoints then started working.
Ensure -g is included in the compiler options in the makefile.
Set a custom working directory in the scheme, set the executable if this hasn't already been set.
Ensure that the project isn't pulling in dylibs that haven't been compiled with -g. You might need a build step to run make install if the project builds dylibs as well as the main target.
Make sure that "strip" isn't being called. There are environment vars that xcode set that allow you to keep a working makefile when used outside xcode.
Just had this problem and this worked (Xcode 4.6) (got source debugging and working breakpoints)
In "Project Navigator" (the file-folder icon just below the "Run" button), right click and select "Add Files To your-project". Browse to the top level folder where you would normally run the external build, and click Add.
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