होम डायरेक्टरी में स्थानीय रूप से लाइब्रेरी स्थापित करना, लेकिन प्रोग्राम इसे मान्यता नहीं देता है


10

मैं एक सर्वर पर एक गैर-रूट उपयोगकर्ता के रूप में एक प्रोग्राम स्थापित कर रहा हूं। विशेष रूप से यह 1.5 tmux है, लेकिन यह मेरे विचार में सभी स्थानीय रूप से स्थापित प्रोग्राम के लिए व्यापक रूप से लागू होना चाहिए (यदि यह समस्या मेरे खुद के त्रुटि नहीं होने की स्थिति में प्रोग्राम के नाम का उल्लेख करता हूं)।

कार्यक्रम के लिए मुझे कुछ आश्रित पुस्तकालयों (जैसे libevent और ncurses) को स्थापित करने की आवश्यकता होती है। इसलिए, मैंने उन दोनों को स्थानीय रूप से स्थापित किया क्योंकि मेरे पास रूट एक्सेस नहीं है

cd $HOME/library/installation/folder
DIR=$HOME/local
./configure --prefix=$DIR 
#... make ... make install 

अब, प्रोग्राम को स्थापित करने के लिए, मुझे लाइब्रेरी पैकेज को भी शामिल करना पड़ा:

cd $HOME/program/installation/folder
./configure --prefix=$DIR CFLAGS="-I$DIR/include" LDFLAGS="-L$DIR/lib"
#... make ... make install 

ठीक है, इसलिए यह बिना किसी समस्या के $ HOME / लोकल / बिन में प्रोग्राम इंस्टॉल करता है, लेकिन अगर मैं निष्पादन योग्य चलाता हूं: $ HOME / लोकल / बिन / tmux, तो मुझे निम्न त्रुटि मिलती है:

tmux: साझा पुस्तकालयों को लोड करते समय त्रुटि: libevent-2.0.so.5: साझा की गई ऑब्जेक्ट फ़ाइल नहीं खोल सकते: ऐसी कोई फ़ाइल या निर्देशिका नहीं

यह मुझे प्रतीत होता है कि कार्यक्रम वांछित पुस्तकालयों को नहीं ढूंढ सकता है, लेकिन फ़ाइल libevent-2.0.so.5 वास्तव में $ HOME / स्थानीय / lib में मौजूद है जैसा कि कॉन्फ़िगर विकल्पों में निर्दिष्ट है। मैं सोच रहा हूं कि कैसे मैं प्रोग्राम को चलाने के लिए स्थापित लाइब्रेरी को पहचान सकता हूं। मैंने $ HOME / lib, $ HOME / bin और $ HOME / local / bin में प्रतीकात्मक लिंक डालने की कोशिश की, लेकिन इनमें से किसी ने भी काम नहीं किया। किसी भी विचार और सुझाव बहुत सराहना की जाएगी


मेरा मानना -R $DIR/libहै CFLAGSकि निर्माण के दौरान tmux(और नहीं libevent)। इसने मेरी मदद नहीं की - यह कहकर कि इसे पहचाना नहीं जा सकता -R(यह भी, बीच बीच में बिना कोशिश किए ) -Rऔर वहाँ से कुछ अंतिम त्रुटि आई $DIR। ./configure --disable- शेयर्ड यह काम किया, यह LD_LIBRARY_PATHभी अद्यतन काम किया। मैंने libeventउपरोक्त --disable-sharedविकल्प के साथ फिर से बनाना शुरू किया ।

जवाबों:


20

उपयोग करके पुनः निर्माण का प्रयास करें

./configure --disable-shared

मुझे संदेह है कि यह आपकी समस्या को ठीक करेगा क्योंकि पुस्तकालय बाइनरी के निर्माण के खिलाफ जुड़ा होगा और रनटाइम के लिए खोज करने की आवश्यकता नहीं है।

वैकल्पिक रूप से, यदि आपको एक गतिशील रूप से लिंक किए गए लिबवेंट की आवश्यकता है, तो आप अपने LD_LIBRARY_PATH पर्यावरण चर में libevent-2.0.so.5 की युक्त निर्देशिका को जोड़ सकते हैं:

export LD_LIBRARY_PATH=${HOME}/local/lib/:${LD_LIBRARY_PATH}

वाह, त्वरित उत्तर के लिए बहुत बहुत धन्यवाद। मैंने समस्या को ठीक करने के लिए LD_LIBRARY_PATH का उपयोग किया, क्योंकि मैं इस फिक्स को किसी भी भविष्य के लाइब्रेरी इंस्टॉलेशन पर लागू कर सकता हूं और हमेशा $ HOME / स्थानीय निर्देशिका का उपयोग कर सकता हूं। मदद की सराहना!
स्काइकुलरेटर


2

दूसरों के साथ कोई भाग्य नहीं है, लेकिन यह मेरे लिए यहाँ से काम किया है :

sudo ln -s /usr/local/lib/libevent-2.0.so.5 /usr/lib64/libevent-2.0.so.5

2

मैंने एक समान प्रश्न पूछा है , दिलचस्प रूप tmuxसे सभी चीजों के निर्माण के बारे में भी पर्याप्त है (हालांकि मैं अभी भी निश्चित हूं कि यह किसी भी स्थिति के बारे में है जहां जीएनयू configureऔर makeएक साथ उपयोग किया जाता है।

मेरा मानना ​​है कि एक क्लीनर दृष्टिकोण तथाकथित "rpath" का उपयोग करना है - पुस्तकालय खोज पथ बाइनरी में एम्बेडेड है। -rpathकम से कम GNU लिंकर का स्विच ldपथ निर्दिष्ट करता है।

निर्माण कमांड लाइन तब निम्नानुसार दिखाई देगी:

PKG_CONFIG_PATH=/path/to/libevent/lib/pkg-config LDFLAGS=-Wl,-rpath,/path/to/libevent/lib ./configure ...

यहां वास्तव में सर्वोपरि नहीं है, लेकिन PKG_CONFIG_PATHऊपर केवल यह करने के लिए अनुशंसित तरीका है कि लोग अन्यथा स्क्रिप्ट -L/path/to/libevent/lib -I/path/to/libevent/includeको मैन्युअल रूप से भेजते हैं ./configure। जब आप निर्माण करते हैं libevent, तो यह अपनी कॉन्फ़िगरेशन फ़ाइलों को स्थापित करता है pkg-config(जिसके लिए उपयोग किया जाता है ./configure)। आपको इसका उपयोग करना चाहिए, क्योंकि केवल libevent निश्चित रूप से जानता है कि इसके खिलाफ निर्माण करते समय स्विच का क्या उपयोग किया जाना चाहिए।

वैसे भी, कुछ स्थितियों में, -rpathसमस्या को हल करने के लिए एक क्लीनर दृष्टिकोण है।

LD_LIBRARY_PATH-बेड सॉल्यूशन, हालांकि, आपको रनटाइम पर आपके द्वारा बनाए गए बाइनरी द्वारा उपयोग किए जाने वाले लाइब्रेरी को टकराने की अनुमति देता है, जो कभी-कभी वांछनीय होता है। लेकिन अगर आप सिर्फ अपने घर के फ़ोल्डर में एक समर्पित जगह पर रखे गए किसी विशेष पुस्तकालय के खिलाफ निर्माण करना चाहते हैं, तो मुझे लगता है कि -rpathसमाधान के लिए एक विहित जवाब के रूप में माना जाता है।

अजीब बात यह है tmuxकि निर्माण के दौरान पुस्तकालय निर्माण पथ से इस मार्ग का निर्माण नहीं हुआ है। शायद उन्हें जरूरत है और नहीं, मुझे नहीं पता। क्या यह हमारे लिए एक संयोग है जो निर्माण हुआ है tmux?

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.