क्यों वहाँ `/ lib` और` / lib64` लेकिन केवल `/ बिन` हैं?

Question

मेरे लैपटॉप में:

$ cat /etc/issue  
Ubuntu 18.04 LTS \n \l

पुस्तकालयों के लिए दो अलग-अलग फ़ोल्डर हैं x86और x86_64:

~$ ls -1 /  
bin
lib
lib64
sbin
...

बायनेरिज़ के लिए केवल एक निर्देशिका क्यों मौजूद है?

PS मुझे एंड्रॉइड में भी दिलचस्पी है लेकिन मुझे उम्मीद है कि उत्तर समान होना चाहिए।

Comments

केवल एक में? मैं वहां /binऔर /sbinवहां दोनों देखता हूं । प्रश्न क्या है? क्या आप /libऔर के बीच अंतर के बारे में पूछ रहे हैं /lib64?

— Kusalananda

@ कुसलानंद, मेरा मतलब है कि इसके लिए कोई स्वतंत्र फ़ोल्डर नहीं है x86_64(न ही /binबिना किसी के लिए /sbin)।

— 20

आईएमओ ओपी जानना चाहता है कि क्यों नहीं है /bin64।

— अर्कादियुस डेर्ब्स्की

लगभग एक अनुप्रयोग जो 32-बिट और 64-बिट दोनों संस्करणों (WINE) से लाभान्वित होता है, इसके चारों ओर अलग-अलग नाम वाले बायनेरिज़ ( wine*32और wine*64) होते हैं।

— इग्नासियो वाज़केज़-अब्राम्स

@ इग्नासियोवेज़ज़-एब्राम्स: यह भी कहा जाना चाहिए कि आप बायनेरिज़ को पुस्तकालयों से जोड़ते हैं, इसके विपरीत नहीं। तो बायनेरिज़ को 32/64-बिटनेस द्वारा विभाजित होने की आवश्यकता नहीं है।

— एसएमसीआई

Answer 1

सबसे पहले, अलग क्यों हैं /libऔर /lib64:

फ़ाइल-सिस्टम अनुक्रम स्टैंडर्ड कहा गया है कि अलग /libऔर /lib64अस्तित्व है क्योंकि:

10.1। ऐसे सिस्टम पर एक / एक से अधिक संस्करण हो सकते हैं, जो अलग-अलग पुस्तकालयों की आवश्यकता वाले एक से अधिक द्विआधारी प्रारूप का समर्थन करते हैं। (...) यह आमतौर पर 64-बिट या 32-बिट सिस्टम के लिए उपयोग किया जाता है जो कई बाइनरी प्रारूपों का समर्थन करता है, लेकिन एक ही नाम के पुस्तकालयों की आवश्यकता होती है। इस मामले में, / lib32 और / lib64 लाइब्रेरी निर्देशिका हो सकते हैं, और / / उनमें से एक के लिए सहानुभूति का परिवाद कर सकते हैं।

मेरी स्लैकवेयर 14.2 पर उदाहरण के लिए देखते हैं /libऔर /lib64 32-बिट और 64-बिट पुस्तकालयों के लिए निर्देशिका क्रमशः भले ही /libएक सिमलिंक के रूप में के रूप में FHS झलकी सुझाव है कि नहीं है:

$ ls -l /lib/libc.so.6
lrwxrwxrwx 1 root root 12 Aug 11  2016 /lib/libc.so.6 -> libc-2.23.so
$ ls -l /lib64/libc.so.6
lrwxrwxrwx 1 root root 12 Aug 11  2016 /lib64/libc.so.6 -> libc-2.23.so

libc.so.6में /libऔर दो पुस्तकालय हैं /lib64।

प्रत्येक गतिशील बनाया ELF बाइनरी इस मामले या तो में, दुभाषिया के लिए एक हार्डकोडेड पथ है /lib/ld-linux.so.2या /lib64/ld-linux-x86-64.so.2:

$ file main
main: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, not stripped
$ readelf  -a main  | grep 'Requesting program interpreter'
      [Requesting program interpreter: /lib/ld-linux.so.2]

$ file ./main64
./main64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not stripped
$ readelf  -a main64  | grep 'Requesting program interpreter'
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

दुभाषिया का काम आवश्यक साझा पुस्तकालयों को लोड करना है। आप एक GNU दुभाषिया से पूछ सकते हैं कि एक लायब्रेरी का उपयोग करके LD_TRACE_LOADED_OBJECTS=1या एक lddआवरण के बिना भी किन पुस्तकालयों को लोड किया जाएगा :

$ LD_TRACE_LOADED_OBJECTS=1 ./main
        linux-gate.so.1 (0xf77a9000)
        libc.so.6 => /lib/libc.so.6 (0xf760e000)
        /lib/ld-linux.so.2 (0xf77aa000)
$ LD_TRACE_LOADED_OBJECTS=1 ./main64
        linux-vdso.so.1 (0x00007ffd535b3000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f56830b3000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f568347c000)

जैसा कि आप देख सकते हैं कि एक दिया गया दुभाषिया बिल्कुल जानता है कि पुस्तकालयों की तलाश कहाँ है - 32-बिट संस्करण पुस्तकालयों के लिए दिखता है /libऔर 64-बिट संस्करण पुस्तकालयों के लिए दिखता है /lib64।

FHS मानक निम्नलिखित के बारे में कहता है /bin:

/ बिन में ऐसे कमांड होते हैं जिनका उपयोग सिस्टम एडमिनिस्ट्रेटर और यूजर्स दोनों के द्वारा किया जा सकता है, लेकिन जब किसी अन्य फाइल सिस्टम को माउंट नहीं किया जाता है (जैसे सिंगल यूजर मोड में)। इसमें ऐसे कमांड भी हो सकते हैं जो स्क्रिप्ट द्वारा अप्रत्यक्ष रूप से उपयोग किए जाते हैं।

IMO कारण है कि कोई अलग नहीं है /binऔर /bin64यह है कि अगर हमारे पास इन दोनों निर्देशिकाओं में एक ही नाम वाली फ़ाइल है, तो हम अप्रत्यक्ष रूप से उनमें से एक को नहीं बुला सकते हैं क्योंकि हमें पहले /binया अंदर डालना होगा ।/bin64$PATH

हालांकि, ध्यान दें कि उपरोक्त सिर्फ सम्मेलन है - लिनक्स कर्नेल वास्तव में परवाह नहीं करता है यदि आपके पास अलग है /binऔर /bin64। यदि आप उन्हें चाहते हैं, तो आप उन्हें बना सकते हैं और उसी के अनुसार अपना सिस्टम सेटअप कर सकते हैं।

आपने एंड्रॉइड का भी उल्लेख किया - ध्यान दें कि एक संशोधित लिनक्स कर्नेल को चलाने के अलावा इसका GNU सिस्टम जैसे Ubuntu से कोई लेना-देना नहीं है - कोई ग्लिबक, कोई बैश (डिफ़ॉल्ट रूप से, आप निश्चित रूप से इसे मैन्युअल रूप से संकलित और तैनात कर सकते हैं), और निर्देशिका संरचना भी पूरी तरह से अलग है।

Comments

आपके ls -lउदाहरण विशेष रूप से जर्मन नहीं हैं। क्या उपयोगी होगा , का आउटपुट है ls -l /lib /lib64, जो संभवतः दिखाता है कि /libस्वयं एक सिम्लिंक है।

— चिरलीस-स्ट्राइक-

आप का मतलब है ls -ld, और नहीं, /libमेरे Slackware 14.2सिस्टम पर कोई सहानुभूति नहीं है।

— अर्कादियुस ड्राज्स्की

पुस्तकालयों में अलग-अलग md5sums हैं: dfd029d25c58831bc5db671aec99a36f /lib64/libc.so.6, 987e7b736f316cc8da87ca2f38dae93e /lib/libc.so.6।

— अर्कादिअस डेर्स्कज़ी

उस स्थिति में, सह-निर्देशिका को निर्देशिका में दिखाना प्रशस्ति पत्र से नहीं जुड़ता है।

— क्राइसिस -ऑन स्ट्राइक-

LD_TRACE_LOADED_OBJECTS = 1 सुरक्षा छेद के कारण अप्रचलित है और ldd अब इसका उपयोग नहीं करता है। कारण: ldd / path / to / malicious-static- बाइनरी का उपयोग सिस्टम को संभालने के लिए किया गया था क्योंकि sysadmins केवल ldd की उम्मीद कर रहे थे कि बाइनरी इसे न देखें। इसके अलावा, स्थिर या नहीं के लिए जाँच अपर्याप्त है क्योंकि बाइनरी का उपयोग दुर्भावनापूर्ण लोडर का उपयोग करने के लिए किया जा सकता है।

— जोशुआ

Answer 2

इसका कारण यह है कि lib / lib64 निर्देशिकाओं में वे फाइलें हो सकती हैं जिनमें समान नाम हो क्योंकि वे विभिन्न कार्यक्रमों के साथ साझा की गई लाइब्रेरी हैं। उन्हें अलग-अलग निर्देशिकाओं में रखकर संघर्ष को हल करता है। वहाँ (आम तौर पर ...) उसी सिस्टम पर समान-नाम वाले निष्पादकों को वितरित करने का कोई अच्छा कारण नहीं है जो 32/64-बिट हैं, लेकिन चूंकि निष्पादनयोग्य का मिश्रण हो सकता है, इसलिए साझा पुस्तकालयों के लिए प्रदान किया जाना है।