Rcutils: find_library: prefiere las bibliotecas cargadas actualmente en lugar de buscar `LD_LIBRARY_PATH`

Aquí hay un prototipo funcional en Linux:
https://github.com/EricCousineau-TRI/rcpputils/commit/b66a3d9e02ace44e6c3b6022eeb3447b121d3311

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

En este compromiso para este proyecto de reproducción de Bazel, ahora puedo especificar la implementación de RMW en el momento de la vinculación o diferir a las variables de entorno:
https://github.com/EricCousineau-TRI/repro/commit/cea11026722b340580257564dc49cb0f59b55178

@ dirk-thomas Me resultaría extremadamente útil. ¿Puedo preguntar qué (si hay alguna) evidencia podría influir en usted para considerar esto? :D

¿Puedo preguntar qué (si hay alguna) evidencia podría influir en usted para considerar esto?

Dado que el objetivo de tener una distribución es garantizar la estabilidad, los backports son solo para corregir errores. Las mejoras deberían apuntar a la próxima distribución.

Está previsto que los primeros paquetes de prueba de Dashing estén disponibles en la primera semana de abril.

Sí, suena bien. Esperará la fusión de https://github.com/ros2/rcpputils/issues/3 , y luego archivará esto contra la rama dev. ¡Gracias!

Tenemos un nodo ros2 que necesita capacidades configuradas a través de setcap que lleva a que LD_LIBRARY_PATH se omita durante la ejecución. Así que estamos configurando RPATH en el binario para buscar bibliotecas compartidas. Sin embargo, como find_library_path basa en LD_LIBRARY_PATH el nodo falla con

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 entiendo correctamente, la propuesta de @ EricCousineau-TRI resolvería este problema. ¿Alguna posibilidad de obtener esta funcionalidad en la próxima versión? ¿O alguna sugerencia para una solución alternativa?

@ EricCousineau-TRI ¿planeas repetir esto?

Si entiendo correctamente, la propuesta de @ EricCousineau-TRI resolvería este problema.

@wieset ¿Cómo resolvería el problema si la biblioteca que está tratando de encontrar / cargar no está ya cargada?

@ivanpauno Probablemente no en ningún momento en el futuro cercano (~ 6 meses a 1 año), desafortunadamente :(

@ dirk-thomas Miré el código de ejemplo de @ EricCousineau-TRI y tienes razón, no resolvería mi problema si la biblioteca no está ya cargada. Supongo que podría vincularlo en el momento de la compilación para que se cargue al iniciar el programa.

Sin embargo, para preservar la carga en tiempo de ejecución, veo dos opciones: o RPATH tendría que ser buscado, que puedo configurar a través de CMAKE_INSTALL_RPATH , o se podría usar otra variable de entorno en lugar de LD_LIBRARY_PATH , por ejemplo, RMW_LIBRARY_PATH . Mencioné ambas opciones en https://github.com/ros2/rcpputils/issues/40.

@wieset Personalizar su compilación para usar rpath para este caso de uso parece el camino a seguir.

@ dirk-thomas De acuerdo, y ya estoy usando RPATH para cargar todas las demás bibliotecas. Pero eso no me hace entender el hecho de que find_library_path() para la biblioteca rmw actualmente no se ve allí. ¿O me estoy perdiendo algo?

Pero eso no me permite entender el hecho de que find_library_path() para la biblioteca rtw actualmente no se ve allí.

Tienes razón. Perdí el contexto en este boleto.

Me pregunto si tiene sentido introducir una variable de entorno separada para esto o si debería asegurarse al ejecutar ejecutables como root para establecer las variables de entorno existentes usted mismo explícitamente.

Por lo que tengo entendido, LD_LIBRARY_PATH se ignora por completo para los ejecutables setcap / setuid , por lo que, desafortunadamente, configurarlo yo mismo no ayudaría. Ver http://man7.org/linux/man-pages/man8/ld.so.8.html

No estoy seguro de si introducir una nueva var env como ROS_LIBRARY_PATH para evitar esa limitación de seguridad es una buena idea. ld solamente no filtraría eso porque no lo sabe e ignora LD_LIBRARY_PATH debido a consideraciones de seguridad.

Siéntase libre de proponer RP para agregar esta mejora (como se indica en la etiqueta "Se necesita ayuda").

¡Lo investigaremos!

Creó una solicitud de extracción en https://github.com/ros2/rcpputils/pull/44

FWIW @hidmic , @iantheengineer y yo estamos comenzando a discutir esto con otras personas en el TRI. Primero hacia nuestros usos internos, luego hacia la integración con cosas como Drake .

Hmm, estoy empezando a preguntarme por qué necesitamos rcpputils::find_library_path() para empezar. Si simplemente proporcionamos rcutils_load_shared_library() o su envoltorio rcpputils::SharedLibrary con una ruta relativa, dlopen y LoadLibrary buscarán rutas y producirán archivos de objetos cargados. La documentación de ambos sugiere que los archivos de objetos ya cargados no se volverán a extraer. Al hacer esto, los RPATH, LD_LIBRARY_PATH, RUNPATH, PATH y las bibliotecas precargadas se respetarían de forma predeterminada.

CC @ EricCousineau-TRI @wieset @clalancette.

Muy bien, consulte el n. ° 320 y los RP conectados para ver esto por primera vez. @wieset, esto también debería (indirectamente) resolver sus problemas. Sin embargo, estos cambios hacen que rcpputils::find_library_path obsoleto (para su uso en paquetes principales).

@hidmic Ahora que hemos conseguido el # 320 y amigos, ¿podemos cerrar esto?

De hecho, podemos. ¡Gracias por el golpe!

Muchas gracias @hidmic , creo que esto me lleva a la mitad del camino. RUNPATH aún debe completarse correctamente. Continuaré la discusión con @clalancette en https://github.com/ros2/rcpputils/pull/44.