Rcutils: find_library: `LD_LIBRARY_PATH` खोजने के बजाय वर्तमान में लोड की गई लाइब्रेरी को प्राथमिकता दें

यहाँ लिनक्स पर एक कार्यशील प्रोटोटाइप है:
https://github.com/EricCousineau-TRI/rcpputils/commit/b66a3d9e02ace44e6c3b6022eeb3447b121d3311

ड्रेक स्रोत से पालना:
https://github.com/RobotLocomotion/drake/blob/4c6246197/common/find_loaded_library.cc

इस बाज़ल रेप्रो प्रोजेक्ट के लिए इस प्रतिबद्धता पर, मैं अब या तो लिंकिंग समय पर आरएमडब्ल्यू कार्यान्वयन निर्दिष्ट कर सकता हूं, या पर्यावरण चर को स्थगित कर सकता हूं:
https://github.com/EricCousineau-TRI/repro/commit/cea11026722b340580257564dc49cb0f59b55178

@ डिर्क-थॉमस मुझे यह बेहद उपयोगी लगेगा। क्या मैं पूछ सकता हूं कि क्या (यदि कोई हो) सबूत आपको इस पर विचार करने के लिए प्रेरित कर सकते हैं? :डी

क्या मैं पूछ सकता हूं कि क्या (यदि कोई हो) सबूत आपको इस पर विचार करने के लिए प्रेरित कर सकते हैं?

चूंकि डिस्ट्रो होने का लक्ष्य स्थिरता सुनिश्चित करना है बैकपोर्ट केवल बग फिक्स के लिए हैं। एन्हांसमेंट्स को अगले डिस्ट्रो को लक्षित करना चाहिए।

डैशिंग के पहले परीक्षण पैकेज अप्रैल के पहले सप्ताह में उपलब्ध होने का लक्ष्य रखा गया है।

ऐ, अच्छा लगता है। https://github.com/ros2/rcpputils/issues/3 के विलय का इंतजार करेंगे, और फिर इसे देव शाखा के खिलाफ दर्ज करेंगे। धन्यवाद!

हमारे पास एक ros2 नोड है जिसे setcap माध्यम से सेट की गई क्षमताओं की आवश्यकता होती है जो निष्पादन के दौरान LD_LIBRARY_PATH को छोड़ दिया जाता है। इसलिए हम साझा पुस्तकालयों को खोजने के लिए बाइनरी में RPATH सेट कर रहे हैं। हालांकि, चूंकि find_library_path LD_LIBRARY_PATH पर निर्भर करता है, नोड विफल रहता है

terminate called after throwing an instance of 'rclcpp::exceptions::RCLError'
  what():  failed to initialized rcl init options: failed to find shared library of rmw implementation. Searched rmw_fastrtps_cpp, at /tmp/binarydeb/ros-eloquent-rmw-implementation-0.8.2/src/functions.cpp:130, at /tmp/binarydeb/ros-eloquent-rcl-0.8.3/src/rcl/init_options.c:55

अगर मैं सही ढंग से समझूं, तो @EricCousineau-TRI के प्रस्ताव से इस समस्या का समाधान हो जाएगा। अगली रिलीज में इस कार्यक्षमता को पाने का कोई मौका? या कामकाज के लिए कोई सुझाव?

@ EricCousineau-TRI क्या आप इस पर पुनरावृति करने की योजना बना रहे हैं?

अगर मैं सही ढंग से समझूं, तो @EricCousineau-TRI के प्रस्ताव से इस समस्या का समाधान हो जाएगा।

@wieset यदि आप जिस पुस्तकालय को खोजने/लोड करने का प्रयास कर रहे हैं, वह पहले से लोड नहीं है, तो यह समस्या का समाधान कैसे करेगा?

@ivanpauno शायद निकट भविष्य में कभी भी नहीं (~ 6mo से 1yr), दुर्भाग्य से :(

@ डिर्क-थॉमस मैंने @ एरिककूसिनो-टीआरआई के उदाहरण कोड को देखा और आप सही हैं, अगर पुस्तकालय पहले से लोड नहीं हुआ है तो यह मेरी समस्या का समाधान नहीं करेगा। मुझे लगता है कि मैं इसे बिल्ड टाइम पर लिंक कर सकता हूं ताकि यह प्रोग्राम स्टार्टअप पर लोड हो जाए?

हालांकि, रन टाइम पर लोडिंग को संरक्षित करने के लिए, मुझे दो विकल्प दिखाई देते हैं: या तो RPATH खोजना होगा, जिसे मैं CMAKE_INSTALL_RPATH माध्यम से सेट कर सकता हूं, या LD_LIBRARY_PATH बजाय किसी अन्य पर्यावरण चर का उपयोग किया जा सकता है RMW_LIBRARY_PATH । मैंने उन दोनों विकल्पों का उल्लेख https://github.com/ros2/rcpputils/issues/40 में किया है।

@wieset इस उपयोग के मामले के लिए rpath का उपयोग करने के लिए अपने निर्माण को अनुकूलित करने का तरीका लगता है।

@ डिर्क-थॉमस सहमत हुए, और मैं पहले से ही अन्य सभी पुस्तकालयों को लोड करने के लिए RPATH का उपयोग कर रहा हूं। लेकिन यह मुझे इस तथ्य के आसपास नहीं मिलता है कि आरएमडब्ल्यू पुस्तकालय के लिए find_library_path() वर्तमान में वहां नहीं दिखता है। या क्या मैं कुछ न कुछ भूल रहा हूं?

लेकिन यह मुझे इस तथ्य के आसपास नहीं मिलता है कि आरटीडब्ल्यू पुस्तकालय के लिए find_library_path() वर्तमान में वहां नहीं दिखता है।

आप ठीक कह रहे हैं। मैं इस टिकट पर संदर्भ से चूक गया।

मुझे आश्चर्य है कि क्या इसके लिए एक अलग पर्यावरण चर पेश करना समझ में आता है या यदि आपको मौजूदा पर्यावरण चर को स्पष्ट रूप से सेट करने के लिए निष्पादन योग्य को रूट के रूप में चलाते समय सुनिश्चित करना चाहिए।

जहां तक ​​​​मैं समझता हूं, LD_LIBRARY_PATH को setcap / setuid निष्पादन योग्य के लिए पूरी तरह से अनदेखा कर दिया गया है, इसलिए इसे स्वयं सेट करना दुर्भाग्य से मदद नहीं करेगा। देखें http://man7.org/linux/man-pages/man8/ld.so.8.html

सुनिश्चित नहीं है कि सुरक्षा सीमा को बायपास करने के लिए ROS_LIBRARY_PATH जैसे नए env var को पेश करना एक अच्छा विचार है। ld केवल इसे फ़िल्टर नहीं करेगा क्योंकि यह इसके बारे में नहीं जानता है और यह सुरक्षा कारणों से LD_LIBRARY_PATH को अनदेखा करता है।

कृपया इस वृद्धि को जोड़ने के लिए पीआर का प्रस्ताव करने के लिए स्वतंत्र महसूस करें (जैसा कि "सहायता चाहता है" लेबल द्वारा इंगित किया गया है)।

इस पर गौर करेंगे!

https://github.com/ros2/rcpputils/pull/44 . पर एक पुल अनुरोध बनाया गया

FWIW @hidmic , @iantheengineer , और मैं टीआरआई में अन्य लोगों के साथ इस पर चर्चा करना शुरू कर रहा हूं। पहले हमारे आंतरिक उपयोग की ओर, फिर ड्रेक जैसी चीजों के साथ एकीकरण की ओर।

हम्म, मुझे आश्चर्य हो रहा है कि हमें शुरुआत करने के लिए rcpputils::find_library_path() आवश्यकता क्यों है। यदि हम केवल rcutils_load_shared_library() या इसके rcpputils::SharedLibrary रैपर को एक सापेक्ष पथ के साथ प्रदान करते हैं, तो dlopen और LoadLibrary पथ खोजेंगे और लोड ऑब्जेक्ट फ़ाइलों को प्राप्त करेंगे। दोनों के लिए दस्तावेज़ीकरण से पता चलता है कि पहले से लोड की गई ऑब्जेक्ट फ़ाइलों को फिर से नहीं खींचा जाएगा। ऐसा करने से, डिफ़ॉल्ट रूप से RPATHs, LD_LIBRARY_PATHs, RUNPATHs, PATHs और प्रीलोडेड लाइब्रेरी को सम्मानित किया जाएगा।

सीसी @EricCousineau-TRI @wieset @clalancette।

ठीक है, इस पर पहली बार हमला करने के लिए #320 और कनेक्टेड पीआर देखें। @wieset इसे (अप्रत्यक्ष रूप से) आपके मुद्दों को भी हल करना चाहिए। हालांकि ये परिवर्तन rcpputils::find_library_path अप्रचलित हैं (कोर पैकेज में उपयोग के लिए)।

@hidmic अब जबकि हम #320 पर पहुंच गए हैं और दोस्तों, क्या हम इसे बंद कर सकते हैं?

वास्तव में हम कर सकते हैं। टक्कर के लिए धन्यवाद!

बहुत बहुत धन्यवाद @hidmic , मुझे लगता है कि यह मुझे वहां आधा कर देता है। RUNPATH अभी भी ठीक से भरने की जरूरत है। मैं https://github.com/ros2/rcpputils/pull/44 में @clalancet के साथ चर्चा जारी ।