2012-06-18 15 views
13

मैंने देखा है कि हालिया कर्नेल (2.16.24 से शुरू हो रहा है?) पसंद नहीं है अगर बाहरी मॉड्यूल Kbuild फ़ाइल में CFLAGS बदल दिया गया है। यदि CFLAGS बदल गया है आप लिनक्स कर्नेल Kbuild प्रणाली द्वारा निम्न त्रुटि जारी जाएगा:कर्नेल मॉड्यूल संकलन और KBUILD_NOPEDANTIC

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

here से:

बाहरी मॉड्यूल CFLAGS संशोधित करके जीसीसी विकल्प modifed कुछ मामलों में की है। यह कभी दस्तावेज नहीं किया गया है और एक बुरा अभ्यास था।

एलकेएमएल से अतिरिक्त email

यह बुरा विचार क्यों है? तर्कसंगत क्या है?

उत्तर

1

लिनक्स मेकफ़ाइल CFLAGS को कर्नेल के लिए उपयुक्त तरीके से बनाता है।
ओवरराइडिंग CFLAGS का मतलब है कि आप कुछ झंडे जोड़ते हैं और कुछ झंडे हटा सकते हैं। सही संकलन के लिए हटाए गए झंडे में से कुछ महत्वपूर्ण हो सकते हैं।

+0

अगर मुझे लगता है कि CFLAGS झंडे हैं तो पूरे कर्नेल को संकलित किया गया है और इसलिए बदला नहीं जाना चाहिए। इसका मतलब है कि कर्नेल केबीयूल्ड सिस्टम मेरे बाहरी मॉड्यूल को CFLAGS + EXTRA_CFLAGS के साथ संकलित करेगा। सही बात? – dimba

+0

मुझे लगता है कि यह करता है। – ugoren

9

सबसे पहले, यह उल्लेखनीय हो सकता है कि EXTRA_CFLAGS को कुछ समय पहले बहिष्कृत कर दिया गया है और इसे ccflags-y द्वारा प्रतिस्थापित किया गया है। आप , सेक्शन 3.7 में ccflags-y के इरादे के बारे में पढ़ सकते हैं।

असल में, यह चर आपको उस फ़ाइल के दायरे में सी संकलन झंडे के सेट में सेटिंग्स को जोड़ने की अनुमति देता है जहां इसे केवल असाइन किया जाता है। आपको वैश्विक झंडे को बदलने की जरूरत नहीं है, क्योंकि आपके खुद के मेकफ़ाइल से परे वैश्विक प्रभाव डाल सकता है, जिसे खराब अभ्यास माना जाता है। आपके द्वारा उल्लिखित चेक सत्यापित करता है कि वास्तव में, ग्लोबल झंडे को मेकफ़ाइल द्वारा बदला नहीं गया था।

यह देखना दिलचस्प है कि ccflags-y, जिसे पहले EXTRA_CFLAGS के नाम से जाना जाता है, निर्माण प्रक्रिया में उपयोग किया जा रहा है। (, लेकिन सभी नहीं क्योंकि कि पाठक ;-) करने के लिए एक व्यायाम के रूप में छोड़ दिया जाता है) कुछ प्रासंगिक अंक ट्रेसिंग से पता चलता है:

EXTRA_CFLAGS अभी भी प्रयोग किया जा सकता है, scripts/Makefile.lib

1 # Backward compatibility 
2 asflags-y += $(EXTRA_AFLAGS) 
3 ccflags-y += $(EXTRA_CFLAGS) 

एक ही फाइल के अनुसार दिखाता है कि कैसे 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 में

, कंप्यूटर अनुप्रयोग ilation नियम परिभाषित किया गया है:

234 cmd_cc_o_c = $(CC) $(c_flags) -c -o [email protected] $< 

नोट है कि इन सभी रिकर्सिवली का विस्तार कर रहे हैं चर, = और नहीं :=, जिसका अर्थ है कि ccflags-y का अपना स्वयं का मूल्य सी झंडे में डाला हो जाता है जब आप अपने खुद के makefile में परिभाषित का उपयोग कर।

अंततः KBUILD_NOPEDANTIC, जिसे आप शीर्षक में उल्लेख करते हैं लेकिन वास्तविक प्रश्न में नहीं।CFLAGS की बदली हुई मूल्य के लिए यह परीक्षण KBUILD_NOPEDANTIC किसी भी मूल्य देकर निष्क्रिय किया जा सकता - scripts/Makefile.build

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 का निर्माण प्रणाली में नहीं किया जाता है (स्पष्ट रूप से, न ही स्पष्ट रूप से), लेकिन KBUILD_CFLAGS है। तो मुझे आश्चर्य है कि CFLAGS में बदलावों के लिए यह जांच वास्तव में KBUILD_CFLAGS में परिवर्तनों की जांच होनी चाहिए।

संबंधित मुद्दे