यह कमांड मेकप_ट्यूटोरियल_कंपिलेशन है जिसे हमारे कई मुफ्त ऑनलाइन वर्कस्टेशन जैसे कि उबंटू ऑनलाइन, फेडोरा ऑनलाइन, विंडोज ऑनलाइन एमुलेटर या मैक ओएस ऑनलाइन एमुलेटर का उपयोग करके ऑनवर्क्स फ्री होस्टिंग प्रदाता में चलाया जा सकता है।
कार्यक्रम:
नाम
makepp_tutorial_compilation -- यूनिक्स संकलन आदेश
वर्णन
यदि आपको इस बात की अच्छी समझ है कि संकलन आदेश क्या करते हैं, तो इस मैनुअल पृष्ठ को छोड़ दें।
मुझे लगता है कि परेशान करने वाली बात यह है कि बहुत कम लोगों को उनकी प्रोग्रामिंग कक्षाओं में यह सिखाया जाता है कि कैसे
प्रोग्राम लिखने के बाद उन्हें संकलित करना शुरू करें। नौसिखिए या तो एक पर भरोसा करते हैं
याद किया गया आदेश, या फिर अंतर्निहित नियमों पर। मुझे आश्चर्य हुआ है
अत्यधिक कंप्यूटर साक्षर लोग जिन्होंने अनुकूलन के बिना संकलन करना सीखा क्योंकि
उन्हें कभी बताया ही नहीं गया कि यह कितना महत्वपूर्ण है। संकलन कैसे किया जाता है इसका प्रारंभिक ज्ञान
कमांड का काम आपके प्रोग्राम को दोगुनी या उससे अधिक तेजी से चला सकता है, इसलिए कम से कम यह इसके लायक है
पाँच मिनट। यह पृष्ठ सी को संकलित करने के लिए आपको जो कुछ जानने की आवश्यकता है उसके बारे में वर्णन करता है
या यूनिक्स के लगभग किसी भी संस्करण पर C++ प्रोग्राम।
उदाहरण अधिकतर C के लिए होंगे, क्योंकि नाम को छोड़कर C++ संकलन समान है
कंपाइलर अलग है. मान लीजिए आप नामक फ़ाइल में स्रोत कोड संकलित कर रहे हैं
"xyz.c" और आप "xyz" नामक एक प्रोग्राम बनाना चाहते हैं। क्या होना चाहिए?
आप जानते होंगे कि आप इस तरह एक कमांड का उपयोग करके अपना प्रोग्राम एक चरण में बना सकते हैं:
सीसी -जी xyz.c -o xyz
यह काम करेगा, लेकिन इसमें दो-चरणीय प्रक्रिया छिपी हुई है जिसे आपको समझना होगा यदि आप हैं
मेकफ़ाइलें लिखना। (वास्तव में, दो से अधिक चरण हैं, लेकिन आपको केवल ऐसा करना है
उनमें से दो को समझें।) एक से अधिक मॉड्यूल के प्रोग्राम के लिए, आमतौर पर दो चरण होते हैं
स्पष्ट रूप से अलग किया गया।
संकलन
पहला चरण आपके C या C++ स्रोत कोड को बाइनरी फ़ाइल में अनुवाद करना है
एक ऑब्जेक्ट फ़ाइल. ऑब्जेक्ट फ़ाइलों में आमतौर पर ".o" का एक्सटेंशन होता है। (कुछ और हालिया के लिए
प्रोजेक्ट्स में, ".lo" का उपयोग थोड़ी भिन्न प्रकार की ऑब्जेक्ट फ़ाइल के लिए भी किया जाता है।)
यूनिक्स पर ऑब्जेक्ट फ़ाइल बनाने का आदेश कुछ इस तरह दिखता है:
सीसी -जी -सी xyz.c -o xyz.o
"सीसी" सी कंपाइलर है। कभी-कभी वैकल्पिक सी कंपाइलर का उपयोग किया जाता है; एक बहुत आम है
"जीसीसी" कहा जाता है। एक सामान्य C++ कंपाइलर GNU कंपाइलर है, जिसे आमतौर पर "g++" कहा जाता है। आभासी रूप से
यूनिक्स पर सभी सी और सी++ कंपाइलर्स में बाकी कमांड के लिए समान सिंटैक्स होता है (कम से कम)।
बुनियादी संचालन के लिए), इसलिए एकमात्र अंतर पहला शब्द होगा।
हम बाद में बताएंगे कि "-g" विकल्प क्या करता है।
"-सी" विकल्प सी कंपाइलर को आउटपुट के रूप में ".o" फ़ाइल तैयार करने के लिए कहता है। (यदि आप नहीं करते हैं
"-c" निर्दिष्ट करें, फिर यह स्वचालित रूप से दूसरा संकलन चरण निष्पादित करता है।)
"-o xyz.o" विकल्प कंपाइलर को बताता है कि ऑब्जेक्ट फ़ाइल का नाम क्या है। तुम कर सकते हो
इसे छोड़ दें, जब तक ऑब्जेक्ट फ़ाइल का नाम स्रोत के नाम के समान है
फ़ाइल ".o" एक्सटेंशन को छोड़कर।
अधिकांश भाग के लिए, विकल्पों का क्रम और फ़ाइल नाम कोई मायने नहीं रखते। एक
महत्वपूर्ण अपवाद यह है कि आउटपुट फ़ाइल को तुरंत "-o" का अनुसरण करना चाहिए।
जोड़ने
किसी प्रोग्राम के निर्माण का दूसरा चरण कहलाता है जोड़ने. कोई ऑब्जेक्ट फ़ाइल नहीं चलाई जा सकती
सीधे तौर पर; यह एक मध्यवर्ती रूप है जो होना ही चाहिए जुड़ा हुआ अन्य घटकों के लिए
एक प्रोग्राम तैयार करें. अन्य घटकों में शामिल हो सकते हैं:
· पुस्तकालय. ए पुस्तकालयमोटे तौर पर कहें तो, यह ऑब्जेक्ट मॉड्यूल का एक संग्रह है
आवश्यकतानुसार शामिल किया गया। उदाहरण के लिए, यदि आपका प्रोग्राम "प्रिंटफ" फ़ंक्शन को कॉल करता है, तो
"प्रिंटफ" फ़ंक्शन की परिभाषा को सिस्टम सी लाइब्रेरी से शामिल किया जाना चाहिए।
कुछ लाइब्रेरी स्वचालित रूप से आपके प्रोग्राम से लिंक हो जाती हैं (उदाहरण के लिए, जिसमें
"प्रिंटफ") इसलिए आपको उनके बारे में कभी भी चिंता करने की आवश्यकता नहीं है।
· आपके प्रोग्राम में अन्य स्रोत फ़ाइलों से प्राप्त ऑब्जेक्ट फ़ाइलें। यदि आप अपना लिखते हैं
प्रोग्राम को इस प्रकार बनाएं कि इसमें वास्तव में कई स्रोत फ़ाइलें हों, सामान्यतः आप प्रत्येक को संकलित करेंगे
स्रोत फ़ाइल को एक अलग ऑब्जेक्ट फ़ाइल में बदलें और फिर उन सभी को एक साथ लिंक करें।
RSI संयोजक ऑब्जेक्ट फ़ाइलों का संग्रह लेने के लिए प्रोग्राम जिम्मेदार है और
एक निष्पादन योग्य फ़ाइल बनाने के लिए पुस्तकालयों और उन्हें एक साथ जोड़ना। निष्पादन योग्य फ़ाइल है
वह प्रोग्राम जो आप वास्तव में चलाते हैं।
प्रोग्राम को लिंक करने का कमांड कुछ इस तरह दिखता है:
सीसी -जी xyz.ओ -ओ xyz
यह अजीब लग सकता है, लेकिन हम आमतौर पर लिंकिंग करने के लिए एक ही प्रोग्राम ("सीसी") चलाते हैं। क्या
सतह के नीचे ऐसा होता है कि "सीसी" प्रोग्राम तुरंत नियंत्रण से बाहर हो जाता है
एक नंबर जोड़ने के बाद अलग-अलग प्रोग्राम (लिंकर, जिसे कभी-कभी लोडर या "एलडी" भी कहा जाता है)।
कमांड लाइन पर जानकारी के जटिल टुकड़े। उदाहरण के लिए, "cc" "ld" को बताता है कि कहाँ है
सिस्टम लाइब्रेरी वह है जिसमें "प्रिंटफ" जैसे फ़ंक्शंस की परिभाषा शामिल है। जब तक तुम
साझा लाइब्रेरी लिखना शुरू करें, आपको आमतौर पर सीधे "एलडी" से निपटने की ज़रूरत नहीं है।
यदि आप "-o xyz" निर्दिष्ट नहीं करते हैं, तो आउटपुट फ़ाइल को "a.out" कहा जाएगा, जो प्रतीत होता है
मेरे लिए यह पूरी तरह से बेकार और भ्रमित करने वाला सम्मेलन है। इसलिए हमेशा "-o" निर्दिष्ट करें
लिंक करने का चरण.
यदि आपके प्रोग्राम में एक से अधिक ऑब्जेक्ट फ़ाइल हैं, तो आपको सभी ऑब्जेक्ट फ़ाइलों को निर्दिष्ट करना चाहिए
लिंक कमांड।
क्यों इसलिए आप आवश्यकता सेवा मेरे अलग la कदम
इस तरह सरल, एक-चरणीय कमांड का उपयोग क्यों न करें:
सीसी -जी xyz.c -o xyz
अधिक जटिल दो-चरणीय संकलन के बजाय
सीसी -जी -सी xyz.c -o xyz.o
सीसी -जी xyz.ओ -ओ xyz
यदि आंतरिक रूप से प्रथम को दूसरे में परिवर्तित कर दिया जाए? अंतर तभी महत्वपूर्ण है जब
आपके प्रोग्राम में एक से अधिक मॉड्यूल हैं. मान लीजिए हमारे पास एक अतिरिक्त मॉड्यूल है,
"एबीसी.सी"। अब हमारा संकलन इस प्रकार दिखता है:
# वन-स्टेज कमांड.
सीसी-जी xyz.c एबीसी.सी-ओ xyz
or
# दो चरणीय आदेश.
सीसी -जी -सी xyz.c -o xyz.o
सीसी-जी-सी एबीसी.सी-ओ एबीसी.ओ
सीसी-जी xyz.ओ एबीसी.ओ-ओ xyz
बेशक, पहली विधि आंतरिक रूप से दूसरी विधि में परिवर्तित हो जाती है। इसका मतलब यह है
प्रत्येक बार कमांड चलाने पर "xyz.c" और "abc.c" दोनों को पुन: संकलित किया जाता है। पर अगर तुम
केवल "xyz.c" को बदला गया है, "abc.c" को पुनः संकलित करने की कोई आवश्यकता नहीं है, इसलिए दोनों की दूसरी पंक्ति-
स्टेज कमांड करने की आवश्यकता नहीं है। इससे संकलन में बड़ा अंतर आ सकता है
समय, खासकर यदि आपके पास कई मॉड्यूल हैं। इस कारण से, वस्तुतः सभी मेकफ़ाइलें रखी जाती हैं
दो संकलन चरण अलग-अलग हैं।
यह काफी हद तक बुनियादी बातें हैं, लेकिन कुछ और छोटी-छोटी जानकारियां हैं जो आपको वास्तव में करनी चाहिए
के बारे में जानना।
डीबगिंग बनाम इष्टतमीकरण
आमतौर पर प्रोग्रामर किसी प्रोग्राम को या तो डिबग के लिए या स्पीड के लिए संकलित करते हैं। संकलन
गति के लिए कहा जाता है इष्टतमीकरण; अनुकूलन के साथ संकलन करने से आपका कोड अधिकतम तक चल सकता है
आपके कोड, आपके प्रोसेसर और आपके कंपाइलर के आधार पर 5 गुना तेज़ या अधिक।
ऐसे नाटकीय लाभ संभव होने पर, आप कभी भी अनुकूलन क्यों नहीं करना चाहेंगे? सबसे
महत्वपूर्ण उत्तर यह है कि अनुकूलन डिबगर के उपयोग को और अधिक कठिन बना देता है
(कभी-कभी असंभव)। (यदि आप डिबगर के बारे में कुछ नहीं जानते हैं, तो यह सीखने का समय है।
बुनियादी बातें सीखने में आप जो आधा घंटा या घंटा खर्च करेंगे, उसका प्रतिफल कई गुना अधिक होगा
बाद में डिबगिंग के दौरान आप जो समय बचाएंगे। मैं GUI डिबगर से शुरुआत करने की अनुशंसा करूंगा
जैसे "kdbg", "ddd", या "gdb" emacs के भीतर से चलते हैं (इसके लिए gdb पर जानकारी पृष्ठ देखें)
इसे कैसे करें इस पर निर्देश)।) अनुकूलन कथनों को पुन: व्यवस्थित और संयोजित करता है, हटाता है
अनावश्यक अस्थायी चर, और आम तौर पर आपके कोड को पुनर्व्यवस्थित करता है ताकि यह बहुत हो
डिबगर के अंदर अनुसरण करना कठिन है। सामान्य प्रक्रिया अपना कोड लिखना, उसे संकलित करना है
अनुकूलन के बिना, इसे डीबग करें, और फिर अनुकूलन चालू करें।
डिबगर को काम करने के लिए, कंपाइलर को न केवल सहयोग करना होगा
अनुकूलन, बल्कि वस्तु में प्रतीकों के नामों के बारे में जानकारी डालकर भी
फ़ाइल करें ताकि डिबगर को पता चले कि चीज़ों को क्या कहा जाता है। यह "-जी" संकलन है
विकल्प करता है.
यदि आपने डिबगिंग पूरी कर ली है, और आप अपना कोड अनुकूलित करना चाहते हैं, तो बस "-g" को प्रतिस्थापित करें
"-ओ"। कई कंपाइलरों के लिए, आप जोड़कर अनुकूलन के बढ़ते स्तर निर्दिष्ट कर सकते हैं
"-O" के बाद एक संख्या. आप अन्य विकल्प भी निर्दिष्ट करने में सक्षम हो सकते हैं जो इसे बढ़ाते हैं
कुछ परिस्थितियों में गति (संभवतः बढ़ी हुई मेमोरी उपयोग के साथ व्यापार बंद)। देखना
विवरण के लिए आपके कंपाइलर का मैन पेज। उदाहरण के लिए, यहां एक अनुकूलन संकलन कमांड है
जिसे मैं "जीसीसी" कंपाइलर के साथ अक्सर उपयोग करता हूं:
जीसीसी -O6 -घातक-डबल -c xyz.c -o xyz.o
सर्वोत्तम सर्वोत्तम के लिए आपको विभिन्न अनुकूलन विकल्पों के साथ प्रयोग करना पड़ सकता है
प्रदर्शन। आपको कोड के विभिन्न हिस्सों के लिए अलग-अलग विकल्पों की आवश्यकता हो सकती है। आम तौर पर
बोलते हुए, "-O6" जैसा एक सरल अनुकूलन ध्वज आमतौर पर कई कंपाइलरों के साथ काम करता है
काफी अच्छे परिणाम देता है.
चेतावनी: दुर्लभ अवसरों पर, आपका प्रोग्राम वास्तव में बिल्कुल वही काम नहीं करता है जब
इसे अनुकूलन के साथ संकलित किया गया है। ऐसा (1) आपके द्वारा की गई अमान्य धारणा के कारण हो सकता है
आपके कोड में जो अनुकूलन के बिना हानिरहित था, लेकिन समस्याएँ पैदा करता है क्योंकि
जब आप अनुकूलन करते हैं तो कंपाइलर चीजों को पुनर्व्यवस्थित करने की स्वतंत्रता लेता है; या (2) दुख की बात है,
कंपाइलरों में भी बग हैं, जिनमें उनके ऑप्टिमाइज़र में बग भी शामिल हैं। जैसे एक स्थिर कंपाइलर के लिए
पेंटियम जैसे सामान्य प्लेटफ़ॉर्म पर "जीसीसी", अनुकूलन बग शायद ही कोई समस्या है (जैसा कि)
वर्ष 2000--कुछ वर्ष पहले समस्याएँ थीं)।
यदि आप अपने संकलन आदेश में "-g" या "-O" निर्दिष्ट नहीं करते हैं, तो परिणामी ऑब्जेक्ट
फ़ाइल न तो डिबगिंग के लिए और न ही तेज़ चलने के लिए उपयुक्त है। किसी कारण से, यह है
गलती करना। इसलिए हमेशा या तो "-g" या "-O" निर्दिष्ट करें।
कुछ प्रणालियों पर, आपको संकलन और लिंकिंग दोनों चरणों पर "-g" प्रदान करना होगा; दूसरों पर
(उदाहरण के लिए लिनक्स), इसे केवल संकलन चरण पर आपूर्ति करने की आवश्यकता है। कुछ प्रणालियों पर, "-O"
वास्तव में लिंकिंग चरण में कुछ अलग होता है, जबकि अन्य पर इसका कोई प्रभाव नहीं पड़ता है।
किसी भी स्थिति में, दोनों आदेशों के लिए "-g" या "-O" प्रदान करना हमेशा हानिरहित होता है।
:
अधिकांश कंपाइलर कई सामान्य प्रोग्रामिंग त्रुटियों को पकड़ने में सक्षम हैं (उदाहरण के लिए,
किसी फ़ंक्शन से कोई मान लौटाना भूल जाना, जिसे कोई मान लौटाना चाहिए)। आम तौर पर,
आप चेतावनियाँ चालू करना चाहेंगे. आप यह कैसे करते हैं यह आपके कंपाइलर पर निर्भर करता है (आदमी देखें)।
पेज), लेकिन "जीसीसी" कंपाइलर के साथ, मैं आमतौर पर कुछ इस तरह का उपयोग करता हूं:
जीसीसी -जी -वॉल -सी xyz.c -o xyz.o
(कभी-कभी मैं एक चेतावनी के कारण "-Wall" के बाद "-Wno-uninitialized" भी जोड़ देता हूं
आमतौर पर गलत होता है जो अनुकूलन करते समय सामने आता है।)
इन चेतावनियों ने मुझे डिबगिंग के कई घंटे बचाए हैं।
अन्य उपयोगी संकलन विकल्पों
अक्सर, आवश्यक फ़ाइलों को वर्तमान के अलावा किसी अन्य निर्देशिका में संग्रहीत किया जाता है
निर्देशिका या सिस्टम में निर्देशिका शामिल है (/ usr / शामिल हैं). ऐसा अक्सर होता है जब
आप एक लाइब्रेरी का उपयोग कर रहे हैं जो फ़ंक्शंस या कक्षाओं को परिभाषित करने के लिए फ़ाइलों के साथ आती है।
उदाहरण के लिए, मान लीजिए, आप एक एप्लिकेशन लिख रहे हैं जो Qt लाइब्रेरीज़ का उपयोग करता है। आपने
में Qt लाइब्रेरी की एक स्थानीय प्रति स्थापित की गई /होम/उपयोगकर्ता/जो/क्यूटी, जिसका मतलब है कि
शामिल फ़ाइलें निर्देशिका में संग्रहीत हैं /होम/उपयोगकर्ता/जो/क्यूटी/शामिल हैं. आपके कोड में, आप
इस तरह की चीजें करने में सक्षम होना चाहते हैं:
#शामिल करना
के बजाय
#शामिल है "/home/users/joe/qt/include/qwidget.h"
आप कंपाइलर को इसका उपयोग करके किसी भिन्न निर्देशिका में फ़ाइलें शामिल करने के लिए कह सकते हैं
"-I" संकलन विकल्प:
g++ -I/home/users/joe/qt/include -g -c mywidget.cpp -o mywidget.o
आमतौर पर "-I" और निर्देशिका नाम के बीच कोई स्थान नहीं होता है।
जब C++ कंपाइलर फ़ाइल की तलाश कर रहा हो qwidget.h, यह अंदर दिखेगा
/होम/उपयोगकर्ता/जो/क्यूटी/शामिल हैं सिस्टम में देखने से पहले निर्देशिका शामिल करें। तुम कर सकते हो
आप जितने चाहें उतने "-I" विकल्प निर्दिष्ट करें।
का प्रयोग पुस्तकालयों
आपको अक्सर लिंकर को विशिष्ट बाहरी पुस्तकालयों से लिंक करने के लिए कहना होगा, यदि आप
ऐसे किसी भी फ़ंक्शन को कॉल कर रहे हैं जो मानक C लाइब्रेरी का हिस्सा नहीं हैं। "-एल" (लोअरकेस
एल) विकल्प एक विशिष्ट पुस्तकालय से लिंक करने के लिए कहता है:
सीसी -जी xyz.ओ -ओ xyz -lm
"-एलएम" सिस्टम गणित लाइब्रेरी से लिंक करने के लिए कहता है, यदि आप उपयोग कर रहे हैं तो आपको इसकी आवश्यकता होगी
"sqrt" जैसे कार्य।
सावधान: यदि आप एक से अधिक "-एल" विकल्प निर्दिष्ट करते हैं, तो ऑर्डर कुछ पर अंतर डाल सकता है
सिस्टम. यदि आपको अपरिभाषित चर मिल रहे हैं जबकि आप जानते हैं कि आपने इन्हें शामिल कर लिया है
लाइब्रेरी जो उन्हें परिभाषित करती है, आप उस लाइब्रेरी को कमांड के अंत तक ले जाने का प्रयास कर सकते हैं
लाइन, या कमांड लाइन के अंत में इसे दूसरी बार भी शामिल करें।
कभी-कभी जिन पुस्तकालयों की आपको आवश्यकता होगी वे सिस्टम के लिए डिफ़ॉल्ट स्थान पर संग्रहीत नहीं होते हैं
पुस्तकालय. "-labc" नामक फ़ाइल खोजता है libabc.a or libabc.so or libabc.sa में
सिस्टम लाइब्रेरी निर्देशिकाएँ (/ Usr / lib और आमतौर पर कुछ अन्य स्थान भी, किस पर निर्भर करते हैं
आप जिस प्रकार का यूनिक्स चला रहे हैं)। "-L" विकल्प खोज के लिए एक अतिरिक्त निर्देशिका निर्दिष्ट करता है
पुस्तकालयों के लिए. उपरोक्त उदाहरण को फिर से लेने के लिए, मान लें कि आपने Qt लाइब्रेरीज़ स्थापित की हैं
in /होम/उपयोगकर्ता/जो/क्यूटी, जिसका अर्थ है कि लाइब्रेरी फ़ाइलें अंदर हैं /home/users/joe/qt/lib.
आपके प्रोग्राम के लिए आपका लिंक चरण कुछ इस तरह दिख सकता है:
g++ -g test_mywidget.o mywidget.o -o test_mywidget -L/home/users/joe/qt/lib -lqt
(कुछ प्रणालियों पर, यदि आप Qt में लिंक करते हैं तो आपको अन्य लाइब्रेरी भी जोड़ने की आवश्यकता होगी (उदाहरण के लिए,
"-L/usr/X11R6/lib -lX11 -lXext"). आपको क्या करना है यह आपके सिस्टम पर निर्भर करेगा।)
ध्यान दें कि "-L" और निर्देशिका नाम के बीच कोई स्थान नहीं है। आमतौर पर "-L" विकल्प
इसे प्रभावित करने वाले किसी भी "-एल" विकल्प से पहले जाता है।
आप कैसे जानते हैं कि आपको किन पुस्तकालयों की आवश्यकता है? सामान्य तौर पर, यह एक कठिन प्रश्न है और भिन्न-भिन्न है
यह इस पर निर्भर करता है कि आप किस प्रकार का यूनिक्स चला रहे हैं। कार्यों के लिए दस्तावेज़ीकरण या
आप जिन कक्षाओं का उपयोग कर रहे हैं उनमें यह लिखा होना चाहिए कि आपको किन पुस्तकालयों से लिंक करने की आवश्यकता है। यदि आप उपयोग कर रहे हैं
बाहरी पैकेज से फ़ंक्शंस या कक्षाएं, आमतौर पर एक लाइब्रेरी होती है जिसे आपको लिंक करने की आवश्यकता होती है
साथ; लाइब्रेरी आमतौर पर "libabc.a" या "libabc.so" या "libabc.sa" नामक फ़ाइल होगी
यदि आपको "-labc" विकल्प जोड़ने की आवश्यकता है।
कुछ अन्य भ्रमित चीज़ें
आपने देखा होगा कि उन विकल्पों को निर्दिष्ट करना संभव है जो सामान्य रूप से लागू होते हैं
लिंकिंग चरण पर संकलन, और विकल्प जो सामान्यतः लिंकिंग पर लागू होते हैं
संकलन चरण. उदाहरण के लिए, निम्नलिखित आदेश मान्य हैं:
cc -g -L/usr/X11R6/lib -c xyz.c -o xyz.o
cc -g -I/कहीं/include xyz.o -o xyz
अप्रासंगिक विकल्पों को नजरअंदाज कर दिया जाता है; उपरोक्त आदेश बिल्कुल इसके समतुल्य हैं:
सीसी -जी -सी xyz.c -o xyz.o
सीसी -जी xyz.ओ -ओ xyz
onworks.net सेवाओं का उपयोग करके ऑनलाइन makepp_tutorial_compilation का उपयोग करें
