5 This document describes the Linux kernel Makefiles.
11 === 3 The kbuild files
12 --- 3.1 Goal definitions
13 --- 3.2 Built-in object goals - obj-y
14 --- 3.3 Loadable module goals - obj-m
16 --- 3.5 Library file goals - lib-y
17 --- 3.6 Descending down in directories
18 --- 3.7 Non-builtin vmlinux targets - extra-y
19 --- 3.8 Always built goals - always-y
20 --- 3.9 Compilation flags
21 --- 3.10 Dependency tracking
23 --- 3.12 Command change detection
24 --- 3.13 $(CC) support functions
25 --- 3.14 $(LD) support functions
26 --- 3.15 Script Invocation
28 === 4 Host Program support
29 --- 4.1 Simple Host Program
30 --- 4.2 Composite Host Programs
31 --- 4.3 Using C++ for host programs
32 --- 4.4 Using Rust for host programs
33 --- 4.5 Controlling compiler options for host programs
34 --- 4.6 When host programs are actually built
36 === 5 Userspace Program support
37 --- 5.1 Simple Userspace Program
38 --- 5.2 Composite Userspace Programs
39 --- 5.3 Controlling compiler options for userspace programs
40 --- 5.4 When userspace programs are actually built
42 === 6 Kbuild clean infrastructure
44 === 7 Architecture Makefiles
45 --- 7.1 Set variables to tweak the build to the architecture
46 --- 7.2 Add prerequisites to archheaders
47 --- 7.3 Add prerequisites to archprepare
48 --- 7.4 List directories to visit when descending
49 --- 7.5 Architecture-specific boot images
50 --- 7.6 Building non-kbuild targets
51 --- 7.7 Commands useful for building a boot image
53 --- 7.9 Preprocessing linker scripts
54 --- 7.10 Generic header files
55 --- 7.11 Post-link pass
57 === 8 Kbuild syntax for exported headers
58 --- 8.1 no-export-headers
63 === 9 Kbuild Variables
64 === 10 Makefile language
71 The Makefiles have five parts::
73 Makefile the top Makefile.
74 .config the kernel configuration file.
75 arch/$(SRCARCH)/Makefile the arch Makefile.
76 scripts/Makefile.* common rules etc. for all kbuild Makefiles.
77 kbuild Makefiles exist in every subdirectory
79 The top Makefile reads the .config file, which comes from the kernel
80 configuration process.
82 The top Makefile is responsible for building two major products: vmlinux
83 (the resident kernel image) and modules (any module files).
84 It builds these goals by recursively descending into the subdirectories of
85 the kernel source tree.
86 The list of subdirectories which are visited depends upon the kernel
87 configuration. The top Makefile textually includes an arch Makefile
88 with the name arch/$(SRCARCH)/Makefile. The arch Makefile supplies
89 architecture-specific information to the top Makefile.
91 Each subdirectory has a kbuild Makefile which carries out the commands
92 passed down from above. The kbuild Makefile uses information from the
93 .config file to construct various file lists used by kbuild to build
94 any built-in or modular targets.
96 scripts/Makefile.* contains all the definitions/rules etc. that
97 are used to build the kernel based on the kbuild makefiles.
103 People have four different relationships with the kernel Makefiles.
105 *Users* are people who build kernels. These people type commands such as
106 "make menuconfig" or "make". They usually do not read or edit
107 any kernel Makefiles (or any other source files).
109 *Normal developers* are people who work on features such as device
110 drivers, file systems, and network protocols. These people need to
111 maintain the kbuild Makefiles for the subsystem they are
112 working on. In order to do this effectively, they need some overall
113 knowledge about the kernel Makefiles, plus detailed knowledge about the
114 public interface for kbuild.
116 *Arch developers* are people who work on an entire architecture, such
117 as sparc or ia64. Arch developers need to know about the arch Makefile
118 as well as kbuild Makefiles.
120 *Kbuild developers* are people who work on the kernel build system itself.
121 These people need to know about all aspects of the kernel Makefiles.
123 This document is aimed towards normal developers and arch developers.
129 Most Makefiles within the kernel are kbuild Makefiles that use the
130 kbuild infrastructure. This chapter introduces the syntax used in the
132 The preferred name for the kbuild files are 'Makefile' but 'Kbuild' can
133 be used and if both a 'Makefile' and a 'Kbuild' file exists, then the 'Kbuild'
136 Section 3.1 "Goal definitions" is a quick intro; further chapters provide
137 more details, with real examples.
142 Goal definitions are the main part (heart) of the kbuild Makefile.
143 These lines define the files to be built, any special compilation
144 options, and any subdirectories to be entered recursively.
146 The most simple kbuild makefile contains one line:
152 This tells kbuild that there is one object in that directory, named
153 foo.o. foo.o will be built from foo.c or foo.S.
155 If foo.o shall be built as a module, the variable obj-m is used.
156 Therefore the following pattern is often used:
160 obj-$(CONFIG_FOO) += foo.o
162 $(CONFIG_FOO) evaluates to either y (for built-in) or m (for module).
163 If CONFIG_FOO is neither y nor m, then the file will not be compiled
166 3.2 Built-in object goals - obj-y
167 ---------------------------------
169 The kbuild Makefile specifies object files for vmlinux
170 in the $(obj-y) lists. These lists depend on the kernel
173 Kbuild compiles all the $(obj-y) files. It then calls
174 "$(AR) rcSTP" to merge these files into one built-in.a file.
175 This is a thin archive without a symbol table. It will be later
176 linked into vmlinux by scripts/link-vmlinux.sh
178 The order of files in $(obj-y) is significant. Duplicates in
179 the lists are allowed: the first instance will be linked into
180 built-in.a and succeeding instances will be ignored.
182 Link order is significant, because certain functions
183 (module_init() / __initcall) will be called during boot in the
184 order they appear. So keep in mind that changing the link
185 order may e.g. change the order in which your SCSI
186 controllers are detected, and thus your disks are renumbered.
190 #drivers/isdn/i4l/Makefile
191 # Makefile for the kernel ISDN subsystem and device drivers.
192 # Each configuration option enables a list of files.
193 obj-$(CONFIG_ISDN_I4L) += isdn.o
194 obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
196 3.3 Loadable module goals - obj-m
197 ---------------------------------
199 $(obj-m) specifies object files which are built as loadable
202 A module may be built from one source file or several source
203 files. In the case of one source file, the kbuild makefile
204 simply adds the file to $(obj-m).
208 #drivers/isdn/i4l/Makefile
209 obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
211 Note: In this example $(CONFIG_ISDN_PPP_BSDCOMP) evaluates to 'm'
213 If a kernel module is built from several source files, you specify
214 that you want to build a module in the same way as above; however,
215 kbuild needs to know which object files you want to build your
216 module from, so you have to tell it by setting a $(<module_name>-y)
221 #drivers/isdn/i4l/Makefile
222 obj-$(CONFIG_ISDN_I4L) += isdn.o
223 isdn-y := isdn_net_lib.o isdn_v110.o isdn_common.o
225 In this example, the module name will be isdn.o. Kbuild will
226 compile the objects listed in $(isdn-y) and then run
227 "$(LD) -r" on the list of these files to generate isdn.o.
229 Due to kbuild recognizing $(<module_name>-y) for composite objects,
230 you can use the value of a `CONFIG_` symbol to optionally include an
231 object file as part of a composite object.
236 obj-$(CONFIG_EXT2_FS) += ext2.o
237 ext2-y := balloc.o dir.o file.o ialloc.o inode.o ioctl.o \
238 namei.o super.o symlink.o
239 ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o xattr_user.o \
242 In this example, xattr.o, xattr_user.o and xattr_trusted.o are only
243 part of the composite object ext2.o if $(CONFIG_EXT2_FS_XATTR)
246 Note: Of course, when you are building objects into the kernel,
247 the syntax above will also work. So, if you have CONFIG_EXT2_FS=y,
248 kbuild will build an ext2.o file for you out of the individual
249 parts and then link this into built-in.a, as you would expect.
251 3.5 Library file goals - lib-y
252 ------------------------------
254 Objects listed with obj-* are used for modules, or
255 combined in a built-in.a for that specific directory.
256 There is also the possibility to list objects that will
257 be included in a library, lib.a.
258 All objects listed with lib-y are combined in a single
259 library for that directory.
260 Objects that are listed in obj-y and additionally listed in
261 lib-y will not be included in the library, since they will
262 be accessible anyway.
263 For consistency, objects listed in lib-m will be included in lib.a.
265 Note that the same kbuild makefile may list files to be built-in
266 and to be part of a library. Therefore the same directory
267 may contain both a built-in.a and a lib.a file.
271 #arch/x86/lib/Makefile
274 This will create a library lib.a based on delay.o. For kbuild to
275 actually recognize that there is a lib.a being built, the directory
276 shall be listed in libs-y.
278 See also "7.4 List directories to visit when descending".
280 Use of lib-y is normally restricted to `lib/` and `arch/*/lib`.
282 3.6 Descending down in directories
283 ----------------------------------
285 A Makefile is only responsible for building objects in its own
286 directory. Files in subdirectories should be taken care of by
287 Makefiles in these subdirs. The build system will automatically
288 invoke make recursively in subdirectories, provided you let it know of
291 To do so, obj-y and obj-m are used.
292 ext2 lives in a separate directory, and the Makefile present in fs/
293 tells kbuild to descend down using the following assignment.
298 obj-$(CONFIG_EXT2_FS) += ext2/
300 If CONFIG_EXT2_FS is set to either 'y' (built-in) or 'm' (modular)
301 the corresponding obj- variable will be set, and kbuild will descend
302 down in the ext2 directory.
304 Kbuild uses this information not only to decide that it needs to visit
305 the directory, but also to decide whether or not to link objects from
306 the directory into vmlinux.
308 When Kbuild descends into the directory with 'y', all built-in objects
309 from that directory are combined into the built-in.a, which will be
310 eventually linked into vmlinux.
312 When Kbuild descends into the directory with 'm', in contrast, nothing
313 from that directory will be linked into vmlinux. If the Makefile in
314 that directory specifies obj-y, those objects will be left orphan.
315 It is very likely a bug of the Makefile or of dependencies in Kconfig.
317 Kbuild also supports dedicated syntax, subdir-y and subdir-m, for
318 descending into subdirectories. It is a good fit when you know they
319 do not contain kernel-space objects at all. A typical usage is to let
320 Kbuild descend into subdirectories to build tools.
325 subdir-$(CONFIG_GCC_PLUGINS) += gcc-plugins
326 subdir-$(CONFIG_MODVERSIONS) += genksyms
327 subdir-$(CONFIG_SECURITY_SELINUX) += selinux
329 Unlike obj-y/m, subdir-y/m does not need the trailing slash since this
330 syntax is always used for directories.
332 It is good practice to use a `CONFIG_` variable when assigning directory
333 names. This allows kbuild to totally skip the directory if the
334 corresponding `CONFIG_` option is neither 'y' nor 'm'.
336 3.7 Non-builtin vmlinux targets - extra-y
337 -----------------------------------------
339 extra-y specifies targets which are needed for building vmlinux,
340 but not combined into built-in.a.
346 Some objects must be placed at the head of vmlinux. They are
347 directly linked to vmlinux without going through built-in.a
348 A typical use-case is an object that contains the entry point.
350 arch/$(SRCARCH)/Makefile should specify such objects as head-y.
353 Given that we can control the section order in the linker script,
354 why do we need head-y?
356 2) vmlinux linker script
358 The linker script for vmlinux is located at
359 arch/$(SRCARCH)/kernel/vmlinux.lds
363 # arch/x86/kernel/Makefile
364 extra-y := head_$(BITS).o
365 extra-y += head$(BITS).o
367 extra-y += platform-quirks.o
368 extra-y += vmlinux.lds
370 $(extra-y) should only contain targets needed for vmlinux.
372 Kbuild skips extra-y when vmlinux is apparently not a final goal.
373 (e.g. 'make modules', or building external modules)
375 If you intend to build targets unconditionally, always-y (explained
376 in the next section) is the correct syntax to use.
378 3.8 Always built goals - always-y
379 ---------------------------------
381 always-y specifies targets which are literally always built when
382 Kbuild visits the Makefile.
386 offsets-file := include/generated/asm-offsets.h
387 always-y += $(offsets-file)
389 3.9 Compilation flags
390 ---------------------
392 ccflags-y, asflags-y and ldflags-y
393 These three flags apply only to the kbuild makefile in which they
394 are assigned. They are used for all the normal cc, as and ld
395 invocations happening during a recursive build.
396 Note: Flags with the same behaviour were previously named:
397 EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS.
398 They are still supported but their usage is deprecated.
400 ccflags-y specifies options for compiling with $(CC).
404 # drivers/acpi/acpica/Makefile
405 ccflags-y := -Os -D_LINUX -DBUILDING_ACPICA
406 ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT
408 This variable is necessary because the top Makefile owns the
409 variable $(KBUILD_CFLAGS) and uses it for compilation flags for the
412 asflags-y specifies assembler options.
416 #arch/sparc/kernel/Makefile
419 ldflags-y specifies options for linking with $(LD).
423 #arch/cris/boot/compressed/Makefile
424 ldflags-y += -T $(srctree)/$(src)/decompress_$(arch-y).lds
426 subdir-ccflags-y, subdir-asflags-y
427 The two flags listed above are similar to ccflags-y and asflags-y.
428 The difference is that the subdir- variants have effect for the kbuild
429 file where they are present and all subdirectories.
430 Options specified using subdir-* are added to the commandline before
431 the options specified using the non-subdir variants.
435 subdir-ccflags-y := -Werror
437 ccflags-remove-y, asflags-remove-y
438 These flags are used to remove particular flags for the compiler,
439 assembler invocations.
443 ccflags-remove-$(CONFIG_MCOUNT) += -pg
446 CFLAGS_$@ and AFLAGS_$@ only apply to commands in current
449 $(CFLAGS_$@) specifies per-file options for $(CC). The $@
450 part has a literal value which specifies the file that it is for.
452 CFLAGS_$@ has the higher priority than ccflags-remove-y; CFLAGS_$@
453 can re-add compiler flags that were removed by ccflags-remove-y.
457 # drivers/scsi/Makefile
458 CFLAGS_aha152x.o = -DAHA152X_STAT -DAUTOCONF
460 This line specify compilation flags for aha152x.o.
462 $(AFLAGS_$@) is a similar feature for source files in assembly
465 AFLAGS_$@ has the higher priority than asflags-remove-y; AFLAGS_$@
466 can re-add assembler flags that were removed by asflags-remove-y.
470 # arch/arm/kernel/Makefile
471 AFLAGS_head.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
472 AFLAGS_crunch-bits.o := -Wa,-mcpu=ep9312
473 AFLAGS_iwmmxt.o := -Wa,-mcpu=iwmmxt
476 3.10 Dependency tracking
477 ------------------------
479 Kbuild tracks dependencies on the following:
481 1) All prerequisite files (both `*.c` and `*.h`)
482 2) `CONFIG_` options used in all prerequisite files
483 3) Command-line used to compile target
485 Thus, if you change an option to $(CC) all affected files will
491 Custom rules are used when the kbuild infrastructure does
492 not provide the required support. A typical example is
493 header files generated during the build process.
494 Another example are the architecture-specific Makefiles which
495 need custom rules to prepare boot images etc.
497 Custom rules are written as normal Make rules.
498 Kbuild is not executing in the directory where the Makefile is
499 located, so all custom rules shall use a relative
500 path to prerequisite files and target files.
502 Two variables are used when defining custom rules:
505 $(src) is a relative path which points to the directory
506 where the Makefile is located. Always use $(src) when
507 referring to files located in the src tree.
510 $(obj) is a relative path which points to the directory
511 where the target is saved. Always use $(obj) when
512 referring to generated files.
516 #drivers/scsi/Makefile
517 $(obj)/53c8xx_d.h: $(src)/53c7,8xx.scr $(src)/script_asm.pl
518 $(CPP) -DCHIP=810 - < $< | ... $(src)/script_asm.pl
520 This is a custom rule, following the normal syntax
523 The target file depends on two prerequisite files. References
524 to the target file are prefixed with $(obj), references
525 to prerequisites are referenced with $(src) (because they are not
529 echoing information to user in a rule is often a good practice
530 but when execution "make -s" one does not expect to see any output
531 except for warnings/errors.
532 To support this kbuild defines $(kecho) which will echo out the
533 text following $(kecho) to stdout except if "make -s" is used.
538 $(BOOT_TARGETS): vmlinux
539 $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@
540 @$(kecho) ' Kernel: $(boot)/$@ is ready'
542 When kbuild is executing with KBUILD_VERBOSE=0, then only a shorthand
543 of a command is normally displayed.
544 To enable this behaviour for custom commands kbuild requires
545 two variables to be set::
547 quiet_cmd_<command> - what shall be echoed
548 cmd_<command> - the command to execute
553 quiet_cmd_crc32 = GEN $@
556 $(obj)/crc32table.h: $(obj)/gen_crc32table
559 When updating the $(obj)/crc32table.h target, the line:
563 will be displayed with "make KBUILD_VERBOSE=0".
565 3.12 Command change detection
566 -----------------------------
568 When the rule is evaluated, timestamps are compared between the target
569 and its prerequisite files. GNU Make updates the target when any of the
570 prerequisites is newer than that.
572 The target should be rebuilt also when the command line has changed
573 since the last invocation. This is not supported by Make itself, so
574 Kbuild achieves this by a kind of meta-programming.
576 if_changed is the macro used for this purpose, in the following form::
578 quiet_cmd_<command> = ...
581 <target>: <source(s)> FORCE
582 $(call if_changed,<command>)
584 Any target that utilizes if_changed must be listed in $(targets),
585 otherwise the command line check will fail, and the target will
588 If the target is already listed in the recognized syntax such as
589 obj-y/m, lib-y/m, extra-y/m, always-y/m, hostprogs, userprogs, Kbuild
590 automatically adds it to $(targets). Otherwise, the target must be
591 explicitly added to $(targets).
593 Assignments to $(targets) are without $(obj)/ prefix. if_changed may be
594 used in conjunction with custom rules as defined in "3.11 Custom Rules".
596 Note: It is a typical mistake to forget the FORCE prerequisite.
597 Another common pitfall is that whitespace is sometimes significant; for
598 instance, the below will fail (note the extra space after the comma)::
600 target: source(s) FORCE
602 **WRONG!** $(call if_changed, objcopy)
605 if_changed should not be used more than once per target.
606 It stores the executed command in a corresponding .cmd
607 file and multiple calls would result in overwrites and
608 unwanted results when the target is up to date and only the
609 tests on changed commands trigger execution of commands.
611 3.13 $(CC) support functions
612 ----------------------------
614 The kernel may be built with several different versions of
615 $(CC), each supporting a unique set of features and options.
616 kbuild provides basic support to check for valid options for $(CC).
617 $(CC) is usually the gcc compiler, but other alternatives are
621 as-option is used to check if $(CC) -- when used to compile
622 assembler (`*.S`) files -- supports the given option. An optional
623 second option may be specified if the first option is not supported.
628 cflags-y += $(call as-option,-Wa$(comma)-isa=$(isa-y),)
630 In the above example, cflags-y will be assigned the option
631 -Wa$(comma)-isa=$(isa-y) if it is supported by $(CC).
632 The second argument is optional, and if supplied will be used
633 if first argument is not supported.
636 as-instr checks if the assembler reports a specific instruction
637 and then outputs either option1 or option2
638 C escapes are supported in the test instruction
639 Note: as-instr-option uses KBUILD_AFLAGS for assembler options
642 cc-option is used to check if $(CC) supports a given option, and if
643 not supported to use an optional second option.
648 cflags-y += $(call cc-option,-march=pentium-mmx,-march=i586)
650 In the above example, cflags-y will be assigned the option
651 -march=pentium-mmx if supported by $(CC), otherwise -march=i586.
652 The second argument to cc-option is optional, and if omitted,
653 cflags-y will be assigned no value if first option is not supported.
654 Note: cc-option uses KBUILD_CFLAGS for $(CC) options
657 cc-option-yn is used to check if gcc supports a given option
658 and return 'y' if supported, otherwise 'n'.
663 biarch := $(call cc-option-yn, -m32)
664 aflags-$(biarch) += -a32
665 cflags-$(biarch) += -m32
667 In the above example, $(biarch) is set to y if $(CC) supports the -m32
668 option. When $(biarch) equals 'y', the expanded variables $(aflags-y)
669 and $(cflags-y) will be assigned the values -a32 and -m32,
671 Note: cc-option-yn uses KBUILD_CFLAGS for $(CC) options
674 cc-disable-warning checks if gcc supports a given warning and returns
675 the commandline switch to disable it. This special function is needed,
676 because gcc 4.4 and later accept any unknown -Wno-* option and only
677 warn about it if there is another warning in the source file.
681 KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable)
683 In the above example, -Wno-unused-but-set-variable will be added to
684 KBUILD_CFLAGS only if gcc really accepts it.
687 cc-ifversion tests the version of $(CC) and equals the fourth parameter
688 if version expression is true, or the fifth (if given) if the version
693 #fs/reiserfs/Makefile
694 ccflags-y := $(call cc-ifversion, -lt, 0402, -O1)
696 In this example, ccflags-y will be assigned the value -O1 if the
697 $(CC) version is less than 4.2.
698 cc-ifversion takes all the shell operators:
699 -eq, -ne, -lt, -le, -gt, and -ge
700 The third parameter may be a text as in this example, but it may also
701 be an expanded variable or a macro.
704 cc-cross-prefix is used to check if there exists a $(CC) in path with
705 one of the listed prefixes. The first prefix where there exist a
706 prefix$(CC) in the PATH is returned - and if no prefix$(CC) is found
707 then nothing is returned.
708 Additional prefixes are separated by a single space in the
709 call of cc-cross-prefix.
710 This functionality is useful for architecture Makefiles that try
711 to set CROSS_COMPILE to well-known values but may have several
712 values to select between.
713 It is recommended only to try to set CROSS_COMPILE if it is a cross
714 build (host arch is different from target arch). And if CROSS_COMPILE
715 is already set then leave it with the old value.
720 ifneq ($(SUBARCH),$(ARCH))
721 ifeq ($(CROSS_COMPILE),)
722 CROSS_COMPILE := $(call cc-cross-prefix, m68k-linux-gnu-)
726 3.14 $(LD) support functions
727 ----------------------------
730 ld-option is used to check if $(LD) supports the supplied option.
731 ld-option takes two options as arguments.
732 The second argument is an optional option that can be used if the
733 first option is not supported by $(LD).
738 LDFLAGS_vmlinux += $(call ld-option, -X)
740 3.15 Script invocation
741 ----------------------
743 Make rules may invoke scripts to build the kernel. The rules shall
744 always provide the appropriate interpreter to execute the script. They
745 shall not rely on the execute bits being set, and shall not invoke the
746 script directly. For the convenience of manual script invocation, such
747 as invoking ./scripts/checkpatch.pl, it is recommended to set execute
748 bits on the scripts nonetheless.
750 Kbuild provides variables $(CONFIG_SHELL), $(AWK), $(PERL),
751 and $(PYTHON3) to refer to interpreters for the respective
757 cmd_depmod = $(CONFIG_SHELL) $(srctree)/scripts/depmod.sh $(DEPMOD) \
760 4 Host Program support
761 ======================
763 Kbuild supports building executables on the host for use during the
765 Two steps are required in order to use a host executable.
767 The first step is to tell kbuild that a host program exists. This is
768 done utilising the variable "hostprogs".
770 The second step is to add an explicit dependency to the executable.
771 This can be done in two ways. Either add the dependency in a rule,
772 or utilise the variable "always-y".
773 Both possibilities are described in the following.
775 4.1 Simple Host Program
776 -----------------------
778 In some cases there is a need to compile and run a program on the
779 computer where the build is running.
780 The following line tells kbuild that the program bin2hex shall be
781 built on the build host.
787 Kbuild assumes in the above example that bin2hex is made from a single
788 c-source file named bin2hex.c located in the same directory as
791 4.2 Composite Host Programs
792 ---------------------------
794 Host programs can be made up based on composite objects.
795 The syntax used to define composite objects for host programs is
796 similar to the syntax used for kernel objects.
797 $(<executable>-objs) lists all objects used to link the final
802 #scripts/lxdialog/Makefile
803 hostprogs := lxdialog
804 lxdialog-objs := checklist.o lxdialog.o
806 Objects with extension .o are compiled from the corresponding .c
807 files. In the above example, checklist.c is compiled to checklist.o
808 and lxdialog.c is compiled to lxdialog.o.
810 Finally, the two .o files are linked to the executable, lxdialog.
811 Note: The syntax <executable>-y is not permitted for host-programs.
813 4.3 Using C++ for host programs
814 -------------------------------
816 kbuild offers support for host programs written in C++. This was
817 introduced solely to support kconfig, and is not recommended
822 #scripts/kconfig/Makefile
824 qconf-cxxobjs := qconf.o
826 In the example above the executable is composed of the C++ file
827 qconf.cc - identified by $(qconf-cxxobjs).
829 If qconf is composed of a mixture of .c and .cc files, then an
830 additional line can be used to identify this.
834 #scripts/kconfig/Makefile
836 qconf-cxxobjs := qconf.o
837 qconf-objs := check.o
839 4.4 Using Rust for host programs
840 --------------------------------
842 Kbuild offers support for host programs written in Rust. However,
843 since a Rust toolchain is not mandatory for kernel compilation,
844 it may only be used in scenarios where Rust is required to be
845 available (e.g. when ``CONFIG_RUST`` is enabled).
852 Kbuild will compile ``target`` using ``target.rs`` as the crate root,
853 located in the same directory as the ``Makefile``. The crate may
854 consist of several source files (see ``samples/rust/hostprogs``).
856 4.5 Controlling compiler options for host programs
857 --------------------------------------------------
859 When compiling host programs, it is possible to set specific flags.
860 The programs will always be compiled utilising $(HOSTCC) passed
861 the options specified in $(KBUILD_HOSTCFLAGS).
862 To set flags that will take effect for all host programs created
863 in that Makefile, use the variable HOST_EXTRACFLAGS.
867 #scripts/lxdialog/Makefile
868 HOST_EXTRACFLAGS += -I/usr/include/ncurses
870 To set specific flags for a single file the following construction
875 #arch/ppc64/boot/Makefile
876 HOSTCFLAGS_piggyback.o := -DKERNELBASE=$(KERNELBASE)
878 It is also possible to specify additional options to the linker.
882 #scripts/kconfig/Makefile
883 HOSTLDLIBS_qconf := -L$(QTDIR)/lib
885 When linking qconf, it will be passed the extra option
888 4.6 When host programs are actually built
889 -----------------------------------------
891 Kbuild will only build host-programs when they are referenced
893 This is possible in two ways:
895 (1) List the prerequisite explicitly in a custom rule.
899 #drivers/pci/Makefile
900 hostprogs := gen-devlist
901 $(obj)/devlist.h: $(src)/pci.ids $(obj)/gen-devlist
902 ( cd $(obj); ./gen-devlist ) < $<
904 The target $(obj)/devlist.h will not be built before
905 $(obj)/gen-devlist is updated. Note that references to
906 the host programs in custom rules must be prefixed with $(obj).
910 When there is no suitable custom rule, and the host program
911 shall be built when a makefile is entered, the always-y
912 variable shall be used.
916 #scripts/lxdialog/Makefile
917 hostprogs := lxdialog
918 always-y := $(hostprogs)
920 Kbuild provides the following shorthand for this:
922 hostprogs-always-y := lxdialog
924 This will tell kbuild to build lxdialog even if not referenced in
927 5 Userspace Program support
928 ===========================
930 Just like host programs, Kbuild also supports building userspace executables
931 for the target architecture (i.e. the same architecture as you are building
934 The syntax is quite similar. The difference is to use "userprogs" instead of
937 5.1 Simple Userspace Program
938 ----------------------------
940 The following line tells kbuild that the program bpf-direct shall be
941 built for the target architecture.
945 userprogs := bpf-direct
947 Kbuild assumes in the above example that bpf-direct is made from a
948 single C source file named bpf-direct.c located in the same directory
951 5.2 Composite Userspace Programs
952 --------------------------------
954 Userspace programs can be made up based on composite objects.
955 The syntax used to define composite objects for userspace programs is
956 similar to the syntax used for kernel objects.
957 $(<executable>-objs) lists all objects used to link the final
962 #samples/seccomp/Makefile
963 userprogs := bpf-fancy
964 bpf-fancy-objs := bpf-fancy.o bpf-helper.o
966 Objects with extension .o are compiled from the corresponding .c
967 files. In the above example, bpf-fancy.c is compiled to bpf-fancy.o
968 and bpf-helper.c is compiled to bpf-helper.o.
970 Finally, the two .o files are linked to the executable, bpf-fancy.
971 Note: The syntax <executable>-y is not permitted for userspace programs.
973 5.3 Controlling compiler options for userspace programs
974 -------------------------------------------------------
976 When compiling userspace programs, it is possible to set specific flags.
977 The programs will always be compiled utilising $(CC) passed
978 the options specified in $(KBUILD_USERCFLAGS).
979 To set flags that will take effect for all userspace programs created
980 in that Makefile, use the variable userccflags.
984 # samples/seccomp/Makefile
985 userccflags += -I usr/include
987 To set specific flags for a single file the following construction
992 bpf-helper-userccflags += -I user/include
994 It is also possible to specify additional options to the linker.
998 # net/bpfilter/Makefile
999 bpfilter_umh-userldflags += -static
1001 When linking bpfilter_umh, it will be passed the extra option -static.
1003 From command line, :ref:`USERCFLAGS and USERLDFLAGS <userkbuildflags>` will also be used.
1005 5.4 When userspace programs are actually built
1006 ----------------------------------------------
1008 Kbuild builds userspace programs only when told to do so.
1009 There are two ways to do this.
1011 (1) Add it as the prerequisite of another file
1015 #net/bpfilter/Makefile
1016 userprogs := bpfilter_umh
1017 $(obj)/bpfilter_umh_blob.o: $(obj)/bpfilter_umh
1019 $(obj)/bpfilter_umh is built before $(obj)/bpfilter_umh_blob.o
1025 userprogs := binderfs_example
1026 always-y := $(userprogs)
1028 Kbuild provides the following shorthand for this:
1030 userprogs-always-y := binderfs_example
1032 This will tell Kbuild to build binderfs_example when it visits this
1035 6 Kbuild clean infrastructure
1036 =============================
1038 "make clean" deletes most generated files in the obj tree where the kernel
1039 is compiled. This includes generated files such as host programs.
1040 Kbuild knows targets listed in $(hostprogs), $(always-y), $(always-m),
1041 $(always-), $(extra-y), $(extra-) and $(targets). They are all deleted
1042 during "make clean". Files matching the patterns "*.[oas]", "*.ko", plus
1043 some additional files generated by kbuild are deleted all over the kernel
1044 source tree when "make clean" is executed.
1046 Additional files or directories can be specified in kbuild makefiles by use of
1052 clean-files := crc32table.h
1054 When executing "make clean", the file "crc32table.h" will be deleted.
1055 Kbuild will assume files to be in the same relative directory as the
1056 Makefile, except if prefixed with $(objtree).
1058 To exclude certain files or directories from make clean, use the
1059 $(no-clean-files) variable.
1061 Usually kbuild descends down in subdirectories due to "obj-* := dir/",
1062 but in the architecture makefiles where the kbuild infrastructure
1063 is not sufficient this sometimes needs to be explicit.
1067 #arch/x86/boot/Makefile
1068 subdir- := compressed
1070 The above assignment instructs kbuild to descend down in the
1071 directory compressed/ when "make clean" is executed.
1073 Note 1: arch/$(SRCARCH)/Makefile cannot use "subdir-", because that file is
1074 included in the top level makefile. Instead, arch/$(SRCARCH)/Kbuild can use
1077 Note 2: All directories listed in core-y, libs-y, drivers-y and net-y will
1078 be visited during "make clean".
1080 7 Architecture Makefiles
1081 ========================
1083 The top level Makefile sets up the environment and does the preparation,
1084 before starting to descend down in the individual directories.
1085 The top level makefile contains the generic part, whereas
1086 arch/$(SRCARCH)/Makefile contains what is required to set up kbuild
1087 for said architecture.
1088 To do so, arch/$(SRCARCH)/Makefile sets up a number of variables and defines
1091 When kbuild executes, the following steps are followed (roughly):
1093 1) Configuration of the kernel => produce .config
1094 2) Store kernel version in include/linux/version.h
1095 3) Updating all other prerequisites to the target prepare:
1096 - Additional prerequisites are specified in arch/$(SRCARCH)/Makefile
1097 4) Recursively descend down in all directories listed in
1098 init-* core* drivers-* net-* libs-* and build all targets.
1099 - The values of the above variables are expanded in arch/$(SRCARCH)/Makefile.
1100 5) All object files are then linked and the resulting file vmlinux is
1101 located at the root of the obj tree.
1102 The very first objects linked are listed in head-y, assigned by
1103 arch/$(SRCARCH)/Makefile.
1104 6) Finally, the architecture-specific part does any required post processing
1105 and builds the final bootimage.
1106 - This includes building boot records
1107 - Preparing initrd images and the like
1110 7.1 Set variables to tweak the build to the architecture
1111 --------------------------------------------------------
1114 Generic $(LD) options
1116 Flags used for all invocations of the linker.
1117 Often specifying the emulation is sufficient.
1122 KBUILD_LDFLAGS := -m elf_s390
1124 Note: ldflags-y can be used to further customise
1125 the flags used. See section 3.7.
1128 Options for $(LD) when linking vmlinux
1130 LDFLAGS_vmlinux is used to specify additional flags to pass to
1131 the linker when linking the final vmlinux image.
1132 LDFLAGS_vmlinux uses the LDFLAGS_$@ support.
1137 LDFLAGS_vmlinux := -e stext
1142 When $(call if_changed,objcopy) is used to translate a .o file,
1143 the flags specified in OBJCOPYFLAGS will be used.
1144 $(call if_changed,objcopy) is often used to generate raw binaries on
1150 OBJCOPYFLAGS := -O binary
1152 #arch/s390/boot/Makefile
1153 $(obj)/image: vmlinux FORCE
1154 $(call if_changed,objcopy)
1156 In this example, the binary $(obj)/image is a binary version of
1157 vmlinux. The usage of $(call if_changed,xxx) will be described later.
1162 Default value - see top level Makefile
1163 Append or modify as required per architecture.
1167 #arch/sparc64/Makefile
1168 KBUILD_AFLAGS += -m64 -mcpu=ultrasparc
1171 $(CC) compiler flags
1173 Default value - see top level Makefile
1174 Append or modify as required per architecture.
1176 Often, the KBUILD_CFLAGS variable depends on the configuration.
1180 #arch/x86/boot/compressed/Makefile
1181 cflags-$(CONFIG_X86_32) := -march=i386
1182 cflags-$(CONFIG_X86_64) := -mcmodel=small
1183 KBUILD_CFLAGS += $(cflags-y)
1185 Many arch Makefiles dynamically run the target C compiler to
1186 probe supported options::
1191 cflags-$(CONFIG_MPENTIUMII) += $(call cc-option,\
1192 -march=pentium2,-march=i686)
1194 # Disable unit-at-a-time mode ...
1195 KBUILD_CFLAGS += $(call cc-option,-fno-unit-at-a-time)
1199 The first example utilises the trick that a config option expands
1200 to 'y' when selected.
1203 $(RUSTC) compiler flags
1205 Default value - see top level Makefile
1206 Append or modify as required per architecture.
1208 Often, the KBUILD_RUSTFLAGS variable depends on the configuration.
1210 Note that target specification file generation (for ``--target``)
1211 is handled in ``scripts/generate_rust_target.rs``.
1213 KBUILD_AFLAGS_KERNEL
1214 Assembler options specific for built-in
1216 $(KBUILD_AFLAGS_KERNEL) contains extra C compiler flags used to compile
1217 resident kernel code.
1219 KBUILD_AFLAGS_MODULE
1220 Assembler options specific for modules
1222 $(KBUILD_AFLAGS_MODULE) is used to add arch-specific options that
1223 are used for assembler.
1225 From commandline AFLAGS_MODULE shall be used (see kbuild.rst).
1227 KBUILD_CFLAGS_KERNEL
1228 $(CC) options specific for built-in
1230 $(KBUILD_CFLAGS_KERNEL) contains extra C compiler flags used to compile
1231 resident kernel code.
1233 KBUILD_CFLAGS_MODULE
1234 Options for $(CC) when building modules
1236 $(KBUILD_CFLAGS_MODULE) is used to add arch-specific options that
1238 From commandline CFLAGS_MODULE shall be used (see kbuild.rst).
1240 KBUILD_RUSTFLAGS_KERNEL
1241 $(RUSTC) options specific for built-in
1243 $(KBUILD_RUSTFLAGS_KERNEL) contains extra Rust compiler flags used to
1244 compile resident kernel code.
1246 KBUILD_RUSTFLAGS_MODULE
1247 Options for $(RUSTC) when building modules
1249 $(KBUILD_RUSTFLAGS_MODULE) is used to add arch-specific options that
1250 are used for $(RUSTC).
1251 From commandline RUSTFLAGS_MODULE shall be used (see kbuild.rst).
1253 KBUILD_LDFLAGS_MODULE
1254 Options for $(LD) when linking modules
1256 $(KBUILD_LDFLAGS_MODULE) is used to add arch-specific options
1257 used when linking modules. This is often a linker script.
1259 From commandline LDFLAGS_MODULE shall be used (see kbuild.rst).
1263 The linker script with full path. Assigned by the top-level Makefile.
1267 The module linker script with full path. Assigned by the top-level
1268 Makefile and additionally by the arch Makefile.
1272 All object files for vmlinux. They are linked to vmlinux in the same
1273 order as listed in KBUILD_VMLINUX_OBJS.
1277 All .a "lib" files for vmlinux. KBUILD_VMLINUX_OBJS and
1278 KBUILD_VMLINUX_LIBS together specify all the object files used to
1281 7.2 Add prerequisites to archheaders
1282 ------------------------------------
1284 The archheaders: rule is used to generate header files that
1285 may be installed into user space by "make header_install".
1287 It is run before "make archprepare" when run on the
1288 architecture itself.
1291 7.3 Add prerequisites to archprepare
1292 ------------------------------------
1294 The archprepare: rule is used to list prerequisites that need to be
1295 built before starting to descend down in the subdirectories.
1296 This is usually used for header files containing assembler constants.
1301 archprepare: maketools
1303 In this example, the file target maketools will be processed
1304 before descending down in the subdirectories.
1305 See also chapter XXX-TODO that describes how kbuild supports
1306 generating offset header files.
1309 7.4 List directories to visit when descending
1310 ---------------------------------------------
1312 An arch Makefile cooperates with the top Makefile to define variables
1313 which specify how to build the vmlinux file. Note that there is no
1314 corresponding arch-specific section for modules; the module-building
1315 machinery is all architecture-independent.
1318 head-y, core-y, libs-y, drivers-y
1319 $(head-y) lists objects to be linked first in vmlinux.
1321 $(libs-y) lists directories where a lib.a archive can be located.
1323 The rest list directories where a built-in.a object file can be
1326 Then the rest follows in this order:
1328 $(core-y), $(libs-y), $(drivers-y)
1330 The top level Makefile defines values for all generic directories,
1331 and arch/$(SRCARCH)/Makefile only adds architecture-specific
1336 # arch/sparc/Makefile
1337 core-y += arch/sparc/
1339 libs-y += arch/sparc/prom/
1340 libs-y += arch/sparc/lib/
1342 drivers-$(CONFIG_PM) += arch/sparc/power/
1344 7.5 Architecture-specific boot images
1345 -------------------------------------
1347 An arch Makefile specifies goals that take the vmlinux file, compress
1348 it, wrap it in bootstrapping code, and copy the resulting files
1349 somewhere. This includes various kinds of installation commands.
1350 The actual goals are not standardized across architectures.
1352 It is common to locate any additional processing in a boot/
1353 directory below arch/$(SRCARCH)/.
1355 Kbuild does not provide any smart way to support building a
1356 target specified in boot/. Therefore arch/$(SRCARCH)/Makefile shall
1357 call make manually to build a target in boot/.
1359 The recommended approach is to include shortcuts in
1360 arch/$(SRCARCH)/Makefile, and use the full path when calling down
1361 into the arch/$(SRCARCH)/boot/Makefile.
1366 boot := arch/x86/boot
1368 $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
1370 "$(Q)$(MAKE) $(build)=<dir>" is the recommended way to invoke
1371 make in a subdirectory.
1373 There are no rules for naming architecture-specific targets,
1374 but executing "make help" will list all relevant targets.
1375 To support this, $(archhelp) must be defined.
1381 echo '* bzImage - Compressed kernel image (arch/x86/boot/bzImage)'
1384 When make is executed without arguments, the first goal encountered
1385 will be built. In the top level Makefile the first goal present
1387 An architecture shall always, per default, build a bootable image.
1388 In "make help", the default goal is highlighted with a '*'.
1389 Add a new prerequisite to all: to select a default goal different
1397 When "make" is executed without arguments, bzImage will be built.
1399 7.7 Commands useful for building a boot image
1400 ---------------------------------------------
1402 Kbuild provides a few macros that are useful when building a
1406 Link target. Often, LDFLAGS_$@ is used to set specific options to ld.
1410 #arch/x86/boot/Makefile
1411 LDFLAGS_bootsect := -Ttext 0x0 -s --oformat binary
1412 LDFLAGS_setup := -Ttext 0x0 -s --oformat binary -e begtext
1414 targets += setup setup.o bootsect bootsect.o
1415 $(obj)/setup $(obj)/bootsect: %: %.o FORCE
1416 $(call if_changed,ld)
1418 In this example, there are two possible targets, requiring different
1419 options to the linker. The linker options are specified using the
1420 LDFLAGS_$@ syntax - one for each potential target.
1421 $(targets) are assigned all potential targets, by which kbuild knows
1422 the targets and will:
1424 1) check for commandline changes
1425 2) delete target during make clean
1427 The ": %: %.o" part of the prerequisite is a shorthand that
1428 frees us from listing the setup.o and bootsect.o files.
1431 It is a common mistake to forget the "targets :=" assignment,
1432 resulting in the target file being recompiled for no
1436 Copy binary. Uses OBJCOPYFLAGS usually specified in
1437 arch/$(SRCARCH)/Makefile.
1438 OBJCOPYFLAGS_$@ may be used to set additional options.
1441 Compress target. Use maximum compression to compress target.
1445 #arch/x86/boot/compressed/Makefile
1446 $(obj)/vmlinux.bin.gz: $(vmlinux.bin.all-y) FORCE
1447 $(call if_changed,gzip)
1450 Create flattened device tree blob object suitable for linking
1451 into vmlinux. Device tree blobs linked into vmlinux are placed
1452 in an init section in the image. Platform code *must* copy the
1453 blob to non-init memory prior to calling unflatten_device_tree().
1455 To use this command, simply add `*.dtb` into obj-y or targets, or make
1456 some other target depend on `%.dtb`
1458 A central rule exists to create `$(obj)/%.dtb` from `$(src)/%.dts`;
1459 architecture Makefiles do no need to explicitly write out that rule.
1464 DTC_FLAGS ?= -p 1024
1466 7.9 Preprocessing linker scripts
1467 --------------------------------
1469 When the vmlinux image is built, the linker script
1470 arch/$(SRCARCH)/kernel/vmlinux.lds is used.
1471 The script is a preprocessed variant of the file vmlinux.lds.S
1472 located in the same directory.
1473 kbuild knows .lds files and includes a rule `*lds.S` -> `*lds`.
1477 #arch/x86/kernel/Makefile
1478 extra-y := vmlinux.lds
1480 The assignment to extra-y is used to tell kbuild to build the
1482 The assignment to $(CPPFLAGS_vmlinux.lds) tells kbuild to use the
1483 specified options when building the target vmlinux.lds.
1485 When building the `*.lds` target, kbuild uses the variables::
1487 KBUILD_CPPFLAGS : Set in top-level Makefile
1488 cppflags-y : May be set in the kbuild makefile
1489 CPPFLAGS_$(@F) : Target-specific flags.
1490 Note that the full filename is used in this
1493 The kbuild infrastructure for `*lds` files is used in several
1494 architecture-specific files.
1496 7.10 Generic header files
1497 -------------------------
1499 The directory include/asm-generic contains the header files
1500 that may be shared between individual architectures.
1501 The recommended approach how to use a generic header file is
1502 to list the file in the Kbuild file.
1503 See "8.2 generic-y" for further info on syntax etc.
1508 If the file arch/xxx/Makefile.postlink exists, this makefile
1509 will be invoked for post-link objects (vmlinux and modules.ko)
1510 for architectures to run post-link passes on. Must also handle
1513 This pass runs after kallsyms generation. If the architecture
1514 needs to modify symbol locations, rather than manipulate the
1515 kallsyms, it may be easier to add another postlink target for
1516 .tmp_vmlinux? targets to be called from link-vmlinux.sh.
1518 For example, powerpc uses this to check relocation sanity of
1519 the linked vmlinux file.
1521 8 Kbuild syntax for exported headers
1522 ------------------------------------
1524 The kernel includes a set of headers that is exported to userspace.
1525 Many headers can be exported as-is but other headers require a
1526 minimal pre-processing before they are ready for user-space.
1527 The pre-processing does:
1529 - drop kernel-specific annotations
1530 - drop include of compiler.h
1531 - drop all sections that are kernel internal (guarded by `ifdef __KERNEL__`)
1533 All headers under include/uapi/, include/generated/uapi/,
1534 arch/<arch>/include/uapi/ and arch/<arch>/include/generated/uapi/
1537 A Kbuild file may be defined under arch/<arch>/include/uapi/asm/ and
1538 arch/<arch>/include/asm/ to list asm files coming from asm-generic.
1539 See subsequent chapter for the syntax of the Kbuild file.
1541 8.1 no-export-headers
1542 ---------------------
1544 no-export-headers is essentially used by include/uapi/linux/Kbuild to
1545 avoid exporting specific headers (e.g. kvm.h) on architectures that do
1546 not support it. It should be avoided as much as possible.
1551 If an architecture uses a verbatim copy of a header from
1552 include/asm-generic then this is listed in the file
1553 arch/$(SRCARCH)/include/asm/Kbuild like this:
1557 #arch/x86/include/asm/Kbuild
1558 generic-y += termios.h
1561 During the prepare phase of the build a wrapper include
1562 file is generated in the directory::
1564 arch/$(SRCARCH)/include/generated/asm
1566 When a header is exported where the architecture uses
1567 the generic header a similar wrapper is generated as part
1568 of the set of exported headers in the directory::
1572 The generated wrapper will in both cases look like the following:
1574 Example: termios.h::
1576 #include <asm-generic/termios.h>
1581 If an architecture generates other header files alongside generic-y
1582 wrappers, generated-y specifies them.
1584 This prevents them being treated as stale asm-generic wrappers and
1589 #arch/x86/include/asm/Kbuild
1590 generated-y += syscalls_32.h
1595 mandatory-y is essentially used by include/(uapi/)asm-generic/Kbuild
1596 to define the minimum set of ASM headers that all architectures must have.
1598 This works like optional generic-y. If a mandatory header is missing
1599 in arch/$(SRCARCH)/include/(uapi/)/asm, Kbuild will automatically
1600 generate a wrapper of the asm-generic one.
1605 The top Makefile exports the following variables:
1607 VERSION, PATCHLEVEL, SUBLEVEL, EXTRAVERSION
1608 These variables define the current kernel version. A few arch
1609 Makefiles actually use these values directly; they should use
1610 $(KERNELRELEASE) instead.
1612 $(VERSION), $(PATCHLEVEL), and $(SUBLEVEL) define the basic
1613 three-part version number, such as "2", "4", and "0". These three
1614 values are always numeric.
1616 $(EXTRAVERSION) defines an even tinier sublevel for pre-patches
1617 or additional patches. It is usually some non-numeric string
1618 such as "-pre4", and is often blank.
1621 $(KERNELRELEASE) is a single string such as "2.4.0-pre4", suitable
1622 for constructing installation directory names or showing in
1623 version strings. Some arch Makefiles use it for this purpose.
1626 This variable defines the target architecture, such as "i386",
1627 "arm", or "sparc". Some kbuild Makefiles test $(ARCH) to
1628 determine which files to compile.
1630 By default, the top Makefile sets $(ARCH) to be the same as the
1631 host system architecture. For a cross build, a user may
1632 override the value of $(ARCH) on the command line::
1637 This variable specifies the directory in arch/ to build.
1639 ARCH and SRCARCH may not necessarily match. A couple of arch
1640 directories are biarch, that is, a single `arch/*/` directory supports
1641 both 32-bit and 64-bit.
1643 For example, you can pass in ARCH=i386, ARCH=x86_64, or ARCH=x86.
1644 For all of them, SRCARCH=x86 because arch/x86/ supports both i386 and
1648 This variable defines a place for the arch Makefiles to install
1649 the resident kernel image and System.map file.
1650 Use this for architecture-specific install targets.
1652 INSTALL_MOD_PATH, MODLIB
1653 $(INSTALL_MOD_PATH) specifies a prefix to $(MODLIB) for module
1654 installation. This variable is not defined in the Makefile but
1655 may be passed in by the user if desired.
1657 $(MODLIB) specifies the directory for module installation.
1658 The top Makefile defines $(MODLIB) to
1659 $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE). The user may
1660 override this value on the command line if desired.
1663 If this variable is specified, it will cause modules to be stripped
1664 after they are installed. If INSTALL_MOD_STRIP is '1', then the
1665 default option --strip-debug will be used. Otherwise, the
1666 INSTALL_MOD_STRIP value will be used as the option(s) to the strip
1670 10 Makefile language
1671 ====================
1673 The kernel Makefiles are designed to be run with GNU Make. The Makefiles
1674 use only the documented features of GNU Make, but they do use many
1677 GNU Make supports elementary list-processing functions. The kernel
1678 Makefiles use a novel style of list building and manipulation with few
1681 GNU Make has two assignment operators, ":=" and "=". ":=" performs
1682 immediate evaluation of the right-hand side and stores an actual string
1683 into the left-hand side. "=" is like a formula definition; it stores the
1684 right-hand side in an unevaluated form and then evaluates this form each
1685 time the left-hand side is used.
1687 There are some cases where "=" is appropriate. Usually, though, ":="
1688 is the right choice.
1693 - Original version made by Michael Elizabeth Chastain, <mailto:mec@shout.net>
1694 - Updates by Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
1695 - Updates by Sam Ravnborg <sam@ravnborg.org>
1696 - Language QA by Jan Engelhardt <jengelh@gmx.de>
1701 - Describe how kbuild supports shipped files with _shipped.
1702 - Generating offset header files.
1703 - Add more variables to chapters 7 or 9?