किसी प्रोग्राम को बनाने के बाद साझा लाइब्रेरी के फ़ाइल नाम को मैं कैसे बदल सकता हूं?

Question

मेरे पास एक ऐसा प्रोग्राम है जो साझा लाइब्रेरी पर निर्भर करता है, यह निर्देशिका संरचना के अंदर गहराई से खोजने की अपेक्षा करता है। मैं उस साझा लाइब्रेरी को बाहर और बेहतर स्थान पर ले जाना चाहता हूं। ओएस एक्स पर, यह install_name_tool के साथ किया जा सकता है। मैं लिनक्स के बराबर नहीं ढूंढ पा रहा हूं।

संदर्भ के लिए, readelf -d myprogram निम्नलिखित दूसरे शब्दों में बयान उत्पादन बाहर थूक:

Dynamic section at offset 0x1e9ed4 contains 30 entries: 
    Tag  Type       Name/Value 
0x00000001 (NEEDED)      Shared library: [this/is/terrible/library.so] 
0x00000001 (NEEDED)      Shared library: [libGL.so.1] 
0x00000001 (NEEDED)      Shared library: [libGLU.so.1] 
0x00000001 (NEEDED)      Shared library: [libstdc++.so.6] 
(continues in an uninteresting fashion) 

(और अनुरोध के द्वारा, ldd myprogram :)

linux-gate.so.1 => (0x0056a000) 
    this/is/terrible/library.so => not found 
    libGL.so.1 => /usr/lib/mesa/libGL.so.1 (0x0017d000) 
    libGLU.so.1 => /usr/lib/libGLU.so.1 (0x00a9c000) 
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00710000) 
    (etc, etc) 

और मैं शुद्धिपत्र करने के लिए "चाहते हैं यह/है/भयानक/लाइब्रेरी.सो "साझा"/पुस्तकालय.सो "होना"। ध्यान दें कि, यदि प्रोग्राम अपने "निर्मित" स्थान में छोड़ा गया है, जहां सापेक्ष पथ यह// भयानक/लाइब्रेरी है। वास्तव में मौजूद है, तो ldd इसे ढूंढने में सक्षम है, जैसा कि आप उम्मीद करेंगे।

मुझे RPATH के बारे में पता है और यह वह नहीं है जिसे मैं ढूंढ रहा हूं, मुझे वैश्विक स्तर पर खोज पथ बदलने की आवश्यकता नहीं है।

Answer 1

HT - यह सहायक हो सकता है।

एचटी एक्जिक्यूटिव के लिए एक फ़ाइल संपादक/दर्शक/विश्लेषक है। लक्ष्य डीबगर की निम्न-स्तरीय कार्यक्षमता और आईडीई की प्रयोज्यता को जोड़ना है। हम सभी (हेक्स-) संपादन सुविधाओं और सबसे महत्वपूर्ण फ़ाइल प्रारूपों के समर्थन को लागू करने की योजना बना रहे हैं।

मुझे ज़ोरबाथट के समाधान से कुछ अलग नहीं मिला, लेकिन शायद अलग-अलग लंबाई के साथ एक नाम रखना संभव है और अभी भी बाइनरी वैध रखें।

gelf - यह भी उपयोगी हो सकता है।

जीईएलएफ मैनिपुलेट के लिए एक सामान्य, ईएलएफ कक्षा-स्वतंत्र एपीआई है- ईएलएफ ऑब्जेक्ट फाइलों में आईएनजी। जीईएलएफ 32-बिट और 64-बिट ईएलएफ प्रारूप ऑब्जेक्ट फ़ाइलों को संभालने के लिए एक एकल, सामान्य अंतर- चेहरा प्रदान करता है।

Answer 2

आप साझा पुस्तकालयों के लिए खोज पथ बदलने के लिए LD_LIBRARY_PATH का उपयोग कर सकते हैं। यदि आपका प्रोग्राम आपके उदाहरण शो जैसे किसी विशेष सापेक्ष पथ पर निर्भर करता है, तो आपको अभी भी उस निर्देशिका संरचना की आवश्यकता होगी। दूसरे शब्दों में आप आप अपने कार्यक्रम के पुनर्निर्माण कर सकते हैं /home/user/dev/project/this/is/terrible/library.so से /usr/local/lib/this/is/terrible/library.so लेकिन नहीं करने के लिए /usr/local/lib/library.so

को lib स्थानांतरित कर सकते हैं, तो सापेक्ष पथ यह lib के लिए उपयोग करता है बदल सकते हैं।

http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

Answer 3

पर लिनक्स में साझा libs पर कुछ अधिक जानकारी पोस्ट कर रहा है एक अस्थायी, भयानक, hacky समाधान नहीं है।

लाइब्रेरी निर्भरताओं को ईएलएफ ब्लॉक में संग्रहीत किया जाता है जिसे डीपेंड ब्लॉक कहा जाता है। उस ब्लॉक का प्रारूप पहचानकर्ता/स्ट्रिंगपोइंटर जोड़े की एक बड़ी सरणी है, जिसमें स्ट्रिंगपोइंटर बाइनरी में स्थित मानक सी नल-टर्मिनेटेड स्ट्रिंग को इंगित करता है।

आप देखते हैं कि यह कहां जा रहा है, है ना?

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

ईएलएफ में चेकसम शामिल है, लेकिन जाहिर है कि कोई लोडर नहीं है जो वास्तव में इसे सत्यापित करता है, इसलिए यह "सुरक्षित" है - यद्यपि गन्दा - अनदेखा करना।

"असली समाधान" एक उपयोगिता होगी जो ईएलएफ संरचना के निम्न स्तर के सामान्यीकृत हेरफेर की अनुमति देगी। जैसा कि मैं कह सकता हूं, कुछ विशेष मामलों को छोड़कर किसी भी चीज के लिए ऐसी कोई उपयोगिता मौजूद नहीं है (आरपीएटीएच, ज्यादातर।) मुझे यह जानने का नाटक नहीं है कि ऐसी उपयोगिता कितनी मुश्किल होगी।

मुझे बिल्कुल इसका बेहतर समाधान पसंद आएगा, लेकिन अब तक, यह काम प्रतीत होता है।

Answer 4

हम उपयोग कर सकते हैं patchelf:

patchelf --replace-needed liboriginal.so.1 libreplacement.so.1 my-program 

हम भी निर्भरता निकाल सकते हैं:

patchelf --remove-needed libfoo.so.1 my-program 

निर्भरता जोड़ें:

patchelf --add-needed libfoo.so.1 my-program 

या जहां खोज करने के लिए पथ बदल पुस्तकालयों के लिए (rpath):

patchelf --set-rpath /path/to/lib:/other/path my-program