Rcutils: find_library: Préfère les bibliothèques actuellement chargées à la recherche de `LD_LIBRARY_PATH`

Voici un prototype fonctionnel sous Linux:
https://github.com/EricCousineau-TRI/rcpputils/commit/b66a3d9e02ace44e6c3b6022eeb3447b121d3311

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

Lors de cette validation pour ce projet de repro Bazel, je peux maintenant soit spécifier l'implémentation RMW au moment de la liaison, soit m'en remettre aux variables d'environnement:
https://github.com/EricCousineau-TRI/repro/commit/cea11026722b340580257564dc49cb0f59b55178

@ dirk-thomas Je trouverais cela extrêmement utile. Puis-je vous demander quelles preuves (le cas échéant) pourraient vous inciter à considérer cela? :RÉ

Puis-je vous demander quelles preuves (le cas échéant) pourraient vous inciter à considérer cela?

Étant donné que le but d'avoir une distribution est de garantir la stabilité, les backports sont uniquement destinés aux corrections de bogues. Les améliorations devraient cibler la prochaine distribution.

Les premiers packages de test de Dashing devraient être disponibles au cours de la première semaine d'avril.

Oui, ça sonne bien. Attendra la fusion de https://github.com/ros2/rcpputils/issues/3 , puis déposez-le contre la branche dev. Merci!

Nous avons un nœud ros2 qui a besoin de capacités définies via setcap ce qui conduit à l'omission de LD_LIBRARY_PATH lors de l'exécution. Nous définissons donc RPATH dans le binaire pour trouver des bibliothèques partagées. Cependant, comme find_library_path dépend de LD_LIBRARY_PATH le nœud échoue avec

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

Si je comprends bien, la proposition de @ EricCousineau-TRI résoudrait ce problème. Avez-vous une chance d'obtenir cette fonctionnalité dans la prochaine version? Ou des suggestions pour une solution de contournement?

@ EricCousineau-TRI envisagez-vous d'itérer là-dessus?

Si je comprends bien, la proposition de @ EricCousineau-TRI résoudrait ce problème.

@wieset Comment résoudre le problème si la bibliothèque que vous essayez de trouver / charger n'est pas déjà chargée?

@ivanpauno Probablement pas à tout moment dans un proche avenir (~ 6 mois à 1 an), malheureusement :(

@ dirk-thomas J'ai regardé l'exemple de code de @ EricCousineau-TRI et vous avez raison, cela ne résoudrait pas mon problème si la bibliothèque n'est pas déjà chargée. Je suppose que je pourrais le lier au moment de la construction afin qu'il soit chargé au démarrage du programme?

Cependant, pour préserver le chargement au moment de l'exécution, je vois deux options: Soit RPATH devrait être recherché, que je peux définir via CMAKE_INSTALL_RPATH , ou une autre variable d'environnement pourrait être utilisée à la place de LD_LIBRARY_PATH , par exemple RMW_LIBRARY_PATH . J'ai mentionné ces deux options sur https://github.com/ros2/rcpputils/issues/40.

@wieset Personnaliser votre build pour utiliser rpath pour ce cas d'utilisation semble être la voie à suivre.

@ dirk-thomas D'accord, et j'utilise déjà RPATH pour charger toutes les autres bibliothèques. Mais cela ne me permet pas de contourner le fait que find_library_path() pour la bibliothèque rmw ne s'y trouve actuellement pas. Ou est-ce que je manque quelque chose?

Mais cela ne me permet pas de contourner le fait que find_library_path() pour la bibliothèque rtw ne regarde actuellement pas là.

Vous avez raison. J'ai raté le contexte sur ce billet.

Je me demande s'il est judicieux d'introduire une variable d'environnement distincte pour cela ou si vous devez simplement vous assurer que lorsque vous exécutez des exécutables en tant que root, vous définissez vous-même explicitement les variables d'environnement existantes.

Autant que je sache, LD_LIBRARY_PATH est complètement ignoré pour les exécutables setcap / setuid , donc le configurer moi-même n'aiderait pas malheureusement. Voir http://man7.org/linux/man-pages/man8/ld.so.8.html

Je ne sais pas si l'introduction d'une nouvelle variable d'environnement comme ROS_LIBRARY_PATH pour contourner cette limitation de sécurité est une bonne idée. ld ne filtrerait pas cela parce qu'il ne le sait pas et qu'il ignore LD_LIBRARY_PATH pour des raisons de sécurité.

N'hésitez pas à proposer des PR pour ajouter cette amélioration (comme indiqué par le libellé "aide recherchée").

Regardera dedans!

Création d'une pull request sur https://github.com/ros2/rcpputils/pull/44

FWIW @hidmic , @iantheengineer et moi commençons à en discuter avec d'autres personnes du TRI. D'abord vers nos usages internes, puis vers l'intégration avec des choses comme Drake .

Hmm, je commence à me demander pourquoi nous avons besoin de rcpputils::find_library_path() pour commencer. Si nous fournissons simplement rcutils_load_shared_library() ou son wrapper rcpputils::SharedLibrary avec un chemin relatif, dlopen et LoadLibrary rechercheront des chemins et produiront des fichiers objets chargés. La documentation pour les deux suggère que les fichiers objets déjà chargés ne seront pas récupérés. En faisant cela, les RPATHs, LD_LIBRARY_PATHs, RUNPATHs, PATHs et les bibliothèques préchargées seraient honorés par défaut.

CC @ EricCousineau-TRI @wieset @clalancette.

Très bien, voir le n ° 320 et les PR connectés pour un premier essai à ce sujet. @wieset cela devrait également résoudre (indirectement) vos problèmes. Ces changements rendent cependant rcpputils::find_library_path obsolète (pour une utilisation dans les packages principaux).

@hidmic Maintenant que nous avons atterri # 320 et ses amis, pouvons-nous clôturer ça?

En effet, nous pouvons. Merci pour la bosse!

Merci beaucoup @hidmic , je pense que cela m'amène à mi-chemin. RUNPATH doit encore être rempli correctement. Je vais continuer la discussion avec @clalancette sur https://github.com/ros2/rcpputils/pull/44.