Rcutils: find_library: Lebih suka perpustakaan yang dimuat saat ini daripada menelusuri `LD_LIBRARY_PATH`

Berikut adalah prototipe yang berfungsi di Linux:
https://github.com/EricCousineau-TRI/rcpputils/commit/b66a3d9e02ace44e6c3b6022eeb3447b121d3311

Cribbing dari sumber Drake:
https://github.com/RobotLocomotion/drake/blob/4c6246197/common/find_loaded_library.cc

Pada komit untuk proyek repro Bazel ini, saya sekarang dapat menentukan implementasi RMW pada waktu penautan, atau tunduk pada variabel lingkungan:
https://github.com/EricCousineau-TRI/repro/commit/cea11026722b340580257564dc49cb0f59b55178

@ dirk-thomas menurut saya ini sangat berguna. Bolehkah saya bertanya (jika ada) bukti yang mungkin mempengaruhi Anda untuk mempertimbangkan hal ini? : D

Bolehkah saya bertanya (jika ada) bukti yang mungkin mempengaruhi Anda untuk mempertimbangkan hal ini?

Karena tujuan memiliki distro adalah untuk memastikan stabilitas backport hanya untuk perbaikan bug. Peningkatan harus menargetkan distro berikutnya.

Paket uji coba pertama Dashing ditargetkan akan tersedia pada minggu pertama April.

Aye, kedengarannya bagus. Akan menunggu penggabungan https://github.com/ros2/rcpputils/issues/3 , dan kemudian mengajukan ini ke cabang dev. Terima kasih!

Kami memiliki simpul ros2 yang membutuhkan kemampuan yang ditetapkan melalui setcap yang menyebabkan LD_LIBRARY_PATH dihilangkan selama eksekusi. Jadi kami menyetel RPATH dalam biner untuk menemukan pustaka bersama. Namun, karena find_library_path bergantung pada LD_LIBRARY_PATH node gagal

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

Jika saya mengerti dengan benar, proposal oleh @ EricCousineau-TRI akan menyelesaikan masalah ini. Adakah kesempatan untuk mendapatkan fungsi ini di rilis berikutnya? Atau ada saran untuk mengatasinya?

@ EricCousineau-TRI apakah Anda berencana untuk mengulanginya?

Jika saya mengerti dengan benar, proposal oleh @ EricCousineau-TRI akan menyelesaikan masalah ini.

@wieset Bagaimana cara mengatasi masalah jika pustaka yang Anda coba temukan / muat belum dimuat?

@ivanpauno Mungkin tidak dalam waktu dekat (~ 6 bulan hingga 1 tahun), sayangnya :(

@ dirk-thomas Saya melihat kode contoh @ EricCousineau-TRI dan Anda benar, itu tidak akan menyelesaikan masalah saya jika perpustakaan belum dimuat. Saya kira saya dapat menautkannya pada waktu pembuatan sehingga dapat dimuat saat program dimulai?

Namun, untuk mempertahankan pemuatan pada waktu proses, saya melihat dua opsi: RPATH harus dicari, yang dapat saya atur melalui CMAKE_INSTALL_RPATH , atau variabel lingkungan lain dapat digunakan sebagai pengganti LD_LIBRARY_PATH , misalnya RMW_LIBRARY_PATH . Saya menyebutkan kedua opsi itu di https://github.com/ros2/rcpputils/issues/40.

@wieset Menyesuaikan build Anda agar menggunakan rpath untuk kasus penggunaan ini sepertinya cara yang tepat.

@ dirk-thomas Setuju, dan saya sudah menggunakan RPATH untuk memuat semua pustaka lainnya. Tapi itu tidak membuat saya memahami fakta bahwa find_library_path() untuk perpustakaan rmw saat ini tidak terlihat di sana. Atau apakah saya melewatkan sesuatu?

Tapi itu tidak membuat saya memahami fakta bahwa find_library_path() untuk pustaka rtw saat ini tidak terlihat di sana.

Kamu benar. Saya melewatkan konteks tiket ini.

Saya ingin tahu apakah masuk akal untuk memperkenalkan variabel lingkungan terpisah untuk ini atau jika Anda harus memastikan saat menjalankan executable sebagai root untuk mengatur sendiri variabel lingkungan yang ada secara eksplisit.

Sejauh yang saya mengerti, LD_LIBRARY_PATH diabaikan sepenuhnya untuk setcap / setuid dapat dieksekusi, jadi sayangnya pengaturannya sendiri tidak akan membantu. Lihat http://man7.org/linux/man-pages/man8/ld.so.8.html

Tidak yakin apakah memperkenalkan env var baru seperti ROS_LIBRARY_PATH untuk melewati batasan keamanan itu adalah ide yang bagus. ld hanya tidak akan memfilter itu karena ia tidak mengetahuinya dan mengabaikan LD_LIBRARY_PATH karena pertimbangan keamanan.

Silakan mengajukan PR untuk menambahkan peningkatan ini (seperti yang ditunjukkan oleh label "dibutuhkan bantuan").

Akan memeriksanya!

Membuat permintaan tarik di https://github.com/ros2/rcpputils/pull/44

FWIW @hidmic , @iantheengineer , dan saya mulai membahas hal ini dengan orang lain di TRI. Pertama menuju penggunaan internal kami, lalu menuju integrasi dengan hal-hal seperti Drake .

Hmm, saya mulai bertanya-tanya mengapa kita perlu rcpputils::find_library_path() untuk memulai. Jika kita hanya menyediakan rcutils_load_shared_library() atau rcpputils::SharedLibrary pembungkusnya dengan path relatif, dlopen dan LoadLibrary akan mencari path dan menghasilkan file objek yang dimuat. Dokumentasi untuk keduanya menunjukkan bahwa file objek yang sudah dimuat tidak akan ditarik lagi. Dengan melakukan ini, RPATHs, LD_LIBRARY_PATHs, RUNPATHs, PATHs, dan pustaka yang dimuat sebelumnya akan diberlakukan secara default.

CC @ EricCousineau-TRI @wieset @clalancette.

Oke, lihat # 320 dan PR terhubung untuk pertama kalinya. @wieset ini seharusnya (secara tidak langsung) menyelesaikan masalah Anda juga. Perubahan ini membuat rcpputils::find_library_path usang (untuk penggunaan dalam paket inti).

@hidmic Sekarang kita telah mendapatkan # 320 dan teman-teman, dapatkah kita menutup ini?

Memang kita bisa. Terima kasih untuk benjolannya!

Terima kasih banyak @hidmic , saya pikir ini membuat saya setengah jalan. RUNPATH masih perlu diisi dengan benar. Saya akan melanjutkan diskusi dengan @clalancette di https://github.com/ros2/rcpputils/pull/44.