Recently, I found a program that is kind of a mix between an IDE and a text editor. It supports the syntax of the language and it does formatting, but it does not build and run the program for you. I am running Mac OS X 10.6.8. I looked up how to build C code using the Terminal application. The format is:
gcc [file]
Pretty simple. The problem is that I cannot change the directory of where the built file is outputted, nor can I change the name. By default, every file compiled is outputted in the home directory by the name of 'a.out.' How can I specify the output directory and name?
Thanks!
gcc has a -o option to change the output name. You can specify the path there. E.g.:
$ ls
program.c
$ gcc program.c -o program
$ ls
program program.c
$ mkdir bin
$ gcc program.c -o bin/program
$ ls bin
program
$
You should probably also want to know about a few other common options:
-std=c99, -std=gnu99: Use the c99 standard / with gnu extensions.
-Wall, -Wextra, -pedantic: Enable extra warnings.
-O0 -ggdb: Compile with debugging symbols. Look up how to use gdb.
-O2: Compile with processor-independent optimizations. Not compatible with -O0.
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.
I use gcc compiled the hello.c:
dele-MBP:temp ldl$ ls
a.out hello.c
now, when I cat a.out:
$ cat a.out
??????? H__PAGEZERO?__TEXT__text__TEXTP1P?__stubs__TEXT??__stub_helper__TEXT???__cstring__TEXT??__unwind_info__TEXT?H??__DATA__nl_symbol_ptr__DATA__la_symbol_ptr__DATH__LINKEDIT ?"? 0 0h ? 8
P?
/usr/lib/dyldס??;K????t22
?*(?P
8??/usr/lib/libSystem.B.dylib&`)h UH??H?? ?E??}?H?u?H?=5??1ɉE??H?? ]Ð?%?L?yAS?%i?h?????Hello
P44?4
there shows the messy code.
I want to know what type of the a.out? is it assembly language? if is why there have so many ??? or %%%?
There are several intermediate file formats, depending on the compiler system you use. Most systems use the following steps, here shown with GCC as example:
Preprocessed C source (gcc -E test.c -o test.i), but this is before compilation, strictly speaking
Assembly source (gcc -S test.c -o test.s)
Object file containing machine code, not executable because calls to external functions are not resolved (gcc -c test.c -o test.o)
Executable file containing machine code (gcc test.c -o test)
Only the first two steps generate text files that you could read by cat or in a text editor. This is BTW a valuable source for insight. However, you can use objdump to see most informations contained in the other formats. Please read its documentation.
Each step does also all steps before it. So (gcc test.c -o test) generates assembly source and object file in temporary files that are removed automatically. You can watch that process by giving GCC the option -v.
Use gcc --help to see some entry points for further investigations.
There is at lot more to say about this process but it would fill a book.
Suppose there are 2 c program named abc.c and xyz.c . Now we want to work with the 2 executables at a time. So we change the name of the ./a.out using
gcc -g abc.c -o abc
gcc -g xyz.c -o xyz
Even gcc -o abc abc.c works.
What does the -g and -o in the above commands specify or describe?
What is the significance of -g and -o in the command for renaming ./a.out file.
Thanks in advance.
-g means to leave debugging information in the output file, it's unrelated to renaming.
-o means to put the result in the specified file instead of the default filename (abc.o for object files, a.out for linked executable files).
From https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html:
-g
Produce debugging information in the operating system's native format (stabs, COFF, XCOFF, or DWARF). GDB can work with this debugging information.
-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.
-g starts becoming useful once you use debuggers such as gdb and lldb. When you attach to a running program and advancing one line at a time printing/altering the state as it changes.
if we specify -g option while compiling, debugging symbols will be available in the output file which will be useful when you try to debug using GDB.
If we won't specify -o option, the output will be placed in default a.out file. So if we run
gcc a.c - output will be in a.out
gcc b.c - output is a.out which is replacing old a.out file
If you want the output not to be a.out file, you can give -o option while compiling
gcc abc.c -o a
-o and -g options are not related.
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
I have written a simple helloworld.c program. I can compile it and run it on linux terminal using gcc and ./a.out command. My query is regarding calling .o file without any extension. For example, to run my program instead of typing "./helloworld.out", I want to run it using keyword "helloworld" on my terminal. Any hints???
Thank You.
Just compile using
gcc -o helloworld helloworld.c
The -o option is for the output file name
Then use:
./helloworld
You need the ./ to tell the shell where the executable resides, since the current directory is unlikely to be in $PATH.