आपका लिंकेज ऑब्जेक्ट फ़ाइलों से पहले पुस्तकालयों की खपत करता है जो उन्हें संदर्भित करता है
- आप अपने कार्यक्रम को जीसीसी टूलकिन के साथ संकलित करने और जोड़ने की कोशिश कर रहे हैं।
- आपका लिंकेज सभी आवश्यक पुस्तकालयों और पुस्तकालय खोज पथों को निर्दिष्ट करता है
- यदि पर
libfooनिर्भर करता है libbar, तो आपका लिंकेज सही तरीके libfooसे पहले रखता है libbar।
- आपका लिंक
undefined reference to कुछ त्रुटियों के साथ विफल हो जाता है ।
- लेकिन आपके द्वारा की गई हेडर फाइलों में सभी अपरिभाषित कुछ s घोषित किए
#includeजाते हैं और वास्तव में उन पुस्तकालयों में परिभाषित होते हैं जिन्हें आप लिंक कर रहे हैं।
उदाहरण सी में हैं। वे समान रूप से अच्छी तरह से सी ++ हो सकते हैं
आपके द्वारा बनाए गए स्थिर पुस्तकालय में शामिल एक न्यूनतम उदाहरण
my_lib.c
#include "my_lib.h"
#include <stdio.h>
void hw(void)
{
puts("Hello World");
}
my_lib.h
#ifndef MY_LIB_H
#define MT_LIB_H
extern void hw(void);
#endif
eg1.c
#include <my_lib.h>
int main()
{
hw();
return 0;
}
आप अपनी स्थैतिक लाइब्रेरी का निर्माण करते हैं:
$ gcc -c -o my_lib.o my_lib.c
$ ar rcs libmy_lib.a my_lib.o
आप अपना कार्यक्रम संकलित करें:
$ gcc -I. -c -o eg1.o eg1.c
आप इसे जोड़ने libmy_lib.aऔर विफल करने का प्रयास करते हैं:
$ gcc -o eg1 -L. -lmy_lib eg1.o
eg1.o: In function `main':
eg1.c:(.text+0x5): undefined reference to `hw'
collect2: error: ld returned 1 exit status
एक ही परिणाम यदि आप एक चरण में संकलित और लिंक करते हैं, जैसे:
$ gcc -o eg1 -I. -L. -lmy_lib eg1.c
/tmp/ccQk1tvs.o: In function `main':
eg1.c:(.text+0x5): undefined reference to `hw'
collect2: error: ld returned 1 exit status
एक साझा प्रणाली पुस्तकालय, संपीड़न पुस्तकालय में शामिल एक न्यूनतम उदाहरण libz
eg2.c
#include <zlib.h>
#include <stdio.h>
int main()
{
printf("%s\n",zlibVersion());
return 0;
}
अपना कार्यक्रम संकलित करें:
$ gcc -c -o eg2.o eg2.c
अपने प्रोग्राम को जोड़ने libzऔर विफल करने का प्रयास करें :
$ gcc -o eg2 -lz eg2.o
eg2.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'
collect2: error: ld returned 1 exit status
यदि आप संकलित करते हैं और एक ही बार में लिंक करते हैं:
$ gcc -o eg2 -I. -lz eg2.c
/tmp/ccxCiGn7.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'
collect2: error: ld returned 1 exit status
और उदाहरण 2 में एक भिन्नता शामिल है pkg-config:
$ gcc -o eg2 $(pkg-config --libs zlib) eg2.o
eg2.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'
आप क्या गलत कर रहे हैं?
ऑब्जेक्ट फ़ाइलों और पुस्तकालयों के अनुक्रम में आप अपने प्रोग्राम को बनाने के लिए लिंक करना चाहते हैं, आप ऑब्जेक्ट फ़ाइलों से पहले पुस्तकालयों को रख रहे हैं जो उन्हें संदर्भित करते हैं। आपको इसके बाद पुस्तकालयों को रखने की आवश्यकता है उन ऑब्जेक्ट फ़ाइलों के जो उन्हें संदर्भित करते हैं।
लिंक उदाहरण 1 सही ढंग से:
$ gcc -o eg1 eg1.o -L. -lmy_lib
सफलता:
$ ./eg1
Hello World
लिंक उदाहरण 2 सही ढंग से:
$ gcc -o eg2 eg2.o -lz
सफलता:
$ ./eg2
1.2.8
उदाहरण 2 pkg-configविविधता को सही ढंग से लिंक करें :
$ gcc -o eg2 eg2.o $(pkg-config --libs zlib)
$ ./eg2
1.2.8
स्पष्टीकरण
पढ़ना यहाँ से वैकल्पिक है ।
डिफ़ॉल्ट रूप से, आपके डिस्ट्रो पर जीसीसी द्वारा उत्पन्न एक लिंकेज कमांड, कमांडलाइन अनुक्रम में बाएं से दाएं लिंकेज में फाइलों का उपभोग करता है। जब यह पता चलता है कि एक फ़ाइल किसी चीज़ को संदर्भित करती है
और इसके लिए परिभाषा नहीं होती है, तो आगे दाईं ओर फ़ाइलों में परिभाषा की खोज की जाएगी। यदि यह अंततः एक परिभाषा पाता है, तो संदर्भ हल हो जाता है। यदि कोई संदर्भ अंत में अनसुलझे रहते हैं, तो लिंकेज विफल हो जाता है: लिंकर पीछे की ओर नहीं खोजता है।
सबसे पहले, उदाहरण 1 , स्थैतिक पुस्तकालय के साथmy_lib.a
एक स्थिर पुस्तकालय ऑब्जेक्ट फ़ाइलों का एक अनुक्रमित संग्रह है। जब लिंकर -lmy_libलिंकेज अनुक्रम में पाता है और यह पता लगाता है कि यह स्थैतिक पुस्तकालय को संदर्भित करता है ./libmy_lib.a, तो यह जानना चाहता है कि क्या आपके प्रोग्राम को ऑब्जेक्ट फ़ाइलों में से किसी की आवश्यकता है libmy_lib.a।
libmy_lib.aअर्थात् में केवल ऑब्जेक्ट फ़ाइल है , my_lib.oऔर वहाँ केवल एक चीज में परिभाषित है my_lib.o, अर्थात् कार्य hw।
लिंकर यह तय करेगा कि आपके कार्यक्रम की जरूरत my_lib.oहै और केवल अगर यह पहले से ही जानता है कि आपके कार्यक्रम को संदर्भित करता है hw, तो एक या एक से अधिक ऑब्जेक्ट फ़ाइलों में यह पहले से ही प्रोग्राम में जोड़ा गया है, और यह कि पहले से ही जोड़ा गया ऑब्जेक्ट फ़ाइलों में से कोई भी शामिल नहीं है के लिए परिभाषा hw।
यदि यह सच है, तो लिंकर my_lib.oपुस्तकालय से एक प्रति निकालेगा और आपके कार्यक्रम में जोड़ देगा। फिर, आपके कार्यक्रम में एक परिभाषा है hw, इसलिए इसके संदर्भ हलhw किए जाते हैं ।
जब आप प्रोग्राम को लिंक करने का प्रयास करते हैं जैसे:
$ gcc -o eg1 -L. -lmy_lib eg1.o
लिंकर प्रोग्राम को देखता है जब यह जोड़ा नहीं है
। क्योंकि उस बिंदु पर, यह नहीं देखा है । आपका कार्यक्रम अभी तक के सभी संदर्भ पड़ता है नहीं : यह अभी तक कोई भी संदर्भ नहीं है सब पर है, क्योंकि सभी संदर्भों को यह बनाता है में हैं ।eg1.o -lmy_libeg1.ohweg1.o
इसलिए लिंकर my_lib.oकार्यक्रम में शामिल नहीं होता है और इसका कोई और उपयोग नहीं है libmy_lib.a।
अगला, इसे पाता है eg1.o, और इसे प्रोग्राम होने के लिए जोड़ता है। लिंकेज अनुक्रम में एक ऑब्जेक्ट फ़ाइल को हमेशा प्रोग्राम में जोड़ा जाता है। अब, कार्यक्रम एक संदर्भ बनाता है hw, और इसमें परिभाषा नहीं होती है hw; लेकिन लिंकेज अनुक्रम में कुछ भी नहीं बचा है जो लापता परिभाषा प्रदान कर सकता है। संदर्भ अनसुलझेhw समाप्त होता है , और लिंकेज विफल हो जाता है।
साझा पुस्तकालय के साथ दूसरा, उदाहरण 2libz
एक साझा लाइब्रेरी ऑब्जेक्ट फ़ाइलों या इसके जैसे कुछ का संग्रह नहीं है। यह एक प्रोग्राम की तरह बहुत अधिक है, जिसमें कोई mainफ़ंक्शन नहीं है और इसके बजाय यह परिभाषित करने वाले कई अन्य प्रतीकों को उजागर करता है, ताकि अन्य प्रोग्राम रनटाइम के दौरान उनका उपयोग कर सकें।
कई Linux distros आज उनके जीसीसी toolchain ताकि उसके भाषा ड्राइवरों (कॉन्फ़िगर gcc, g++, gfortranआदि) प्रणाली लिंकर (हिदायत ldएक पर लिंक साझा पुस्तकालयों के लिए) के रूप में जरूरी आधार। आपको उन विकृतियों में से एक मिला है।
इसका मतलब यह है कि जब लिंकर -lzलिंकेज अनुक्रम में पाता है, और यह पता लगाता है कि यह साझा लाइब्रेरी (कहता है) को संदर्भित करता है /usr/lib/x86_64-linux-gnu/libz.so, तो यह जानना चाहता है कि क्या आपके प्रोग्राम में शामिल किए गए किसी भी संदर्भ को अभी तक परिभाषित नहीं किया गया है, इसकी परिभाषाएं हैं द्वारा निर्यात किया गयाlibz
अगर यह सच है, तो लिंकर बाहर किसी भी हिस्सा को कॉपी नहीं करेगा libzऔर उन्हें आपके प्रोग्राम में जोड़ देगा; इसके बजाय, यह सिर्फ आपके प्रोग्राम के कोड को डॉक्टर करेगा ताकि: -
रनटाइम के दौरान, सिस्टम प्रोग्राम लोडर libzआपके प्रोग्राम की एक ही प्रक्रिया में एक कॉपी लोड करेगा जब भी यह आपके प्रोग्राम की एक कॉपी लोड करता है, इसे चलाने के लिए।
रनटाइम के दौरान, जब भी आपका प्रोग्राम किसी ऐसी चीज़ को संदर्भित करता है, जिसे उस परिभाषित किया जाता है
libz, तो संदर्भ libzउसी प्रक्रिया की कॉपी द्वारा निर्यात की गई परिभाषा का उपयोग करता है।
आपका कार्यक्रम केवल एक चीज को संदर्भित करना चाहता है जिसकी एक परिभाषा है libzजिसका निर्यात किया जाता है , अर्थात् फ़ंक्शन zlibVersion, जिसे केवल एक बार, में संदर्भित किया जाता है eg2.c। यदि लिंकर आपके कार्यक्रम में उस संदर्भ को जोड़ता है, और फिर द्वारा निर्यात की गई परिभाषा पाता है libz, तो संदर्भ हल हो जाता है
लेकिन जब आप प्रोग्राम को लिंक करने का प्रयास करते हैं जैसे:
gcc -o eg2 -lz eg2.o
घटनाओं का क्रम ठीक उसी तरह से गलत है जैसे उदाहरण 1। जिस बिंदु पर जब लिंकर को पता चलता है -lz, तो कार्यक्रम में किसी भी चीज का कोई संदर्भ नहीं होता है : वे सभी अंदर हैं eg2.o, जो अभी तक नहीं देखा गया है। तो लिंकर यह तय करता है कि इसका कोई उपयोग नहीं है libz। जब यह पहुंचता है eg2.o, तो इसे प्रोग्राम में जोड़ता है, और फिर इसका अपरिभाषित संदर्भ होता है zlibVersion, लिंकेज अनुक्रम समाप्त हो जाता है; वह संदर्भ अनसुलझा है, और लिंकेज विफल है।
अंत में, pkg-configउदाहरण 2 की भिन्नता का अब स्पष्ट स्पष्टीकरण है। शेल-विस्तार के बाद:
gcc -o eg2 $(pkg-config --libs zlib) eg2.o
हो जाता है:
gcc -o eg2 -lz eg2.o
जो सिर्फ 2 उदाहरण फिर से है।
मैं उदाहरण 1 में समस्या को पुन: पेश कर सकता हूं, लेकिन उदाहरण 2 में नहीं
लिंकेज:
gcc -o eg2 -lz eg2.o
तुम्हारे लिए ठीक काम करता है!
(या: लिंकेज ने आपके लिए ठीक काम किया, कहते हैं, फेडोरा 23, लेकिन उबंटू 16.04 पर विफल रहता है)
ऐसा इसलिए है क्योंकि डिस्ट्रॉ जिस पर लिंकेज काम करता है, उनमें से एक है जो अपने जीसीसी टूलकिन को साझा पुस्तकालयों को आवश्यकतानुसार जोड़ने के लिए कॉन्फ़िगर नहीं करता है ।
दिन में, यूनिक्स जैसी प्रणालियों के लिए विभिन्न नियमों द्वारा स्थिर और साझा पुस्तकालयों को जोड़ना सामान्य था। एक सीक्वेंस सीक्वेंस में स्टेटिक लाइब्रेरीज़ को उदाहरण 1 में बताए गए आवश्यक आधार पर लिंक किया गया था , लेकिन साझा लाइब्रेरी को बिना शर्त लिंक किया गया था।
यह व्यवहार लिंकटाइम पर किफायती है क्योंकि लिंक करने वाले को यह विचार करने की आवश्यकता नहीं है कि प्रोग्राम द्वारा साझा लाइब्रेरी की आवश्यकता है: यदि यह एक साझा लाइब्रेरी है, तो इसे लिंक करें। और अधिकांश लिंकेज में अधिकांश लाइब्रेरी साझा लाइब्रेरी हैं। लेकिन इसके नुकसान भी हैं: -
यह रनटाइम में अनौपचारिक है , क्योंकि यह साझा पुस्तकालयों को एक कार्यक्रम के साथ लोड किए जाने का कारण बन सकता है, भले ही उनकी आवश्यकता न हो।
स्थिर और साझा पुस्तकालयों के लिए अलग-अलग लिंकेज नियम अनुभवहीन प्रोग्रामर को भ्रमित कर सकते हैं, जो यह नहीं जान सकते हैं कि -lfooउनके लिंकेज में /some/where/libfoo.aया तो समाधान करने जा रहे हैं या नहीं /some/where/libfoo.so, और वैसे भी साझा और स्थिर पुस्तकालयों के बीच अंतर को समझ नहीं सकते हैं।
इस व्यापार बंद के कारण आज विद्वतापूर्ण स्थिति पैदा हो गई है। कुछ पुस्तकालयों ने साझा पुस्तकालयों के लिए अपने जीसीसी लिंकेज नियमों को बदल दिया है ताकि
सभी पुस्तकालयों के लिए आवश्यक सिद्धांत लागू हो। कुछ डिस्ट्रॉर्स पुराने तरीके से अटक गए हैं।
अगर मुझे उसी समय संकलन और लिंक भी मिल जाता है, तो भी मुझे यह समस्या क्यों आती है?
अगर मैं बस:
$ gcc -o eg1 -I. -L. -lmy_lib eg1.c
निश्चित रूप से जीसीसी को eg1.cपहले संकलित करना है , और फिर परिणामी ऑब्जेक्ट फ़ाइल के साथ लिंक करना है libmy_lib.a। तो यह कैसे पता नहीं चल सकता है कि लिंक करते समय ऑब्जेक्ट फ़ाइल की आवश्यकता है?
क्योंकि एकल कमांड के साथ संकलन और लिंक करना लिंकेज अनुक्रम के क्रम को नहीं बदलता है।
जब आप ऊपर कमांड चलाते हैं, gccतो यह पता लगाते हैं कि आप संकलन + लिंकेज चाहते हैं। तो पर्दे के पीछे, यह एक संकलन कमांड उत्पन्न करता है, और इसे चलाता है, फिर एक लिंकेज कमांड उत्पन्न करता है, और इसे चलाता है, जैसे कि आपने दो कमांड चलाए थे:
$ gcc -I. -c -o eg1.o eg1.c
$ gcc -o eg1 -L. -lmy_lib eg1.o
तो कड़ी में विफल रहता है अगर आप बस के रूप में यह होता है है उन दो आदेशों को चलाने के। विफलता में आपको केवल इतना ही अंतर दिखाई देता है कि जीसीसी ने संकलन + लिंक मामले में एक अस्थायी ऑब्जेक्ट फ़ाइल उत्पन्न की है, क्योंकि आप इसे उपयोग करने के लिए नहीं कह रहे हैं eg1.o। हम देखते हैं:
/tmp/ccQk1tvs.o: In function `main'
के बजाय:
eg1.o: In function `main':
यह सभी देखें
जिस क्रम में अन्योन्याश्रित लिंक्ड लाइब्रेरी निर्दिष्ट की गई है वह गलत है
गलत क्रम में अन्योन्याश्रित पुस्तकालयों लाना सिर्फ एक तरीका है जिसमें आप फ़ाइलों को प्राप्त कर सकते हैं की जरूरत है जो फ़ाइलें से संबंध में बाद में आने वाले चीजों की परिभाषा प्रदान परिभाषाएँ। ऑब्जेक्ट फाइल्स के सामने लाइब्रेरियों को रखना जो उन्हें संदर्भित करते हैं, वही गलती करने का एक और तरीका है।