2010-11-19 5 views
2

필자는 필요한 저장소 백엔드의 일부 기능을 번들로 제공하는 동적 (.so) 라이브러리를 만들었습니다. 그대로
, 그것은 알려진 인터페이스를 제공하고 공유 라이브러리 유닉스에서의 의존성을 다루는 방법

이제 내 문제는 내 공유 라이브러리가 libmysqlclient에 libsqlite3에 libmemcached에 달려 있다는 것입니다 등 memcached를, MySQL은, SQLite는 ... 같은 것들에 대한 백엔드를 제공합니다 .. 등등, 나는 그것을 포장하는 방법을 모르기 때문에 sqlite 만 필요로하는 클라이언트는 libmemcached를 설치할 필요가 없기 때문에 포장해야합니다.

다른 라이브러리로 분할하려고 생각했지만 20 개 정도의 .so 라이브러리로 끝나고 그 생각을 좋아하지 않는 것 같습니다.

대체품?

답변

3

하나의 대안은 사용자가 만든 공유 라이브러리 내에 인터페이스를 배치하는 것입니다. 런타임시 종속성을로드 할 수 있습니다. 따라서, 예를 들어 서로 다른 구성 요소에 대해 별도의 초기화 기능을 가질 수 있습니다

init_memcached(); 
init_sqlite(); 

당신은 dlopen() 친구를 사용하여 이러한 초기화 기능을 구현합니다.

0

런타임 중에 필요한 공유 라이브러리 만로드 할 수는 있지만 내 의견으로는 그렇게 좋은 접근 방법이 아닙니다.

나는 20 개의 라이브러리가 아닌 공유 라이브러리를 분리했다. 몇 가지 공통 기능을 그룹화 할 수 있는지 확인하십시오.

+0

궁금합니다. 왜 첫 번째 접근 방식을 좋다고 생각하지 않습니까? – Sudhanshu

+0

@Sudhanshu 그 접근 방식의 문제점은 필요한 모든 함수의 주소를 알아야하고 C에서 잘 작동하지만 C++에서는 (예를 들어 객체를 만들고 삭제하는 함수를 제공하는 등) 몇 가지 저글링이 필요합니다. –

2

dynamic loadingdlsymdlopen을 사용할 수 있습니다. 이 방법의 장점은 클라이언트 측에서 공유 라이브러리를 찾을 수 없을 때 응용 프로그램이 잘 실행된다는 것입니다.