Linux gcc build makefile
These targets are available from the ‘ gcc ’ directory:
This is the default target. Depending on what your build/host/target configuration is, it coordinates all the things that need to be built.
Produce info-formatted documentation and man pages. Essentially it calls ‘ make man ’ and ‘ make info ’.
Produce DVI-formatted documentation.
Produce PDF-formatted documentation.
Produce HTML-formatted documentation.
Generate info-formatted pages.
Delete the files made while building the compiler.
That, and all the other files built by ‘ make all ’.
That, and all the files created by configure .
Distclean plus any file that can be generated from other files. Note that additional tools may be required beyond what is normally needed to build GCC.
Generates files in the source directory that are not version-controlled but should go into a release tarball.
Copies the info-formatted and manpage documentation into the source directory usually for the purpose of generating a release tarball.
Deletes installed files, though this is not supported.
Run the testsuite. This creates a testsuite subdirectory that has various .sum and .log files containing the results of the testing. You can run subsets with, for example, ‘ make check-gcc ’. You can specify specific tests by setting RUNTESTFLAGS to be the name of the .exp file, optionally followed by (for some tests) an equals and a file wildcard, like:
make check-gcc RUNTESTFLAGS="execute.exp=19980413-*"
Note that running the testsuite may require additional tools be installed, such as Tcl or DejaGnu.
The toplevel tree from which you start GCC compilation is not the GCC directory, but rather a complex Makefile that coordinates the various steps of the build, including bootstrapping the compiler and using the new compiler to build target libraries.
When GCC is configured for a native configuration, the default action for make is to do a full three-stage bootstrap. This means that GCC is built three times—once with the native compiler, once with the native-built compiler it just built, and once with the compiler it built the second time. In theory, the last two should produce the same results, which ‘ make compare ’ can check. Each stage is configured separately and compiled into a separate directory, to minimize problems due to ABI incompatibilities between the native compiler and GCC.
If you do a change, rebuilding will also start from the first stage and “bubble” up the change through the three stages. Each stage is taken from its build directory (if it had been built previously), rebuilt, and copied to its subdirectory. This will allow you to, for example, continue a bootstrap after fixing a bug which causes the stage2 build to crash. It does not provide as good coverage of the compiler as bootstrapping from scratch, but it ensures that the new code is syntactically correct (e.g., that you did not use GCC extensions by mistake), and avoids spurious bootstrap comparison failures 1 .
Other targets available from the top level include:
Like bootstrap , except that the various stages are removed once they’re no longer needed. This saves disk space.
Performs only the first two stages of bootstrap. Unlike a three-stage bootstrap, this does not perform a comparison to test that the compiler is running properly. Note that the disk space required by a “lean” bootstrap is approximately independent of the number of stages.
stage N -bubble ( N = 1…4, profile, feedback)
Rebuild all the stages up to N , with the appropriate flags, “bubbling” the changes as described above.
all-stage N ( N = 1…4, profile, feedback)
Assuming that stage N has already been built, rebuild it with the appropriate flags. This is rarely needed.
Remove everything (‘ make clean ’) and rebuilds (‘ make bootstrap ’).
Compares the results of stages 2 and 3. This ensures that the compiler is running properly, since it should produce the same object files regardless of how it itself was compiled.
distclean-stage N ( N = 1…4, profile, feedback)
Wipe stage N and all the following ones.
For example, ‘ make distclean-stage3 ’ wipes stage 3 and all the following ones, so that another make then rebuilds them from scratch. This can be useful if you’re doing changes where “bubbling” the changes as described above is not sufficient, but a full make restrap isn’t necessary either.
Builds a compiler with profiling feedback information. In this case, the second and third stages are named ‘ profile ’ and ‘ feedback ’, respectively. For more information, see the installation instructions.
Restart a bootstrap, so that everything that was not built with the system compiler is rebuilt.
stage N -start ( N = 1…4, profile, feedback)
For each package that is bootstrapped, rename directories so that, for example, gcc points to the stage N GCC, compiled with the stage N-1 GCC 2 .
You will invoke this target if you need to test or debug the stage N GCC. If you only need to execute GCC (but you need not run ‘ make ’ either to rebuild it or to run test suites), you should be able to work directly in the stage N -gcc directory. This makes it easier to debug multiple stages in parallel.
For each package that is bootstrapped, relocate its build directory to indicate its stage. For example, if the gcc directory points to the stage2 GCC, after invoking this target it will be renamed to stage2-gcc .
If you wish to use non-default GCC flags when compiling the stage2 and stage3 compilers, set BOOT_CFLAGS on the command line when doing ‘ make ’.
Usually, the first stage only builds the languages that the compiler is written in: typically, C and maybe Ada. If you are debugging a miscompilation of a different stage2 front-end (for example, of the Fortran front-end), you may want to have front-ends for other languages in the first stage as well. To do so, set STAGE1_LANGUAGES on the command line when doing ‘ make ’.
For example, in the aforementioned scenario of debugging a Fortran front-end miscompilation caused by the stage1 compiler, you may need a command like
make stage2-bubble STAGE1_LANGUAGES=c,fortran
Alternatively, you can use per-language targets to build and test languages that are not enabled by default in stage1. For example, make f951 will build a Fortran compiler even in the stage1 build directory.
Footnotes
(1)
Except if the compiler was buggy and miscompiled some of the files that were not modified. In this case, it’s best to use make restrap .
(2)
Customarily, the system compiler is also termed the stage0 GCC.
How do I make a simple makefile for gcc on Linux?
I have three files: program.c , program.h and headers.h . program.c includes program.h and headers.h . I need to compile this on Linux using gcc compiler. I’m not sure how to do this. Netbeans created one for me, but it’s empty.
There is an extremely elegant (and well documented) solution at spin.atomicobject.com/2016/08/26/makefile-c-projects.
5 Answers 5
Interesting, I didn’t know make would default to using the C compiler given rules regarding source files.
Anyway, a simple solution that demonstrates simple Makefile concepts would be:
HEADERS = program.h headers.h default: program program.o: program.c $(HEADERS) gcc -c program.c -o program.o program: program.o gcc program.o -o program clean: -rm -f program.o -rm -f program (bear in mind that make requires tab instead of space indentation, so be sure to fix that when copying)
However, to support more C files, you’d have to make new rules for each of them. Thus, to improve:
HEADERS = program.h headers.h OBJECTS = program.o default: program %.o: %.c $(HEADERS) gcc -c $< -o $@ program: $(OBJECTS) gcc $(OBJECTS) -o $@ clean: -rm -f $(OBJECTS) -rm -f program I tried to make this as simple as possible by omitting variables like $(CC) and $(CFLAGS) that are usually seen in makefiles. If you're interested in figuring that out, I hope I've given you a good start on that.
Here's the Makefile I like to use for C source. Feel free to use it:
TARGET = prog LIBS = -lm CC = gcc CFLAGS = -g -Wall .PHONY: default all clean default: $(TARGET) all: default OBJECTS = $(patsubst %.c, %.o, $(wildcard *.c)) HEADERS = $(wildcard *.h) %.o: %.c $(HEADERS) $(CC) $(CFLAGS) -c $< -o $@ .PRECIOUS: $(TARGET) $(OBJECTS) $(TARGET): $(OBJECTS) $(CC) $(OBJECTS) -Wall $(LIBS) -o $@ clean: -rm -f *.o -rm -f $(TARGET) It uses the wildcard and patsubst features of the make utility to automatically include .c and .h files in the current directory, meaning when you add new code files to your directory, you won't have to update the Makefile. However, if you want to change the name of the generated executable, libraries, or compiler flags, you can just modify the variables.
In either case, don't use autoconf, please. I'm begging you! 🙂