आप पुस्तकालयों के स्थान को बाइनरी में कैसे निर्दिष्ट करते हैं? (लिनक्स)

34

इस प्रश्न के लिए मैं एक विशिष्ट उदाहरण का उपयोग करूंगा, लेकिन वास्तव में यह लिनक्स पर बहुत अधिक द्विआधारी को सामान्य करता है जो इसके 'आश्रित पुस्तकालयों' को खोजने के लिए प्रतीत नहीं हो सकता है। इसलिए, मेरे पास एक कार्यक्रम है जो लापता पुस्तकालयों के कारण नहीं चलेगा:

./cart5: error while loading shared libraries: libcorona-1.0.2.so: cannot open shared object file: No such file or directory

ldd इस मुद्दे पर कुछ प्रकाश डाला:

linux-vdso.so.1 =>  (0x00007fff18b01000)
libcorona-1.0.2.so => not found
libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/libstdc++.so.6 (0x00007f0975830000)
libm.so.6 => /lib/libm.so.6 (0x00007f09755af000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f0975399000)
libc.so.6 => /lib/libc.so.6 (0x00007f0975040000)
libz.so.1 => /lib/libz.so.1 (0x00007f0974e2b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0975b36000)

हालाँकि, कोरोना स्थापित है:

oliver@human$ find / -name libcorona-1.0.2.so 2> /dev/null

/usr/local/lib64/libcorona-1.0.2.so
/home/oliver/installed/corona-1.0.2/src/.libs/libcorona-1.0.2.so

मैं बाइनरी को कैसे बताता हूं कि "लापता" लाइब्रेरी की तलाश कहां है?

linux libraries

— माला
स्रोत

43

एक बार बंद होने के लिए, चर LD_LIBRARY_PATHको खोज के लिए निर्देशिकाओं की एक अलग-अलग सूची में सेट करें। यह PATHनिष्पादनयोग्य के लिए अनुरूप है , सिवाय इसके कि मानक प्रणाली निर्देशिकाओं को पर्यावरण के माध्यम से निर्दिष्ट के बाद अतिरिक्त रूप से खोजा जाता है।

LD_LIBRARY_PATH=/usr/local/lib64 ./cart5

यदि आपके पास एक प्रोग्राम है जो पुस्तकालयों को एक गैर-मानक स्थान पर रखता है और उन्हें अपने दम पर खोजने में सक्षम नहीं है, तो आप एक रैपर स्क्रिप्ट लिख सकते हैं:

#!/bin/sh
if [ -n "$LD_LIBRARY_PATH" ]; then
  LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib64
else
  LD_LIBRARY_PATH=/usr/local/lib64
fi
export LD_LIBRARY_PATH
exec /path/to/cart5 "$@"

मानक प्रणाली निर्देशिकाओं की सूची में रखा गया है /etc/ld.so.conf। हाल की प्रणालियाँ इस फ़ाइल को अन्य फ़ाइलों को शामिल करने की अनुमति देती हैं; यदि आपका कुछ ऐसा है include /etc/ld.so.conf.d/*.conf, तो एक नई फ़ाइल बनाएं, जिसे /etc/ld.so.conf.d/mala.confआप जोड़ना चाहते हैं। आपके द्वारा परिवर्तित /etc/ld.so.confया शामिल फ़ाइल के बाद, /sbin/ldconfigअपने परिवर्तनों को प्रभावी बनाने के लिए चलाएं (यह कैश अपडेट करता है)।

( LD_LIBRARY_PATHFreeBSD, NetBSD, OpenBSD, Solaris और Tru64 सहित कई अन्य यूनियनों पर भी लागू होता है। HP-UX के पास SHLIB_PATHऔर Mac OS X है DYLD_LIBRARY_PATH। /etc/ld.so.confअधिकांश यूनियनों पर एनालॉग हैं, लेकिन स्थान और सिंटैक्स अधिक व्यापक रूप से भिन्न हैं।)

— गिल्स 'SO- बुराई होना बंद करो'
स्रोत

1

शानदार, बहुत बहुत धन्यवाद। मुझे /etc/ld.so.conf के बारे में कोई जानकारी नहीं थी, और यह भविष्य में मेरे लिए बहुत उपयोगी होगा।

— माला

15

यदि आप LD_LIBRARY_PATH से बचना चाहते हैं, तो आप इसे लिंक करने के दौरान भी कर सकते हैं:

gcc -o exename -L/path/to/dynamiclib/ -lnameofLib \
    -Wl,-R/path/to/dynamiclib/ sourceCode1.c ...

-Wl, ... लिंकर को अतिरिक्त कमांड पास करने के लिए उपयोग किया जाता है, और इस स्थिति में, -R के साथ आप लिंकर को .so के लिए "डिफ़ॉल्ट खोज पथ" के रूप में इस पथ को संग्रहीत करने के लिए कहते हैं।

मैं अपनी साइट पर इस तरह कई छोटे सुझावों के नोट्स रखता हूं:

https://www.thanassis.space/tricks.html

— ttsiodras
स्रोत

लेकिन अगर पुस्तकालय में सवाल यह है कि पुस्तकालयों को देखने के लिए खुद को साझा किया है, तो द्विआधारी में संग्रहीत rpath को उप-पुस्तकालय लुकअप के लिए पुनरावर्ती रूप से लागू नहीं किया जाता है। मुझे वातावरण में LD_LIBRARY_PATH को सेट करने के अलावा इसके आस-पास कोई रास्ता नहीं मिला, जो फिर से पुनरावर्ती लुक अप्लाई करने के लिए मिलता है ...

— Ethan

@ ईथन: सच। लेकिन यह भी सच है कि सामान्य परिदृश्य जहां आप कुछ बाइनरी के लिए साझा पुस्तकालयों को "पैकेज" करना चाहते हैं, एक वह जगह है जहां आपने उन सभी को एक साथ रखा है; उदाहरण के लिए /opt/mypackage/bin/someBinaryआपको उन स्टोरों की आवश्यकता होगी, जिन्हें आप स्टोर करते हैं /opt/mypackage/lib/। बहुत अधिक सभी स्वामित्व वाली SW / ऑप्ट के तहत स्थापित किया गया नियम इस नियम का अनुसरण करता है - जिसका अर्थ है कि ऊपर दिखाया गया तरीका ऐसे सभी इंस्टॉल को कवर करेगा। इसके बाद वे आमतौर पर / usr / bin के नीचे एक सिमलिंक भी जोड़ते हैं जो बाइनरी के नीचे / ऑप्ट को इंगित करता है - यह जानकर कि "डिफ़ॉल्ट खोज पथ" .soउपयुक्त /opt/.../libफ़ोल्डर के तहत एस को ढूंढ लेगा ।

— ttsiodras

हाँ, मेरे मामले में मैं इसकी स्थापना निर्देशिका के खिलाफ इसे स्थापित करने के बजाय लिंक करके एक पैकेज का परीक्षण करना चाहता था ... (लेकिन पैकेज में कई आंतरिक थे। कुछ अंतर-निर्भरता के साथ। वर्कअराउंड की विविधता लेकिन सिर्फ कष्टप्रद)

— एथन

0

यह इंगित करता है कि लिबरकोरोना सही पथ में स्थापित नहीं है। Libcoreona निर्देशिका को सही पथ पर ले जाएँ, समस्या हल हो जाएगी ।।

— राठी
स्रोत

यह अन्य उत्तरों से बेहतर कैसे है?

— टोटो

@ अन्य उत्तरों के विपरीत, आप मूल रूप से फ़ाइलों को स्थापित कर रहे हैं ... हालांकि इसका मतलब यह नहीं है कि यह उत्तर बेहतर है, लेकिन यह एक विकल्प है जिस पर विचार किया जाना चाहिए (लोग इसे विंडोज में भी पुस्तकालयों की नकल करके करते हैं। system32 / sysWOW64 जब उनके ऐप उन्हें नहीं मिल सकते हैं), ऐसा नहीं है कि यह अनुशंसित है, क्योंकि यह दृढ़ता से हतोत्साहित है।

— टीसीएल