gcc मेकफाइल त्रुटि: "लक्ष्य बनाने के लिए कोई नियम नहीं ..."

355

मैं अपनी परियोजना को संकलित करने के लिए एक बदलाव के साथ जीसीसी (लिनक्स) का उपयोग करने की कोशिश कर रहा हूं।

मुझे निम्नलिखित त्रुटि मिलती है जो इस संदर्भ में समझ में नहीं आती है:

"No rule to make target 'vertex.cpp', needed by 'vertex.o'.  Stop."

यह मेकफाइल है:

a.out: vertex.o edge.o elist.o main.o vlist.o enode.o vnode.o
    g++ vertex.o edge.o elist.o main.o vlist.o enode.o vnode.o

main.o: main.cpp main.h
    g++ -c main.cpp

vertex.o: vertex.cpp vertex.h
    g++ -c vertex.cpp

edge.o: edge.cpp edge.h
    g++ -c num.cpp

vlist.o: vlist.cpp vlist.h
    g++ -c vlist.cpp

elist.o: elist.cpp elist.h
    g++ -c elist.cpp

vnode.o: vnode.cpp vnode.h
    g++ -c vnode.cpp

enode.o: enode.cpp enode.h
    g++ -c node.cpp

gcc makefile

— मीर
स्रोत

2

एक विशिष्ट उदाहरण जिसे आप 'स्रोत फ़ाइल बनाते हैं' मौजूद नहीं है '' VPATH या SRC चर को गलती से रीसेट करने से है जब आपको इसे जोड़ना होगा। मेरा मतलब usnig के VPATH=बजाय है VPATH+=। इससे मेकफाइल फ़ाइल तब नहीं देख सकती जब फ़ाइल वास्तव में होती है।

— किम

424

ऐसा आमतौर पर इसलिए होता है क्योंकि आपके पास vertex.cppउपलब्ध कराने के लिए फाइल नहीं होती है । जांच करे:

वह फ़ाइल मौजूद है।
जब आप बनाते हैं तो आप सही निर्देशिका में होते हैं।

इसके अलावा, मैंने सुझाव देने के लिए बहुत कुछ नहीं किया है। शायद आप हमें उस निर्देशिका की एक निर्देशिका सूची दे सकते हैं।

— paxdiablo
स्रोत

2

हां, मेरी कुछ कक्षाओं में .cpp फाइलें नहीं हैं, इसलिए वे वहां नहीं थीं- त्रुटि का कारण। धन्यवाद।

— मेयर

4

अगर आपको हटाए जाने वाले कुछ हेडर फाइल हैं तो भी आपको ऐसी त्रुटि मिल सकती है लेकिन फिर भी आपके Makefile में हैं

— ady

@par, जो मेरे लिए एक अलग प्रश्न की तरह दिखता है। यदि आप इसे एक प्रश्न के रूप में पूछते हैं, तो आपको संभवतः अधिक जोखिम मिलेगा ।

— पाक्सिडाब्लो

इसके अलावा, सुनिश्चित करें कि आपने अपने मेकफाइल को संपादित करने के बाद सहेज लिया है ... यही मुझे मिला है। मैंने अपने सभी संपादन किए, फिर CTRL + S

— टिम

80

मेरे अनुभव में, यह त्रुटि अक्सर वर्तनी की त्रुटि के कारण होती है।

मुझे आज यह त्रुटि मिली।

make [1]: *** लक्ष्य maintenaceDialog.cpp', needed bymaintenaceDialog.o बनाने के लिए कोई नियम नहीं है । रूक जा।

मेरे मामले में त्रुटि केवल वर्तनी की त्रुटि थी। शब्द रखरखाव याद आ रही थी यह तीसरा एन है।

अपने फ़ाइलनाम पर वर्तनी की भी जाँच करें।

— वेस
स्रोत

2

मेटा क्यों , इस मामले में वस्तु / स्रोत / हेडर संबंधों को स्पष्ट रूप से सूचीबद्ध करने के कारण है। यदि SubCons या CMake जैसे नए उपकरण स्वाद के लिए नहीं हैं, gcc -MT और गनु मेक पैटर्न इसे हल कर सकते हैं। देखें भी ।

— नाथन किड

आपने मेरा दिन बचाया! धन्यवाद! :)

— सुनीत गौतम

मेरे मामले में रास्ता गलत था ../../src/file.cलेकिन वास्तव में यह था../../src/folder/file.c

— रस्मी रंजन नायक

31

इस संदेश को मुद्रित करने का अधिक सामान्य कारण है क्योंकि आप उस निर्देशिका को शामिल करना भूल गए जिसमें स्रोत फ़ाइल रहती है। नतीजतन, जीसीसी "सोचता है" यह फ़ाइल मौजूद नहीं है।

आप -I तर्क का उपयोग करके निर्देशिका जोड़ सकते हैं gcc।

14

मेरे मामले में मेरे पास अस्थि-पंजर का उपयोग अल्पविराम के रूप में विभाजक के रूप में था। आपके उदाहरण का उपयोग करने के लिए मैंने ऐसा किया:

a.out: vertex.o, edge.o, elist.o, main.o, vlist.o, enode.o, vnode.o
    g++ vertex.o edge.o elist.o main.o vlist.o enode.o vnode.o

के बराबर में बदल रहा है

a.out: vertex.o edge.o elist.o main.o vlist.o enode.o vnode.o
    g++ vertex.o edge.o elist.o main.o vlist.o enode.o vnode.o

ठीक कर दिया।

— निक नॉल्सन
स्रोत

11

क्या यह ठीक है? याद रखें कि Makefile सिंटेक्स व्हाट्सएप जागरूक है और कार्यों के तहत आदेशों को टैब की आवश्यकता होती है।

— workmad3
स्रोत

7

जो समस्या मुझे मिली वह अन्य लोगों द्वारा बताई गई बातों की तुलना में भी अधिक गंभीर थी।

हमारे मेकफाइल्स को बनाने के लिए चीजों की सूची पास हो जाती है। किसी ने TheOtherLibraryसूची में जोड़ा , जैसा कि नीचे दिखाया गया है।

LIBRARYDIRS = src/Library
LIBRARYDIRS = src/TheOtherLibrary

उन्हें ऐसा करना चाहिए था:

LIBRARYDIRS = src/Library
LIBRARYDIRS += src/TheOtherLibrary

अगर उन्होंने इसे दूसरे तरीके से किया होता, तो वे Libraryबिल्ड का सफाया नहीं करते । में प्लस +=बहुत महत्वपूर्ण है।

— kmort
स्रोत

6

मेरे मामले में यह मेकफाइल में एक बहु-पंक्ति नियम त्रुटि के कारण था। मेरे पास कुछ ऐसा था:

OBJS-$(CONFIG_OBJ1)            += file1.o file2.o \
                                  file3.o file4.o \
OBJS-$(CONFIG_OBJ2)            += file5.o 
OBJS-$(CONFIG_OBJ3)            += file6.o
...

CONFIG_OBJ1'S नियम में फ़ाइल सूची के अंत में बैकस्लैश इस त्रुटि का कारण बना। यह इस तरह होना चाहिए:

OBJS-$(CONFIG_OBJ1)            += file1.o file2.o \
                                  file3.o file4.o
OBJS-$(CONFIG_OBJ2)            += file5.o
...

— uluorta
स्रोत

5

लगातार गलतियों में से एक दूसरे फ़ाइल नाम में टाइपो हो सकती है ।

आप उदाहरण काफी सीधे हैं, लेकिन कभी-कभी भ्रमित हो सकते हैं makeखुद के संदेश हैं । आइए एक उदाहरण पर विचार करें।

मेरी फ़ोल्डर सामग्री है:

$ ls -1
another_file
index.md
makefile

जबकि मेरी makefileशक्ल ऐसी है

all: index.html

%.html: %.md wrong_path_to_another_file
    @echo $@ $<

हालांकि मेरे पास index.mdयह है कि यह कहां होना चाहिए और इसके नाम पर कोई गलती नहीं है, इससे संदेश makeजाएगा

make: *** No rule to make target `index.html', needed by `all'.  Stop.

ईमानदार होना संदेश भ्रामक है । यह सिर्फ यह कहता है, कि कोई नियम नहीं है। वास्तव में, इसका मतलब है कि नियम गलत है, लेकिन वाइल्डकार्ड (पैटर्न) नियमों के makeकारण यह निर्धारित नहीं कर सकता है कि वास्तव में समस्या क्या हुई।

makefileकहने के लिए थोड़ा बदलें , जो स्पष्ट नियमों के साथ पैटर्न को बदलना है:

index.html: index.md wrong_path_to_another_file

और अब हमें जो संदेश मिलेगा वह होगा:

make: *** No rule to make target `wrong_path_to_another_file', needed by `index.html'.  Stop.

चमत्कार! निम्नलिखित निष्कर्ष निकाला जा सकता है:

संदेश makeनियमों पर निर्भर करते हैं और हमेशा समस्याओं की जड़ की ओर इशारा नहीं करते हैं
makefileइस संदेश द्वारा निर्दिष्ट आपके भिन्न में अन्य समस्याएं हो सकती हैं

अब हम एक नियम में अन्य निर्भरता की जाँच करने के विचार के साथ आए हैं :

all: index.html

%.html: %.md another_file
    @echo $@ $<

केवल यह हमें वांछित परिणाम प्रदान करेगा:

$ make
index.html index.md

— निक रोज
स्रोत

3

मेरे मामले में, त्रुटि संदेश एक पुराने फ़ाइल नाम को संदर्भित करता है, जो अब मौजूद नहीं था क्योंकि इसका नाम बदल दिया गया था। यह पता चला कि पुरानी जानकारी मेकफाइल से नहीं आई थी, लेकिन .depsनिर्देशिका में फ़ाइलों से ।

मैं एक मशीन से दूसरी मशीन में फ़ाइलों की प्रतिलिपि बनाने के बाद इस त्रुटि में भाग गया। उस प्रक्रिया में, मुझे लगता है कि समयावधि में प्राप्त टाइमस्टैम्प्स, जो समानांतर में कई नौकरियों को चलाने के दौरान "बनाते" हैं ( इस बग रिपोर्ट के समान )।

के साथ अनुक्रमिक बिल्ड make -j 1प्रभावित नहीं थे, लेकिन मुझे यह महसूस करने में थोड़ा समय लगा क्योंकि मैं एक उपनाम ( make -j 8) का उपयोग कर रहा था ।

राज्य को साफ करने के लिए, मैंने सभी .depsफाइलों को हटा दिया और मेकफाइल को फिर से तैयार किया। ये वे कमांड हैं जिनका मैंने उपयोग किया था:

find | grep '.deps' | xargs rm
find | grep '.deps' | xargs rmdir
autoreconf --install # (optional, but my project is using autotools) 
./configure

उसके बाद, इमारत ने फिर से काम किया।

— फिलिप क्लेयन
स्रोत

2

यदि आप जॉन द रिपर "ब्लीडिंग-जंबो" का निर्माण करने की कोशिश कर रहे हैं और "मेक: *** कोई नियम नहीं है तो लक्ष्य 'linux-x86-64' बनाने के लिए। इसके बजाय इस कमांड को चलाने का प्रयास करें:./configure && make

— Ogglas
स्रोत

0

मेरे मामले में, स्रोत और / या पुरानी ऑब्जेक्ट फ़ाइल (ओं) को अर्ध-दुर्घटनाग्रस्त आईडीई द्वारा या बैकअप क्लाउड सेवा से लॉक किया गया (रीड-ओनली) जो ठीक से काम करना बंद कर रहा था। फ़ोल्डर संरचना से जुड़े सभी प्रोग्राम और सेवाओं को पुनरारंभ करने से समस्या हल हो गई।

— sskoog
स्रोत

0

एक अजीब समस्या और इसके समाधान का एक और उदाहरण:

इस:

target_link_libraries(
    ${PROJECT_NAME}
    ${Poco_LIBRARIES}
    ${Poco_Foundation_LIBRARY}
    ${Poco_Net_LIBRARY}
    ${Poco_Util_LIBRARY}
    )

देता है: make[3]: *** No rule to make target '/usr/lib/libPocoFoundationd.so', needed by '../hello_poco/bin/mac/HelloPoco'. Stop.

लेकिन अगर मैं हटाता हूं तो Poco_LIBRARIESयह काम करता है:

target_link_libraries(
    ${PROJECT_NAME}
    ${Poco_Foundation_LIBRARY}
    ${Poco_Net_LIBRARY}
    ${Poco_Util_LIBRARY}
    )

मैं मैक पर clang8 का उपयोग कर रहा हूं और लिनक्स पर 3.9 का उपयोग कर रहा हूं। समस्या केवल लिनक्स पर होती है लेकिन मैक पर काम करती है!

मैं उल्लेख करना भूल गया: Poco_LIBRARIESगलत था - यह cmake / find_package द्वारा सेट नहीं किया गया था!

— माइक मेटरर
स्रोत

0

मेरे मामले में VPATH में पथ सेट नहीं किया गया है, त्रुटि को जोड़ने के बाद।

— tzuhsun
स्रोत

0

इस त्रुटि के कई कारण हैं।

एक कारण जहां मैंने इस त्रुटि का सामना किया है, लिनक्स और खिड़कियों के लिए निर्माण करते समय।

मेरे पास कैप्सलैस के साथ एक फाइलनेम है। SubClass.h SubClass.h यूनिक्स का कहना है कि केस-सेंसिटिव फाइलिंग कन्वेंशन है और विंडोज़ केस-इन्सेंसिव है।

C ++ लोग हेडर फ़ाइलों के नाम पर अपरकेस का उपयोग क्यों नहीं करते हैं?

यदि आप gmake का उपयोग कर रहे हैं, तो gmake का उपयोग करके स्वच्छ बिल्ड का संकलन करने का प्रयास करें

कुछ पाठ संपादकों में केस-संवेदी फ़ाइलनामों को अनदेखा करने के लिए डिफ़ॉल्ट सेटिंग्स हैं। इससे भी वही त्रुटि हो सकती है।

Qt Creator में c ++ फ़ाइल कैसे जोड़ें जिसका नाम बड़े अक्षरों से शुरू होता है? यह स्वचालित रूप से इसे छोटा अक्षर बनाता है

— Corning
स्रोत

0

ट्रैविस के अंदर यह त्रुटि तब हुई जब मैं अपनी गिट रिपॉजिटरी में नई फाइलें जोड़ना भूल गया। मूर्खतापूर्ण गलती, लेकिन मैं इसे काफी सामान्य देख सकता हूं।

— रेयान डेसचैम्प्स
स्रोत

-1

मेरे मामले में, यह मेरे लिए मेकफाइल कॉल करने के कारण था: मेकएयर (सभी कैप्स)

— ninjaPixel
स्रोत