autotoos/libtool에서 적절한 플러그인 (모듈) 처리

Question

정적 라이브러리 L을 생성하는 프로젝트가 있습니다. L의 일부 기능은 일부 플러 거스 M을로드 할 수 있습니다 (dlopen("libmmmm.so") : M은 공유 라이브러리 (모듈) 임). .

L의 module_load() 함수를 테스트하는 테스트 T는 T + L에서의로드를 테스트하기 위해 L 테스트의 주요 테스트 T (L은 통계적으로 링크 됨)와 플러그 인 M으로 구성됩니다.

테스트는 설치의 일부입니다 (testdir이 정의되어 있음).

#the test program linked with the static lib L: 
#(the tests are distributed as well, hence the test_* prefix)         
test_PROGRAMS = tttt          
tttt_SOURCES = tttt.c 
tttt_LDADD = llll.la 

#the module to be loaded by the T+L test:              
lib_LTLIBRARIES = libmmmm.la           
libmmmm_la_SOURCES = mmmm.c         
libmmmm_la_LDFLAGS = $(AM_LDFLAGS) -module -shared 

문제는 모듈을 찾을 수있는 경로에 관한됩니다

: 테스트 작업을 (즉, libmmmm

여기에 테스트 T의 디렉토리에있는 Makefile.am (건물 모두 T와 M)을 다음과 .so가 있습니다) 확인을 위해. 하지만 out of tree (VPATH) 빌드 (공유 라이브러리를 찾을 수 없음)에 실패합니다.

그래서 질문 : 어떻게 작동합니까? libtool이는, 내 생각, dlopen()으로 *.la 래퍼를 결코 이해하지 못할 것입니다 LD_LIBRARY_PATH 같은 것을 ... 설정하는

그래서합니까 이것은 그래서 나무에서, 즉 확인을 항상 작동 내가 고칠 수있는 방법은 무엇 build, distcheck ... .libs 디렉토리에 대한 검색 경로를 하드 코딩하는 것은 매우 휴대 가능하다고 느끼지 않습니다. 우리는 여러 플랫폼을 대상으로하기 때문에 autotools를 사용합니다.

PS : 나는 때문에 당신은 그것을 돌봐 libltdl를 사용할 수있는 "-module"옵션

Answer 1

에 M의 "LIB"접두사를 생략 할 수 있음을 알고, 그 중 하나는 .la 파일을 이해하고, 않습니다 로드를 수정하지만 100 % 동일한 API가 아닙니다.

그렇지 않은 경우이 상황에서 LD_LIBRARY_PATH을 설정하는 자체 래퍼 스크립트를 작성해야합니다.