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.
Related
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.
I have a question about make file using gcc, below is my code in makefile. I got cannot specify -o when generating multiple output files error, but I just cant see where the problem is. Can someone point out my mistakes? Thanks!
BASE_FILES=bwtsearch.c bwtsearch.h bwttext.c bwttext.h chartable.c chartable.h common.h occtable.c occtable.h plset.c plset.h strbuf.c strbuf.h
BASE_ENCODER_FILES=bwtencoder.h bwtencoder.c
BWTSEARCH_FILES=${BASE_FILES} main_bwtsearch.c
BENCODE_FILES=${BASE_ENCODER_FILES} main_bencode.c
PSEARCH_FILES=${BASE_FILES} main_psearch.c
PSEARCH_NL_FILES=${BASE_FILES} main_psearch_nl.c
PENCODE_FILES=${BASE_ENCODER_FILES} main_pencode.c
PENCODE_NL_FILES=${BASE_ENCODER_FILES} main_pencode_nl.c
DEBUG_FILES=${BASE_FILES} main_debug.c
all: bwtsearch psearch psearch_nl pencode pencode_nl bencode
clean:
rm psearch psearch_nl bwtsearch pencode pencode_nl bencode bwt_debug
bwtsearch: ${BWTSEARCH_FILES}
gcc -o bwtsearch ${BWTSEARCH_FILES}
bencode: ${BENCODE_FILES}
gcc -o bencode ${BENCODE_FILES}
psearch: ${PSEARCH_FILES}
gcc -o psearch ${PSEARCH_FILES}
psearch_nl: ${PSEARCH_NL_FILES}
gcc -o psearch_nl ${PSEARCH_NL_FILES}
pencode: ${PENCODE_FILES}
gcc -o pencode ${PENCODE_FILES}
pencode_nl: ${PENCODE_NL_FILES}
gcc -o pencode_nl ${PENCODE_NL_FILES}
debug: ${DEBUG_FILES}
gcc -o bwt_debug ${DEBUG_FILES}
below is the output of the console :)
gcc -o bwtsearch bwtsearch.c bwtsearch.h bwttext.c bwttext.h chartable.c chartable.h common.h occtable.c occtable.h plset.c plset.h strbuf.c strbuf.h main_bwtsearch.c
clang: error: cannot specify -o when generating multiple output files
make: *** [bwtsearch] Error 1
There should be no need to put header files in the list of files to be compiled, since a stylistically correct header file generates no executable code.
It used to be the case that it was mostly harmless to put header files in the gcc command line, because the compiler would add no executable content to the output file as a result of parsing and compiling a header. However, since gcc version 4 or so, and for roughly the same amount of time for clang, header files on the command-line are compiled into precompiled headers for use in later compile steps.
That means that compiling
gcc x.c y.h
will create two products: an executable generated from x.c and a precompiled header generated from y.h.
Gcc (at least up to version 6.3) lets you specify an explicit output filename in this case, although I believe the consequence is that the precompiled header file is written as x and then overwritten by the executable. (It doesn't let you specify an explicit output name in most other cases, such as when you use the -c, -S or -E options to produce an output for every input.) But clang, possibly more sensibly, produces an error when you an explicit output filename with the -o option and you have more than one output, even when that output is a precompiled header (which you possibly didn't intend to produce).
(Confusingly, on Mac OS X, the command gcc normally invokes the clang compiler. I suppose this is to avoid breaking scripts which incorrectly believe that gcc is the generic name for a C compiler.)
The solution is to remove the header files from the list of files to be compiled.
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.
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.
I am a complete novice with Linux. I have Mint on a laptop and have recently been playing around with it.
I wrote a simple C program and saved the file.
Then in the command line I typed
gcc -c myfile
and out popped a file called a.out. I naively (after years of Windows usage) expected a nice .exe file to appear. I have no idea what to do with this a.out file.
Name it with -o and skip the -c:
gcc -Wall -o somefile myfile
You should name your sourcefiles with a .c extension though.
The typical way of compiling e.g. two source files into an executable:
#Compile (the -c) a file, this produces an object file (file1.o and file2.o)
gcc -Wall -c file1.c
gcc -Wall -c file2.c
#Link the object files, and specify the output name as `myapp` instead of the default `a.out`
gcc -o myapp file1.o file2.o
You can make this into a single step:
gcc -Wall -o myapp file1.c file2.c
Or, for your case with a single source file:
gcc -Wall -o myapp file.c
The -Wall part means "enable (almost) all warnings" - this is a habit you should pick up from the start, it'll save you a lot of headaches debugging weird problems later.
The a.out name is a leftover from older unixes where it was an executable format. Linkers still name files a.out by default, event though they tend to produce ELF and not a.out format executables now.
a.out is the executable file.
run it:
./a.out