लिनक्स कर्नेल मॉड्यूल लिंकर चेतावनियां: "*** चेतावनी: <function> [<module>] अपरिभाषित!" - उनसे छुटकारा पाने के लिए कोई रास्ता?

Question

लिनक्स कर्नेल मॉड्यूल है कि एक दूसरे पर निर्भर संकलन है, लिंकर की तरह

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 का उपयोग कर गिरी में डाला जाता है अनसुलझे प्रतीक के रूप में जल्द ही हल कर रहे हैं। क्या लिंकर चेतावनी से छुटकारा पाने का कोई तरीका है, यद्यपि?

मैंने इस मुद्दे पर 3 Google SERP के माध्यम से पढ़ा है - ऐसा लगता है कि कोई भी जवाब नहीं जानता है। जब आप कर्नेल मॉड्यूल बनाते हैं तो क्या ये लिंकर चेतावनियां इस तरह से होती हैं?

Answer 1

नहीं वे नहीं हैं। व्हील आप अपने कोड को पेड़ या पेड़ से बाहर बनाते हैं, यह संदेश प्रदर्शित नहीं होना चाहिए। मुझे लगता है कि आपको अपने मेकफ़ाइल को ठीक करना चाहिए। मेकफ़ाइल उदाहरण यहां दिया गया है। सही नहीं है, लेकिन काम करने के लिए प्रयोग किया जाता है (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 के लिए धन्यवाद।

अद्यतन: बहुत करते समय सावधान रहें, यह सुधार गिरी के पुराने संस्करणों के लिए बनाता है के लिए आवेदन के रूप में वहाँ गिरी जो बनाता है अपने निर्माण दुर्व्यवहार और निर्माण के पुराने संस्करणों में में Makefile.modpost फ़ाइल एक बग है जब आप KBUILD_EXTMOD विकल्प निर्दिष्ट करते हैं तो गलत लक्ष्य।

आपको KBUILD_EXTMOD पैरामीटर बनाने वाले मॉड्यूल के स्रोत के पथ को निर्दिष्ट करना होगा।

कहो, आप एक मॉड्यूल foo कि मॉड्यूल बार से प्रतीकों पर निर्भर करता है है।

foo के लिए स्रोत फ़ाइलें 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 में संबंधित प्रतीत होता है, इसलिए मुझे उम्मीद है कि उनमें से एक सीमा है।