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

Cr√©√© le 25 mars 2019  ¬∑  22Commentaires  ¬∑  Source: ros2/rcutils

√Ä l'heure actuelle, find_library passe directement √† la recherche de biblioth√®ques avec LD_LIBRARY_PATH , plut√īt que d'interroger d'abord les biblioth√®ques charg√©es. Une des 3 impl√©mentations actuelles:
https://github.com/ros2/rmw_implementation/blob/32c3de1/rmw_implementation/src/functions.cpp#L77

Ce serait bien si ce code préférait à la place les bibliothèques actuellement chargées, pour prendre en charge le code d'application qui ne veut

help wanted

Commentaire le plus utile

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.

Tous les 22 commentaires

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.

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

utrenkner picture utrenkner  ¬∑  3Commentaires

zatricky picture zatricky  ¬∑  3Commentaires

itsnotvalid picture itsnotvalid  ¬∑  3Commentaires

romainvause picture romainvause  ¬∑  3Commentaires

helloqhx picture helloqhx  ¬∑  3Commentaires