Rcutils: find_library :`LD_LIBRARY_PATH` 검색보다 현재로드 된 라이브러리를 선호합니다.

다음은 Linux에서 작동하는 프로토 타입입니다.
https://github.com/EricCousineau-TRI/rcpputils/commit/b66a3d9e02ace44e6c3b6022eeb3447b121d3311

Drake 출처에서 Cribbing :
https://github.com/RobotLocomotion/drake/blob/4c6246197/common/find_loaded_library.cc

이 Bazel 재현 프로젝트에 대한이 커밋에서 이제 링크시 RMW 구현을 지정하거나 환경 변수를 연기 할 수 있습니다.
https://github.com/EricCousineau-TRI/repro/commit/cea11026722b340580257564dc49cb0f59b55178

@ dirk-thomas 나는 이것이 매우 유용하다고

당신이 이것을 고려하도록 어떤 (있는 경우) 증거가 있는지 물어봐도 될까요?

배포판의 목표는 안정성 백 포트가 버그 수정 전용임을 확인하는 것입니다. 향상된 기능은 다음 배포판을 대상으로해야합니다.

Dashing의 첫 번째 테스트 패키지는 4 월 첫째 주에 제공 될 예정입니다.

예, 좋은 것 같습니다. https://github.com/ros2/rcpputils/issues/3 의 병합을

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의 예제 코드를 보았고 당신이 맞습니다. 라이브러리가 아직로드되지 않은 경우 내 문제를 해결할 수 없습니다. 프로그램 시작시로드되도록 빌드 할 때 링크 할 수 있을까요?

그러나 런타임에로드를 유지하기 위해 두 가지 옵션이 표시됩니다. 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() 가 현재 거기에서 보이지 않는다는 사실을 이해하지 못합니다.

당신이 옳습니다. 이 티켓의 내용을 놓쳤습니다.

이를 위해 별도의 환경 변수를 도입하는 것이 합리적 일지 또는 기존 환경 변수를 명시 적으로 설정하기 위해 실행 파일을 루트로 실행할 때 확인해야하는지 궁금합니다.

내가 아는 한 LD_LIBRARY_PATH 는 setcap / setuid 실행 파일에 대해 완전히 무시되므로 직접 설정해도 도움이되지 않습니다. http://man7.org/linux/man-pages/man8/ld.so.8.html 참조

보안 제한을 우회하기 위해 ROS_LIBRARY_PATH 와 같은 새로운 환경 변수를 도입하는 것이 좋은 생각인지 확실하지 않습니다. ld 는 그것에 대해 알지 못하기 때문에 필터링하지 않으며 보안 고려 사항으로 인해 LD_LIBRARY_PATH 무시합니다.

이 개선 사항을 추가 할 PR을 자유롭게 제안하십시오 ( "지원 필요"레이블로 표시됨).

그것을 조사 할 것입니다!

https://github.com/ros2/rcpputils/pull/44 에서 pull 요청을 생성했습니다.

FWIW @hidmic , @iantheengineer , 그리고 저는 TRI의 다른 사람들과 이것을 논의하기 시작했습니다. 먼저 내부 용도로 사용 된 다음 Drake 와 같은 것들과의 통합으로 이동합니다.

흠, 시작하는 데 rcpputils::find_library_path() 이 필요한 이유가 궁금합니다. 단순히 rcutils_load_shared_library() 또는 rcpputils::SharedLibrary 래퍼에 상대 경로를 제공하면 dlopen 및 LoadLibrary 가 경로를 검색하고로드 된 개체 파일을 생성합니다. 둘 다에 대한 문서에 따르면 이미로드 된 개체 파일은 다시 가져 오지 않을 것입니다. 이렇게하면 RPATH, LD_LIBRARY_PATH, RUNPATH, PATH 및 사전로드 된 라이브러리가 기본적으로 적용됩니다.

CC @ EricCousineau-TRI @wieset @clalancette.

좋아, 이것에 대한 첫 번째 찌르기 위해 # 320 및 연결된 PR을 참조하십시오. @wieset 은 (간접적으로) 문제도 해결해야합니다. 이러한 변경으로 인해 rcpputils::find_library_path 은 (는) 쓸모 없게됩니다 (코어 패키지에서 사용).

@hidmic 이제 320 번과 친구들이 도착 했으니 이걸 닫아도 될까요?

실제로 우리는 할 수 있습니다. 범프에 감사드립니다!

@hidmic 정말 감사합니다. RUNPATH 은 (는) 여전히 제대로 채워 져야합니다. https://github.com/ros2/rcpputils/pull/44 에서 @clalancette 와 토론을 계속하겠습니다 .