gcc not generating debug files - c

I want to compile an application with debug information using gcc and gdb. When I do the following, the debug (.dSYM) files are generated correctly:
gcc -ggdb src/test.c -o build/test
If I, however, split this into a compile step and a link step, like this:
gcc -ggdb -c src/test.c -o build/test.o
gcc -ggdb build/test.o -o dist/bin/test
… no .dSYM files are generated at all, and therefore gdb does not show me the source line of code where a crash occurs, which makes debugging a lot more difficult. Since I have quite a bit of source files, compiling and linking them all in a single gcc invocation is not possible.
How can I let gcc generate the .dSYM files when using separate compile and link steps?

Check the second comment on the first answer in this post.
Its a quirk. Maybe you can run the "dsymutil" program manually to generate dSYM files.

You can also specify -g3 in you compilation options so that gcc puts debug symbols right into the binary, not in a separate file. Not sure if that is what you need.

Related

Why gcc compiler giving the complied file a new name?

I have reinstalled mingw in my system and downloaded the gcc compiler.
I was shocked after compiling the first file which was "subject.c" but the name of the compiled file which gcc returned was "a.exe". It should be "subject.exe" but do not know why this happened.
Can anyone please explain the reason behind this ?
expected:
gcc subject.c
ls
subject.c subject.exe
tried:
gcc subject.c
ls
subject.c a.exe
-o can be used to give the name of the output file.
For example,
gcc -Wall -Wextra -pedantic subject.c -o subject.exe
(Do enable your compiler's warnings!)
gcc names its output files, in the absence of other instructions, a.out or a.exe depending on system environment because that is what it's supposed to do.
To override this default behavior, you can use the -o flag which tells gcc that the next argument is the desired name for the output file. For instance:
gcc -o subject.exe subject.c
There is no automatic functionality built into gcc to strip a source file of its file extension and add .exe to the end but this can be done manually with Makefiles or other similar scripts, for instance you can write a Makefile with the following contents:
%.exe: %.c
gcc -o $# $<
Then a command like make subject.exe would be translated to gcc -o subject.exe subject.c, which may be what you're looking for.
There is functionality built into gcc to strip source files of their extensions during different parts of the compilation process, which may have been what confused you. For instance a call like gcc -c subject.c can be expected to produce an object file called subject.o, likewise gcc -S subject.c can be expected to produce an assembly language file called subject.s, however this does not apply to executable files not only for historical reasons, but because programs can be compiled from multiple source files and there is not always a clear way to choose a name for the executable output.

Compile Multiple C Files on Mac?

I am new to C and using GCC. How do I compile multiple C files and then run them? I have multiple miles and each has different functions and they are supposed to run through the main.c file. My friend showed me through Windows but I am having issues figuring out how to do it on Mac.
What I was told:
Compile both files individually first:
gcc -Wall -c .\main.c
gcc -Wall -c .\file.c
Then compile both together into an executable:
gcc -o program file.o main.o
Then run executable with .\program.exe
You should probably investigate makefiles, but this is quite easy. The following should do the trick.
gcc -o program file.c main.c
Feel free to add in whichever -W warning flags you want.
Note also that Macs do not use \ as a directory separator but rather /, and executable files do not typically end in .exe.

Can't name executable with specified optimization

I have to turn off optimizations while compiling c code I wrote while using the gcc compiler on a linux. I have found that I can compile the code but I can only get the code to compile without the executable name specified (default to a.out).
So this works:
gcc -O0 Problem04b.c
But my problem is that I have to submit this assignment and I can't submit an executable called a.out because my instructor needs to know which problem it is. I realize I can probably just run
cp a.out Problem04b
then
rm a.out
but I want to know if there is a way I can just compile the code directly into the executable Problem04b. I've tried to run the command like this:
gcc -O0 Problem04b Problem04b.c
but I'm having no luck.
Thanks for your help.
It's the -o flag:
gcc -O0 -o Problem04b Problem04b.c
To specify the output file, you need to use the -o <filename> option with gcc.
Note : Please mind the lower case here
In your case, it should be
gcc -O0 -o Problem04b Problem04b.c
For reference: From gcc manual
-o file
Place output in file file. This applies to whatever sort of output is being produced, whether it be an executable file, an object file, an assembler file or preprocessed C code.
Actually, you also want to get warnings (that won't change the produced executable, but it is very helpful to you), so compile with
gcc -O0 -Wall -Wextra Problem04b.c -o Problem04b
The -Wall option asks for nearly all warnings, the -Wextra option asks for even more of them.
To run your thing (the ./ is useful because of possible PATH issues):
./Problem04b
Notice that -O0 is optional (since it is the default), you could remove it.
gcc -Wall -Wextra Problem04b.c -o Problem04b
If you want real optimization, e.g. for benchmarking, use e.g. -O1 or -O2 or -O3
You probably want to compile with debug information, then
gcc -g -Wall -Wextra Problem04b.c -o Problem04b
and of course you need to learn how to use the GDB debugger. So read some tutorial about that, then type
gdb ./Problem04b
You'll get a (gdb) prompt. Try help at that time.
You probably want to read the chapter about invoking GCC of the GCC documentation.

gcc is working, but not yielding executable

My C compiler was working a second ago and making executables, but I started working on a new .c file and suddenly it won't work anymore. I haven't changed anything and I'm still using the same commands, Gitbash version, etc. The compiler is still able to catch errors, so gcc works, but after calling:
gcc -std=c99 my_file.c
there is no executable called my_file.exe. Help sites online suggest installing additional software to fix the error, but I'm hesitant to do so because everything was working fine earlier and I don't want to aggravate the problem with additional software.
Since you have not specified the name of the file to output, GCC will output a.exe.
If you desire output named something else, you must use the -o flag, for example:
gcc -std=c99 -o my_file.exe my_file.c
On Unix, that compiler command would generate an executable a.out. You may find that there is an executable with a default name — but I don't have Windows to check what that name is. Guesses might include a.exe, a_out.exe, aout.exe, etc.
To get my_file.exe:
gcc -std=c99 -o my_file.exe my_file.c
If you don't specify an output -o flag you will get a.exe by default (a.out on other platforms),
gcc -std=c99 my_file.c
If it is working, produces
a.exe
I think you wanted
gcc -std=c99 -o my_file.exe my_file.c

How can I know in which step (Pre-Processor,Compiling, Linking) my program failed to compile?

How can I know in which step (Pre-Processor,Compiling, Linking) my program got compilation failure?
For example, I wrote a program of 3 source files: a.c ,b.c, c.c and all three of them included the header file, h.h, which contains all the prototypes of all the source files, but I also implemented one function, in the header file. I know it's wrong to do, but I wonder on what stage did the program crash, Is it the linking or the compiling, I got an error message, Is this say that the problem is at the linking stage? (otherwise I'll just get a red underline on the mistake from the compiler?)
Where can I read about linking and what I shouldn't do regarding headers and source files and linking errors?
(I work in Linux, with Eclipse)
You find the location of the error by separating compiling and linking. An error due to the precompiler is unusual and also found during compiling. This is how compiling works on the command line:
Compile step:
gcc -c -o a.o -pedantic -Wall a.c
gcc -c -o b.o -pedantic -Wall b.c
gcc -c -o c.o -pedantic -Wall c.c
link step:
gcc a.o b.o c.o -o prog
Of course you need to specify whatever other flags that are necessary (e.g. -l for linking to a library etc.)
Then read the errors and warnings (!) carefully and you shall find the problem.
Your program crashes only once you have pre-procesed, compiled and linked your program to generate an executable that you can run. A crash is a run-time error.
Re preprocessor/compilation/linking:
You didn't specify what platform/environment you are working in, but in a Linux/Unix environment it is easy to determine if you are getting problems with the linker as you usually get a message with ld.
Compilation errors usually syntax related and easy to identify that way (e.g., mismatched parens, missing semi-colons, etc) (Aside, as a general rule, I would recommend you always compile with the highest warning level, and then consciously determine which warning messages to ignore.)
I am not at a system were I can try it out, so I'm not sure of the pre-processor throws out specific easily identifiable error/warning messages, or if they just get passed on to the compiler and get spit out at that stage.
None of these steps crash your program, that only happens (if it does) after all these steps have been completed successfully.

Resources