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
Related
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.
okay so I'm on OS and I use terminal to compile my c code. Whenever I make a file using nano or vim called "tst.c" (or whatever the name might be ) then I compile using (my teacher told me to use this everytime so I don't think this is the problem:
gcc -Wall -std=c99 -o tst.c ./tst.c
then it turns into binary I'm guessing. But when I try to edit it again, it has all these weird encryptions I'm guessing like:
��������H���__PAGEZERO��������������������������������������������������������ÿ��__TEXT����������������������������������������������������__text����������__TEXT����������`�����*�������`���������������Ä������������__stubs���������__TEXT����������ä������������ä��������������Ä�����������__stub_helper���__TEXT����������ê������������ê���������������Ä������������__cstring�������
So, question is, how do I revert so I can edit and not make a new file every time???????
You're overwriting your original source file with the compiled executable because of the -o option:
gcc -Wall -std=c99 -o tst.c ./tst.c
^^^^^^^^
You'll need to specify a different output file name in the -o option:
gcc -Wall -std=c99 -o tst tst.c
Otherwise, you can leave the -o option off entirely, and the compiled executable will be written to a file named a.out.
Eventually, you'll want to automate all of this with the make utility, but for now just be aware of how the -o option works.
the -o (name) flag means you are storing the output into whatever you used for name.. so if you add .c to the end of the name you'll see lots of interesting stuff. Man pages are pretty awesome when learning about what each flags do.
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.
I'm trying to build a very simple C program for inclusion into a .deb package. The bulk of the project is in Python. When this program is included into a .deb package, lintian gives me the hardening-no-fortify-functions warning.
On further reading, it appears that Debian expects you to include certain flags while building C programs, and that these flags can be retrieved using dpkg-buildflags --get CFLAGS.
My initial build flags looked like this:
gcc -Wall -pedantic -o somefile somefile.c
Now, I'm building with
CFLAGS=`dpkg-buildflags --get CFLAGS`
gcc $CFLAGS -o somefile somefile.c
However, I continue to get the hardening-no-fortify-functions warning. What am I doing wrong here? Is this now a false positive? Can I just add an override and forget about it?
There are several possibilities of which the third seems most likely, but I've mentioned 1 and 2 in case they are causing you problems too:
dpkg-buildflags --get CFLAGS is returning the wrong thing. On my system it returns:
-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security
If you just execute it from the command line, what do you get?
Your value of CFLAGS is not being passed to gcc. I assume you are using a Makefile here; are those two statements actually adjacent? Do you not want CFLAGS = (with a space) if so? Or are you setting CFLAGS at the command line in which case you should know the debian build tool stuff strips the environment of most things that don't start DEB_, so you will need to set CFLAGS inside whatever builds the package.
The CFLAGS aren't sufficient to eliminate the hardening error. Let's have a look at the lintian error: http://lintian.debian.org/tags/hardening-no-fortify-functions.html and note it says 'Certainty: wild guess'. That does not inspire confidence that it is correct. However, I suspect the actual problem is this: you are not bringing in LDFLAGS. Try:
$ dpkg-buildflags --get LDFLAGS
-Wl,-Bsymbolic-functions -Wl,-z,relro
You'll need those on your linker line.
This approach would seem to work (i.e. at least compile):
gcc `dpkg-buildflags --get CFLAGS` `dpkg-buildflags --get LDFLAGS` main.c -o main
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.