Rcutils: find_library： `LD_LIBRARY_PATH`の検索よりも現在ロードされているライブラリを優先します

Linuxで動作するプロトタイプは次のとおりです。
https://github.com/EricCousineau-TRI/rcpputils/commit/b66a3d9e02ace44e6c3b6022eeb3447b121d3311

ドレイクソースからのクリブ：
https://github.com/RobotLocomotion/drake/blob/4c6246197/common/find_loaded_library.cc

このBazel再現プロジェクトのこのコミットで、リンク時にRMW実装を指定するか、環境変数に従うことができます。
https://github.com/EricCousineau-TRI/repro/commit/cea11026722b340580257564dc49cb0f59b55178

@ dirk-thomasこれは非常に便利だと思います。 （もしあれば）どのような証拠があなたにこれを検討するように動揺させるかもしれないか尋ねることができますか？ ：D

（もしあれば）どのような証拠があなたにこれを検討するように動揺させるかもしれないか尋ねることができますか？

ディストリビューションを持つことの目標は安定性を確保することなので、バックポートはバグ修正のみを目的としています。 拡張機能は、次のディストリビューションを対象にする必要があります。

Dashingの最初のテストパッケージは、4月の第1週に利用可能になることを目標としています。

ええ、いいですね。 https://github.com/ros2/rcpputils/issues/3のマージを待ってから、これをdevブランチに対してファイルします。 ありがとう！

setcapを介して設定された機能を必要とするros2ノードがあり、実行中に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か月から1年）はいつでもないでしょう:(

@ dirk-thomas @ EricCousineau-TRIのサンプルコードを見ましたが、その通りです。ライブラリがまだロードされていなければ、問題は解決しません。 プログラムの起動時に読み込まれるように、ビルド時にリンクできると思いますか？

ただし、実行時の読み込みを維持するには、2つのオプションがあります。 RPATHを検索する必要があります。これはCMAKE_INSTALL_RPATHで設定できます。または、 LD_LIBRARY_PATH代わりに別の環境変数を使用できます。 RMW_LIBRARY_PATH 。 これらのオプションは両方ともhttps://github.com/ros2/rcpputils/issues/40で説明しました。

@wiesetこのユースケースでrpathを使用するようにビルドをカスタマイズすることは、道のりのように思えます。

@ dirk-thomas同意しました。私はすでに、他のすべてのライブラリをロードするためにRPATHを使用しています。 しかし、それでは、rmwライブラリのfind_library_path()が現在そこに表示されていないという事実を回避することはできません。 それとも私は何かが足りないのですか？

しかし、それでは、rtwライブラリのfind_library_path()が現在そこに表示されていないという事実を回避することはできません。

あなたが正しいです。 このチケットのコンテキストを見逃しました。

これに別の環境変数を導入するのが理にかなっているのか、それとも実行可能ファイルをrootとして実行するときに、既存の環境変数を自分で明示的に設定することを確認する必要があるのでしょうか。

私の知る限り、 LD_LIBRARY_PATHはsetcap / setuid実行可能ファイルでは完全に無視されるため、自分で設定しても残念ながら役に立ちません。 http://man7.org/linux/man-pages/man8/ld.so.8.htmlを参照して

そのセキュリティ制限を回避するためにROS_LIBRARY_PATHような新しいenv変数を導入することが良い考えであるかどうかはわかりません。 ldはそれを知らないため、それをフィルタリングせず、セキュリティ上の理由からLD_LIBRARY_PATH無視します。

この拡張機能を追加するためのPRを自由に提案してください（「ヘルプ募集」ラベルで示されています）。

調べてみます！

https://github.com/ros2/rcpputils/pull/44でプルリクエストを作成しました

FWIW @ hidmic 、 @ iantheengineer 、そして私はこれについてTRIの他の人々と話し合い始めています。 最初に私たちの内部使用に向けて、次にドレイクのようなものとの統合に向けて。

うーん、そもそもなぜrcpputils::find_library_path()が必要なのか疑問に思い始めています。 rcutils_load_shared_library()またはそのrcpputils::SharedLibraryラッパーに相対パスを指定するだけの場合、 dlopenとLoadLibraryはパスを検索し、ロードされたオブジェクトファイルを生成します。 両方のドキュメントは、すでにロードされたオブジェクトファイルが再びプルされないことを示唆しています。 これを行うことにより、RPATH、LD_LIBRARY_PATH、RUNPATH、PATH、およびプリロードされたライブラリがデフォルトで尊重されます。

EricCousineau-TRI @wieset @clalancette @ CC。

了解しました。これを最初に確認するには、＃320と接続されたPRを参照してください。 @wiesetこれは（間接的に）あなたの問題も解決するはずです。 ただし、これらの変更により、 rcpputils::find_library_path廃止されます（コアパッケージで使用する場合）。

@ hidmic ＃320と友達を上陸させたので、これを閉じることができますか？

確かにできます。 バンプをありがとう！

どうもありがとうRUNPATHは、適切に入力する必要があります。 https://github.com/ros2/rcpputils/pull/44で@clalancetteとの議論を続けます。