2012-06-22 16 views
10

क्यों glibc और pthread लाइब्रेरी दोनों एक ही एपीआई परिभाषित किया? यहाँ स्नैपशॉटक्यों glibc और pthread लाइब्रेरी दोनों एक ही एपीआई परिभाषित किया?

[email protected]:/lib$ objdump -T /lib/i386-linux-gnu/libc.so.6 |grep pthread_cond_signal 
000f8360 g DF .text 00000039 GLIBC_2.3.2 pthread_cond_signal 
0012b940 g DF .text 00000039 (GLIBC_2.0) pthread_cond_signal 

[email protected]:/lib$ objdump -T /lib/i386-linux-gnu/libpthread.so.0 |grep pthread_cond_signal 
0000b350 g DF .text 0000007c (GLIBC_2.0) pthread_cond_signal 
0000af90 g DF .text 000000fc GLIBC_2.3.2 pthread_cond_signal 

उत्तर

10

libpthread.so भी glibc का एक हिस्सा है, और वे दोनों (समान) कुछ प्रतीकों की परिभाषा होते हैं।

आप pthread_create के लिए देखो, तो इसके बजाय आप देखेंगे कि यह libpthread.so में ही मौजूद है - इसका मतलब कार्यक्रमों वास्तव में धागे बनाने के लिए libpthread.so से लिंक करना होगा, लेकिन यह केवल कड़ी एकल पिरोया कार्यक्रमों में mutexes और हालत चर का उपयोग कर सकते हैं libc.so पर। यह इंटरप्रोसेस म्यूटेक्स और इंटरप्रोसेस हालत चर के लिए उपयोगी है जो साझा स्मृति में रहते हैं और अलग प्रक्रियाओं के साथ सिंक्रनाइज़ करने के लिए उपयोग किए जाते हैं। (नीचे झैन लिंक्स की टिप्पणी के लिए सुधार धन्यवाद)।

libpthread.so और libc.so दोनों से लिंक करने में कोई समस्या नहीं है, भले ही वे दोनों प्रतीक को परिभाषित करते हैं। ईएलएफ लिंकर्स कई साझा पुस्तकालयों को एक ही प्रतीक की परिभाषाओं को शामिल करने की अनुमति देता है और लिंकर इसे देखे जाने वाले पहले व्यक्ति को चुनता है और उस प्रतीक के सभी संदर्भों के लिए इसका उपयोग करता है, इसे symbol interposition कहा जाता है। एक और विशेषता जो कई प्रतीकों को परिभाषित करने की अनुमति देती है, यदि एक पुस्तकालय में weak symbols है जो समान नाम वाले गैर-कमजोर प्रतीकों से अधिक हो जाएगा। इस मामले में में परिभाषाएं दो पुस्तकालय समान हैं, इसलिए इससे कोई फर्क नहीं पड़ता कि libpthread.solibc.so में उन लोगों को ओवरराइड करता है। आप LD_DEBUG का उपयोग करें और लिंकर पर तर्कों की क्रम बदलते हैं तो आपको प्रतीक वास्तव में में पाया जाता है जो पुस्तकालय को देखने के लिए सक्षम होना चाहिए।

साथ ही एक ही प्रतीक को परिभाषित दो पुस्तकालयों, प्रत्येक पुस्तकालय दो परिभाषाएं हैं प्रतीक के साथ, विभिन्न symbol versions, GLIBC_2.0 और GLIBC_2.3.2 के साथ। यह प्रतीक संस्करण एक ही लाइब्रेरी में कई परिभाषाओं को सह-अस्तित्व में रखने की अनुमति देता है ताकि पुराने कार्यान्वयन के विरुद्ध जुड़े कोड को तोड़ने के बिना लाइब्रेरी में फ़ंक्शन के नए, बेहतर संस्करण जोड़े जाए। यह समान साझा लाइब्रेरी को एनपीटीएल का उपयोग कर लिनक्स थ्रेड और एप्लिकेशन का उपयोग कर अनुप्रयोगों के लिए काम करने की अनुमति देता है। लाइब्रेरी से लिंक करते समय संदर्भ को संदर्भित करने वाला डिफ़ॉल्ट प्रतीक [email protected]_2.3.2 है जो कि उस फ़ंक्शन के NPTL कार्यान्वयन से संबंधित है (एनपीटीएल पहली बार glibc 2.3.2 में शामिल था)। पुराना प्रतीक, [email protected]_2.0, पुराना लिनक्स थ्रेड कार्यान्वयन है जो एनपीटीएल प्रदान किए जाने से पहले डिफ़ॉल्ट था। ग्लिब के पुराने (प्री-2.3.2) संस्करणों के खिलाफ जुड़े अनुप्रयोग [email protected]_2.0 से बंधे होंगे और उस प्रतीक का उपयोग करेंगे।

+0

आप सही हैं, pthread_create libc.so.6 में परिभाषित नहीं है। लेकिन लिंकिंग करते समय हमें pthread_cond_signal के लिए एकाधिक परिभाषा त्रुटि क्यों नहीं मिलती है? –

+0

उत्तर _symbol interposition_ –

+7

का वर्णन करने के लिए अद्यतन किया गया मुझे विश्वास नहीं है कि यह उत्तर पूरी तरह से सही है। ग्लिब में परिभाषा केवल प्लेसहोल्डर हैं और केवल पैथ्रेड ऑपरेशंस के लिए केवल कुछ भी नहीं-कुछ परिभाषाएं हैं। Libpthread.so में परिभाषा इन ओवरराइड। यह पुस्तकालयों द्वारा उपयोग के लिए है जो एकल-थ्रेडेड में तेजी से होना चाहते हैं लेकिन बहुप्रचारित कार्यक्रमों में थ्रेड-सुरक्षित होना चाहते हैं। –