C++ linux 内核模块链接器警告:“*** 警告:<function> [<module>] 未定义!” - 有什么办法可以摆脱它们?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/625685/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
linux kernel module linker warnings: "*** Warning: <function> [<module>] undefined!" - any way to get rid of them?
提问by Gary
While compiling Linux kernel modules that depend on each other, linker gives undefined symbol warnings like
在编译相互依赖的 Linux 内核模块时,链接器会给出未定义的符号警告,例如
Building modules, stage 2.
MODPOST
*** Warning: "function_name1" [module_name] undefined!
*** Warning: "function_name2" [module_name] undefined!
*** Warning: "function_name3" [module_name] undefined!
The unresolved symbols are resolved as soon as module is inserted into kernel using insmod or modprobe. Is there any way to get rid of the linker warning, though?
一旦使用 insmod 或 modprobe 将模块插入内核,就会解析未解析的符号。但是,有没有办法摆脱链接器警告?
I have read through 3 Google SERP's on this issue - it seems nobody knows the answer. Are these linker warnings supposed to be this way when you build a kernel module?
我已经阅读了关于这个问题的 3 个 Google SERP - 似乎没有人知道答案。当您构建内核模块时,这些链接器警告是否应该是这种方式?
回答by sinoj
Use KBUILD_EXTRA_SYMBOLS as below: KBUILD_EXTRA_SYMBOLS='your module path'/Module.symvers
使用 KBUILD_EXTRA_SYMBOLS 如下: KBUILD_EXTRA_SYMBOLS='your module path'/Module.symvers
回答by Gary
Finally, I got it. Thanks to shodanex for putting me on the right track.
最后我明白了。感谢 shodanex 让我走上正轨。
Update:Be very careful when applying this fix to builds for older versions of kernel, as there is a bug in Makefile.modpostfile in older versions of the kernel which makes your build misbehave and build wrong targets when you specify KBUILD_EXTMODoption.
更新:将此修复程序应用于旧版本内核的构建时要非常小心,因为旧版本内核中的Makefile.modpost文件中存在一个错误,当您指定KBUILD_EXTMOD选项时,该错误会使您的构建行为异常并构建错误的目标。
You have to specify the paths to the source of the modules you depend on in KBUILD_EXTMODmake parameter.
您必须在KBUILD_EXTMODmake 参数中指定您依赖的模块源的路径。
Say, you have a module foothat depends on symbols from module bar.
假设您有一个模块foo,它依赖于模块bar 中的符号。
Source files for fooare in foo/module/and source files for bar are in bar/module/
foo 的源文件在foo/module/ 中,bar 的源文件在bar/module/
The make command in Makefilefor fooprobably looks like
Makefile中foo的 make 命令可能看起来像
make ARCH=$$ARCH CROSS_COMPILE=$$CROSS_COMPILE -C $$LINUX_DIR \
M=`pwd`/module \
modules
(the exact line may differ in your project).
(确切的行可能在您的项目中有所不同)。
Change it to
将其更改为
make ARCH=$$ARCH CROSS_COMPILE=$$CROSS_COMPILE -C $$LINUX_DIR \
M=`pwd`/module \
KBUILD_EXTMOD=`pwd`/../bar/module \
modules
(we added the KBUILD_EXTMOD=pwd
/../bar/module \ line, where pwd
/../bar/module is a path to sources of kernel module we depend on.
(我们添加了 KBUILD_EXTMOD= pwd
/../bar/module \ 行,其中pwd
/../bar/module 是我们依赖的内核模块源的路径。
One would expect KBUILD_EXTRA_SYMBOLSparameter to work this way, however it's KBUILD_EXTMOD.
人们希望KBUILD_EXTRA_SYMBOLS参数以这种方式工作,但它是KBUILD_EXTMOD。
回答by shodanex
No they are not. Wheter you build your code in-tree or out of tree, this message should not be displayed.I think you should fix your Makefile. Here is an example makefile. Not perfect, but used to work (until 2.6.26, did not try it since) :
不,他们不是。无论您在树内还是树外构建代码,都不应显示此消息。我认为您应该修复您的 Makefile。这是一个示例生成文件。不完美,但曾经可以工作(直到 2.6.26,此后没有尝试过):
ifneq ($(KERNELRELEASE),)
# We were called by kbuild
obj-m += mymodule.o
mymodule-objs := mymodule_usb.o a.o b.o c.o
else # We were called from command line
KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
default:
@echo ' Building FOO drivers for 2.6 kernel.'
@echo ' PLEASE IGNORE THE "Overriding SUBDIRS" WARNING'
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
install:
./do_install.sh *.ko
endif # End kbuild check
clean:
rm -f -r *.o *.ko .*cmd .tmp* core *.i
For further documentation, you can check the kernel tree, the kbuild process is documented
如需进一步资料,您可以检查内核树中,kbuild的过程记录
回答by odinguru
Related to the above technique of using KBUILD_EXTMOD, and the question of which kernel versions it works under:
与上述使用 KBUILD_EXTMOD 的技术有关,以及它在哪些内核版本下工作的问题:
- andycjw indicated it didn't work for him in 2.6.12
- It didn't work for me in 2.6.15 (broke my module build)
- Looking through the kernel commits, I see a number of changes to Makefile.modpost that seem related in 2.6.26 and 2.6.28, so I expect one of those is the limit.
- andycjw 表示它在 2.6.12 中对他不起作用
- 它在 2.6.15 中对我不起作用(破坏了我的模块构建)
- 查看内核提交,我看到 Makefile.modpost 的许多更改似乎与 2.6.26 和 2.6.28 相关,因此我希望其中之一是限制。
回答by odinguru
My need to be tailored to your tree. In our source we created a SYMBOLSDIR that is a path to all the modules
我需要为你的树量身定做。在我们的源代码中,我们创建了一个 SYMBOLSDIR,它是所有模块的路径
SYMBOLSDIR = 'some path'
SYMBOLSDIR = '一些路径'
make (same as above example) $(KERNELDIR) MODVERDIR=$(SYMBOLSDIR) modules
make (同上例) $(KERNELDIR) MODVERDIR=$(SYMBOLSDIR) 模块