I have a set of C files to compile using gcc and make. The build process works fine.
I want to know if I can obtain - during compilation - one C file containing all the source code without any preprocessor macro.
One simple was would be to make a file that included all the other source files.
$cat *.c > metafile.c
This would construct such a file, depending on how you set you 'pragma once' and ifndef's this file would probably not be able to compile on its own.
On the other hand, if what you want in a file where all the preprocessor macro's have been unfolded and evaluated, then the answer is to add the following to gcc:
-save-temps
then the file .ii will contain the unfolded and evaluated macros
If you include all files to the gcc compiler at once you could use
gcc -E main.c other.c another.c
This will also include the stdlib functions maybe use -nostdinc
You can't - normally you invoke the compiler to compile just a single source file, resulting in an object file. Later you call the linker on all of the object files to create the executable - it doesn't have the original C source code available.
You can, however, create a separate shell script that calls gcc with the -E option just to preprocess the source files, and then use the cat utility to put all the sources in a single file.
You can use the -save-temps option to get the intermediate outputs. However it will be one output file per source file. Each source file gets compiled separately and represents a compilation unit which can't be mixed up.
You can also use the -E option, however that will only run the preprocessor and not continue compilation.
Related
Let us assume that we have a source file "a.c".
The "a.c" source file is used in building programs "Prog1","Prog2", and 'Prog3".
"Prog1" also uses source file "x.c"
"Prog2" uses source file "y.c"
"Prog3" uses source file "z.c"
Assume that "a.c" uses a function called "foo()" that is only defined in "x.c". Hence "Prog1" would get built, but "Prog2" and "Prog3" would not compile.
Also assume that "a.c" needs to call function bar1() when building program Prog1, bar2() when building program Prog2, and bar3() when building program Prog3.
How should we create the automake Makefile.am to support this?
I have been trying to specify distinct preprocessor directives when building each program in the automake file "Makefile.am", but so far could not see how it is done.
Any help would be appreciated. Thanks.
Simplest solution? Create three different rules for three different object files all built from the a.c source file.
Then each rule can easily add extra flags needed for the specific build.
bin_PROGRAMS = prog1 prog2 prog3
prog1_SOURCES = a.c x.c
prog1_CPPFLAGS = -DPROG1
prog2_SOURCES = a.c y.c
prog2_CPPFLAGS = -DPROG2
prog3_SOURCES = a.c z.c
prog3_CPPFLAGS = -DPROG3
But to use this you need to make sure you call AM_PROG_CC_C_O in your configure.ac, since a.c is then compiled three times with different options.
I'd like to be able to see which header is actually included when I compile. For example, I have two very different check.h files (one is a linux-header thing, the other from the unit test system).
Is there a setting in gcc or some language command/macro that would show where header files are being included from?
You can use the -E flag.
gcc -E source.c
This will show you the “annotated” preprocessed source, including the absolute paths of headers included using <> and relative paths of headers included using "". Keep in mind that it will be a lot to trudge through, especially if you include a lot of system headers (which in turn include implementation-specific headers etc.).
Using grep, you could filter these results with:
gcc -E source.c | grep '^# 1 '
The # n is an annotation describing the line number of the currently-included file, which is always # 1 at the beginning of a file.
You can try adding -MD to your compilation command. This generates a dependency file (suitable for Make) which will tell you all of the include files that your source code depends on.
This can be added to an existing compile command without fear of breaking the compilation, since it generates the dependency file as a side effect of normal compilation.
I compile an example.c file that has the line:
#include "parse/properties/properties.h"
The compiler creates get an example.o file. Is the path to the header file included in the example.o file? or is that information external?
It may or may not, the object file format is not standardised (the standard does not even mention "object files"). A compiler might insert the #include for debugging purposes, or it may skip it completely.
Note also that #include'ing is done by the compiler in what the standard desrcibes as the first phase in translation, using a textual preprocessor; the #include-directive tells the preprocessor to copy verbatim and inplace the contents of another file. This happens long before actual object files would be produced
It is implementation defined but generally when you compile with debugging options ( eg -g in gcc ) the file paths are included to aid you in debugging
gcc -MD file.c creates a dependency output file named file.d. But I dont understand the need of creating this file ( dependency file ), because when error comes while compilation, no dependency file is generated. So can anyone throw some light when he/she has used this dependency file or some usefulness of this file / feature of gcc.
The file.d file can be understand by make. You often first generate the .d files, include them into your Makefile and then compile the c-files only if one of the included headers has changed.
Don't bother about if you don't use make.
GCC documentation says:
Instead of outputting the result of preprocessing, output a rule suitable for make describing the dependencies of the main source file. The preprocessor outputs one make rule containing the object file name for that source file, a colon, and the names of all the included files, including those coming from -include or -imacros command line options.
got a nasm project and i'm calling a c function from it
I put the name of the function in "extern"
and when linking i put all the links together but i can an error of "undefined reference to"
here is my compile/link command
gcc -o Project4 Project4.o array1c.c readdouble.o writedouble.o readarray.o printarray.o addarray.o invertarray.o invertarray2.o invertarray3.o averagearray.o quicksort.c
I would first compile all of your .c files using the "gcc -c" command into object files, then link those resulting .o files (such as "array1c.o" and "quicksort.o") together with your other pre-existing object files and see if that still gives you an undefined reference. That may be an unnecessary step, but I've never combined raw .c files and .o files in a single call to gcc.
You may also have to add an underscore to the beginning of any c-functions called ... I know this an be a platform dependent thing (i.e., Linux typically doesn't need underscores on c-functions whereas OSX and some other UNIX platforms do).
Lastly you could try, using ld, to just link all the object files together at once rather than linking some of the object files together into Project4.o, and then linking that to what you had assembled using nasm (at least that's what I'm assuming you're doing, i.e., you're making a Project4.o, and then calling functions from that in your assembly code).
Hope this helps,
Jason