Question

我注意到最近的内核（从2.16.24开始？）不喜欢在外部模块Kbuild文件中更改CFLAGS。如果更改了CFLAGS，您将被Linux内核Kbuild系统发出以下错误：

scripts/Makefile.build:46: *** CFLAGS was changed in "/some/path". Fix it to use EXTRA_CFLAGS.  Stop.

来自here：

外部模块在少数情况下修改了gcc选项通过修改CFLAGS。这从未被记录过是一种不好的做法。

来自LKML的其他email。

为什么不好主意？什么是理性的？

Answer 1

首先，值得一提的是EXTRA_CFLAGS不久前已被弃用，并被ccflags-y取代。您可以在ccflags-y第3.7节中了解Documentation/kbuild/makefiles.txt的用意。

基本上，此变量允许您将设置附加到C编译标志集，仅在分配它的文件范围内。您不应该更改全局标志，因为可能具有超出您自己的makefile的全局影响，这被认为是不好的做法。您提到的检查验证确实，包含的makefile没有改变全局标志。

有趣的是查看ccflags-y（以前称为EXTRA_CFLAGS）最终是如何在构建过程中使用的。追踪一些相关的观点（但不是全部，因为这是留给读者的练习;-)）显示以下内容：

根据{{1}}

，仍然可以使用

EXTRA_CFLAGS

scripts/Makefile.lib

同一个文件显示1 # Backward compatibility 2 asflags-y += $(EXTRA_AFLAGS) 3 ccflags-y += $(EXTRA_CFLAGS)如何在C编译标志中结束（并且还显示您有另一个变量可供您使用，称为ccflags-y）：

CFLAGS_<filename>.o

然后在104 orig_c_flags = $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) $(KBUILD_SUBDIR_CCFLAGS) \ 105 $(ccflags-y) $(CFLAGS_$(basetarget).o) 106 _c_flags = $(filter-out $(CFLAGS_REMOVE_$(basetarget).o), $(orig_c_flags)) ... 133 __c_flags = $(_c_flags) ... 147 c_flags = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) \ 148 $(__c_flags) $(modkern_cflags) \ 149 -D"KBUILD_STR(s)=\#s" $(basename_flags) $(modname_flags)中，定义了编译规则：

scripts/Makefile.build

请注意，这些都是递归扩展变量，使用234 cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $<而不是=，这意味着当您在自己的{C}中定义它时，自己的:=值会被插入到C标志中拥有makefile。

最后关于ccflags-y，您在标题中提及但未在实际问题中提及。可以通过提供KBUILD_NOPEDANTIC任意值来禁用此CFLAGS更改值的测试 - 请参阅KBUILD_NOPEDANTIC

scripts/Makefile.build

这个答案中引用的文件都是今天检索的。

现在......在写下这整个故事之后，不再是这方面的专家并进一步研究makefile，有一件事我也不明白。在我看来，47 ifeq ($(KBUILD_NOPEDANTIC),) 48 ifneq ("$(save-cflags)","$(CFLAGS)") 49 $(error CFLAGS was changed in "$(kbuild-file)". Fix it to use ccflags-y) 50 endif 51 endif没有在构建系统中使用（不是隐式的，也不是显式的），但CFLAGS是。{1}}。所以我想知道KBUILD_CFLAGS中对此更改的检查是否应该实际检查CFLAGS中的更改。

Answer 2

Linux makefile以适合内核的方式构建CFLAGS 覆盖CFLAGS意味着您添加一些标志并可能删除一些标志。一些被删除的标志对于正确编译可能很重要。

内核模块编译和KBUILD_NOPEDANTIC

2 个答案: