[공유라이브러리] O/S별 공유라이브러리에서 자유로울수 있는 방
글쓴이: ssik425 / 작성시간: 화, 2005/09/06 - 3:45오후
- 제목이 좀 거창하네요.. ^^
제가 작성한 프로그램은 C를 이용해서 PostgreSql에 DB를 생성하고 데이터를 입력하는 단순한 구조를 가지고 있습니다. 그런데 O/S의 버전에 따라 달라지는 Postgresql의 공유라이브러리 버전때문에 매번 컴파일을 해야하는 불편함이 있습니다.
공유라이브러리를 좀더 유동적으로 Load하는 방법은 없을까요.. O/S의 버전에 맞게 공유라이브러리의 경로나 파일등을 프로그램적으로 제어할수 있다면 좀더 일이 덜어질것 같네요..
Makefile의 버전에 맞게 분활하여 사용하란 답변은 말아 주세요.. 이미 그렇게 하고 있습니다. ^^
Forums:
공유 라이브러리들은 dlopen() 으로 열어서 사용할 수 있습니다.
공유 라이브러리들은 dlopen() 으로 열어서 사용할 수 있습니다.
프로그램 내에서 API 콜을 하는 경우에는 공유 라이브러리에 링크가 걸려서
해당 공유 라이브러리가 없으면 프로그램 자체가 로딩되지 않지만,
dlopen() 으로 열어서 심볼 링크를 직접 해서 API 를 사용하는 경우에는
공유 라이브러리 링크가 걸리지 않습니다.
자세한 것은 dlopen(), dlsym() 의 맨 페이지를 보시면 됩니다.
동적 라이브러리를 원하시는 이름으로 ln 하시면 어떨까요?
동적 라이브러리를 원하시는 이름으로 ln 하시면 어떨까요?
postgres의 so가 어떤 식으로 배포되는지는 모르겠지만, 공유 라이
postgres의 so가 어떤 식으로 배포되는지는 모르겠지만, 공유 라이브러리는 대략 다음과 같은 어려움에 봉착하게 됩니다.
* 공유라이브러리 파일 이름에 들어 있는 버전이 다릅니다.
* 공유라이브러리 안에 들어 있는 SONAME이 다릅니다.
* 공유라이브러리 안에 들어 있는 심볼의 버전이 다릅니다.
OS가 다른것때문에 생기는 문제는 libtool을 쓰라고 권하겠지만, OS 버전에 따라 배포되는 so 버전이 다른 것들은 사실 compat library를 설치하여 하위 호환성을 유지시키는 방법외에는 kslee80님의 말대로 dlopen 밖에는 없습니다. 이것 마저 어려운 경우는 다음과 같습니다.
A라는 프로그램은 B라는 so를 dlopen으로 엽니다.
B라는 so는 또 다른 C라는 so에 의존하여 같이 load됩니다.
그런데 이 C라는 녀석은 A에도 의존하기 때문에 이미 올라와 있습니다.
이 때, C 라는 녀석이 A,B 들이 컴파일될 당시의 so 버전과 일치하지 않는것이
문제일 수가 있습니다.
결국 문제는 원점으로 돌아와서 각 OS마다 배포되는 so에 맞게 프로그램을 매번 컴파일하지 않으면 안되는 문제가 발생합니다.
위와 같은 극단(?)적인 상황이 아니라면, -l 을 사용하는 so에 의존성을 명시하는 것 보다 수동으로 dlopen하는 것이 해결책입니다.
---
http://coolengineer.com
댓글 달기