Предупреждение о компоновщике модуля ядра Linux: «*** Предупреждение: <function> [<module>] undefined!" - любой способ избавиться от них?

Question

При компиляции модулей ядра Linux, которые зависят друг от друга, линкер дает неопределенные предупреждения символа, как

Building modules, stage 2. 
MODPOST 
*** Warning: "function_name1" [module_name] undefined! 
*** Warning: "function_name2" [module_name] undefined! 
*** Warning: "function_name3" [module_name] undefined! 

Неразрешенные символы разрешены, как только модуль вставляется в ядро ​​с помощью insmod или Modprobe. Есть ли способ избавиться от предупреждения компоновщика?

Я прочитал три запроса Google по этому вопросу - кажется, никто не знает ответа. Предполагается ли, что эти предупреждения компоновщика должны быть такими, когда вы создаете модуль ядра?

Answer 1

Нет, они не являются. Вы создаете свой код в дереве или вне дерева, это сообщение не должно отображаться. Я думаю, вы должны исправить свой Makefile. Вот пример 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 

Для получения дополнительной документации, вы можете проверить дерево ядра, процесс kbuild является documented

Answer 2

Наконец, я понял. Спасибо shodanex за то, что поставили меня на правильный путь.

Update: Будьте очень осторожны при применении это исправление для сборки для более старых версий ядра, так как есть ошибка в Makefile.modpost файл в старых версиях ядра, что делает ваш строить шалить и строить неправильные цели при указании KBUILD_EXTMOD опция.

Вы должны указать пути к источнику модулей, в которых вы зависите, в KBUILD_EXTMOD make параметр.

Скажем, у вас есть модуль Foo, который зависит от символов из модуля бар.

Исходные файлы для обув в Foo/модуль/файлы и истока для бара в бар/модуль/

Команда делают в Makefile для обув вероятно выглядит

make ARCH=$$ARCH CROSS_COMPILE=$$CROSS_COMPILE -C $$LINUX_DIR \ 
    M=`pwd`/module \ 
    modules 

(точная линия может отличаться в зависимости от проекта).

Изменить его

make ARCH=$$ARCH CROSS_COMPILE=$$CROSS_COMPILE -C $$LINUX_DIR \ 
    M=`pwd`/module \ 
    KBUILD_EXTMOD=`pwd`/../bar/module \ 
    modules 

(мы добавили KBUILD_EXTMOD = pwd /../bar/module \ линии, где pwd /../bar/module является путем к источникам модуля ядра мы зависим на.

Можно было бы ожидать KBUILD_EXTRA_SYMBOLS параметр работать таким образом, однако это KBUILD_EXTMOD.

Answer 3

Моя потребность быть адаптирована к вашему дереву. В нашем источнике мы создали SYMBOLSDIR, который является путем для всех модулей

SYMBOLSDIR = 'некоторого пути'

сделать (так же, как описаны выше, например) $ (KERNELDIR) MODVERDIR = $ (SYMBOLSDIR) модули

Answer 4

Используйте KBUILD_EXTRA_SYMBOLS, как показано ниже: KBUILD_EXTRA_SYMBOLS = «ваш модуль путь»/Module.symvers

Answer 5

, относящиеся к выше методике с использованием KBUILD_EXTMOD, и вопрос о том, какое ядро ​​версии он работает под:

• andycjw указала, что она не работает для него в 2.6.12
• Это не работает для меня в 2.6.15 (сломал мой модуль сборки)
• Просматривая ядро ​​совершает, я вижу ряд изменений в Makefile.modpost, которые, как представляется, связаны в 2.6.26 и 2.6.28, поэтому я ожидаю, что один из них является пределом.