في الوقت الحالي ، يسقط find_library
مباشرة في مكتبات البحث على طول LD_LIBRARY_PATH
، بدلاً من الاستعلام أولاً عن المكتبات المحملة. أحد التطبيقات الثلاثة الحالية:
https://github.com/ros2/rmw_implementation/blob/32c3de1/rmw_implementation/src/functions.cpp#L77
سيكون من الجيد أن يفضل هذا الرمز بدلاً من ذلك المكتبات المحملة حاليًا ، لدعم رمز التطبيق الذي لا يريد القدرة على تبديل تطبيقات DDS (على سبيل المثال ، تبسيط حالات repro ، وما إلى ذلك) في وقت التشغيل ، وبدلاً من ذلك ، يربط RPATH المكتبات المناسبة.
إليك نموذج أولي عملي على Linux:
https://github.com/EricCousineau-TRI/rcpputils/commit/b66a3d9e02ace44e6c3b6022eeb3447b121d3311
Cribbing من مصدر Drake:
https://github.com/RobotLocomotion/drake/blob/4c6246197/common/find_loaded_library.cc
في هذا الالتزام لمشروع Bazel repro هذا ، يمكنني الآن إما تحديد تنفيذ RMW عند ربط الوقت ، أو التأجيل لمتغيرات البيئة:
https://github.com/EricCousineau-TRI/repro/commit/cea11026722b340580257564dc49cb0f59b55178
@ ديرك - توماس أجد هذا مفيدًا للغاية . هل يمكنني أن أسأل ما هو الدليل (إن وجد) الذي قد يحثك على التفكير في ذلك؟ :د
هل يمكنني أن أسأل ما هو الدليل (إن وجد) الذي قد يحثك على التفكير في ذلك؟
نظرًا لأن الهدف من الحصول على توزيعة هو التأكد من أن الإطارات الخلفية للاستقرار مخصصة لإصلاحات الأخطاء فقط. يجب أن تستهدف التحسينات التوزيعات التالية.
من المقرر أن تكون حزم الاختبار الأولى من Dashing متاحة في الأسبوع الأول من أبريل.
حسنًا ، يبدو جيدًا. سوف ننتظر دمج https://github.com/ros2/rcpputils/issues/3 ، ثم قم بتقديم هذا ضد فرع dev. شكرا!
لدينا عقدة 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 ربما ليس في أي وقت في المستقبل القريب (حوالي 6 شهور إلى عام واحد) ، للأسف :(
@ dirk-thomas لقد بحثت في مثال كود @ EricCousineau-TRI وأنت محق ، فلن يحل مشكلتي إذا لم يتم تحميل المكتبة بالفعل. أعتقد أنه يمكنني ربطه في وقت الإنشاء بحيث يتم تحميله عند بدء تشغيل البرنامج؟
ومع ذلك ، للحفاظ على التحميل في وقت التشغيل ، أرى خيارين: إما أن يتم البحث عن RPATH
، والذي يمكنني تعيينه من خلال CMAKE_INSTALL_RPATH
، أو يمكن استخدام متغير بيئة آخر بدلاً من LD_LIBRARY_PATH
، على سبيل المثال RMW_LIBRARY_PATH
. لقد ذكرت كلا الخيارين في https://github.com/ros2/rcpputils/issues/40.
wieset يبدو أن تخصيص جهازك لاستخدام rpath لحالة الاستخدام هذه هو السبيل للذهاب.
@ dirk-thomas موافق ، وأنا أستخدم بالفعل RPATH
لتحميل جميع المكتبات الأخرى. لكن هذا لا يجعلني أتفهم حقيقة أن find_library_path()
لمكتبة rmw حاليًا لا يبدو هناك. أم هل فاتني شيء؟
لكن هذا لا يجعلني أتفهم حقيقة أن
find_library_path()
لمكتبة rtw حاليًا لا تبدو هناك.
أنت على صواب. فاتني سياق هذه التذكرة.
أتساءل عما إذا كان من المنطقي تقديم متغير بيئة منفصل لهذا أو إذا كان عليك فقط التأكد عند تشغيل الملفات التنفيذية كجذر لتعيين متغيرات البيئة الحالية بنفسك بشكل صريح.
بقدر ما أفهم ، يتم تجاهل LD_LIBRARY_PATH
تمامًا للملفات القابلة للتنفيذ setcap
/ setuid
، لذا فإن إعداده بنفسي لن يساعد للأسف. انظر http://man7.org/linux/man-pages/man8/ld.so.8.html
لست متأكدًا مما إذا كان تقديم بيئة جديدة مثل ROS_LIBRARY_PATH
لتجاوز قيود الأمان فكرة جيدة. ld
فقط لن يقوم بتصفية ذلك لأنه لا يعرف عنه ويتجاهل LD_LIBRARY_PATH
بسبب اعتبارات أمنية.
لا تتردد في اقتراح علاقات عامة لإضافة هذا التحسين (كما هو مشار إليه في ملصق "مطلوب مساعدة").
سوف ننظر في ذلك!
قم بإنشاء طلب سحب على https://github.com/ros2/rcpputils/pull/44
بدأت أنا و FWIWhidmic و Drake .
حسنًا ، لقد بدأت أتساءل لماذا نحتاج إلى rcpputils::find_library_path()
لتبدأ. إذا قمنا بتوفير rcutils_load_shared_library()
أو غلافه rcpputils::SharedLibrary
بمسار نسبي ، فإن dlopen
و LoadLibrary
سيبحثون عن المسارات وينتجون ملفات كائنات محملة. تشير الوثائق لكليهما إلى أنه لن يتم سحب ملفات الكائنات المحملة بالفعل مرة أخرى. من خلال القيام بذلك ، سيتم تكريم RPATHs و LD_LIBRARY_PATHs و RUNPATHs و PATHs والمكتبات المحملة مسبقًا افتراضيًا.
CC @ EricCousineau-TRIwiesetclalancette.
حسنًا ، راجع رقم 320 والعلاقات العامة المتصلة للحصول على أول طعنة في هذا. wieset يجب أن مشاكلك أيضًا. هذه التغييرات تجعل rcpputils::find_library_path
قديمًا بالرغم من ذلك (للاستخدام في الحزم الأساسية).
hidmic الآن بعد أن وصلنا إلى # 320 والأصدقاء ، هل يمكننا إغلاق هذا؟
في الواقع نستطيع. شكرا على النتوء!
شكرًا جزيلاً على hidmic ، أعتقد أن هذا RUNPATH
ليتم ملؤه بالسكان بشكل صحيح. سأواصل المناقشة مع clalancette @ في https://github.com/ros2/rcpputils/pull/44.
التعليق الأكثر فائدة
حسنًا ، لقد بدأت أتساءل لماذا نحتاج إلى
rcpputils::find_library_path()
لتبدأ. إذا قمنا بتوفيرrcutils_load_shared_library()
أو غلافهrcpputils::SharedLibrary
بمسار نسبي ، فإنdlopen
وLoadLibrary
سيبحثون عن المسارات وينتجون ملفات كائنات محملة. تشير الوثائق لكليهما إلى أنه لن يتم سحب ملفات الكائنات المحملة بالفعل مرة أخرى. من خلال القيام بذلك ، سيتم تكريم RPATHs و LD_LIBRARY_PATHs و RUNPATHs و PATHs والمكتبات المحملة مسبقًا افتراضيًا.CC @ EricCousineau-TRIwiesetclalancette.