3.1. 관례들(Conventions)

이 원하는 모든 기능을 지원하는 공유 라이브러리에 대해, 많은 관례와 지침이 따라주어야 한다. 당신은 라이브러리의 이름의 차이를 알아야 한다. 특별히, 불리는 이름``soname''과 실제이름``real name''에 대해서 알아야 한다(그리고 이것들이 어떻게 상호작용하는지를). 당신은 또한 이것들이 파일시스템의 어느부분에 위치하는지 알아야 한다.

3.2. 라이브러리 사용 방법들

모든 리눅스 시스템을 포함한 GNU glibc기반 시스템에서는, ELF 바이너리 실행파일의 시작은 프로그램로더가 적재되고 실행된 후에 한다. 리눅스 시스템에서는, 이 로더는 /lib/ld-linux.so.X(여기서 X는 버전 숫자)라는 이름이 붙는다. 이 로더는 프로그램에서 쓰이는 다른 모든 공유 라이브러리를 찾아주고 적재시켜준다.

탐색될때 찾아지는 디렉토리의 리스트는 /etc/ld.so.conf에 저장된다. 많은 Red Hat기반 배포판은 기본적으로 /usr/local/lib을 /etc/ld.so.conf에 저장하지 않는다. 나는 이것이 버그라고 생각한다. 따라서, Red Hat기반 시스템에서 많은 프로그램을 돌리기 위해 /etc/ld.so.conf에 /usr/local/lib을 추가하는것은 버그 ``픽스''이다.

라이브러리에 몇개의 함수를 추가하고 싶은데, 라이브러리의 나머지 부분을 유지하고 싶다면, 오버라이드하는 라이브러리의 이름(.o파일)을 /etc/ld.so.preload에 넣어라; 이 ``미리 적재되는'' 라이브러리는 기본 셋에 대해 우선순위를 가질것이다. 이 미리 적재되는 파일은 일반적으로 긴급패치에 사용된다; 배포판은 일반적으로 출시될때 그런파일들을 포함하지 않는다.

프로그램 시작시에 이런 디렉토리를 다 찾는것은 매우 비효율적인 일이다. 따라서, 보통 캐싱 정렬이 사용된다. ldconfig(8)은 기본으로 /etc/ld.so.conf를 읽고 동적 링크 디렉토리들(표준 관례를따르는)에서 적절한 심볼릭 링크를 만들고, /etc/ld.so.cache에 캐시를 써 넣으면, 다른 프로그램에서 사용된다. 이것은 라이브러리 접근의 속도를 높여준다. 관련된것은 DLL이 추가되거나 삭제되거나 DLL디렉토리가 변할때도 ldconfig이 작동해야 한다는 것이다; ldconfig를 동작시키는 것은 라이브러리를 설치할때 패키지 관리자가 수행해야할 작업 중 하나이다. 그리고나서, 시작시에 동적 로더가 /etc/ld.so.cache를 사용하고 필요한 라이브러리를 로드한다.

그런데, FreeBSD는 이 캐시를 위해 다른 파일이름을 사용한다. FreeBSD에서는, ELF 캐시는 /var/run/ld-elf.so.hints이고 a.out 캐시는 /var/run/ld.so.hints이다. 이것들은 ldconfig(8)에 의해서 업데이트된다. 따라서, 몇몇 다른 상황들에서만 이 장소의 차이가 문제가 된다.

3.3. 환경 변수들

여러가지 환경변수는 이 과정을 제어할 수 있다. 그리고 이 과정을 오버라이드하는 환경변수들이 존재한다.

  /lib/ld-linux.so.2 --library-path PATH EXECUTABLE

  export LD_DEBUG=files
  command_to_run

3.4. 공유 라이브러리 만들기

공유 라이브러리를 만드는 것은 쉽다. 처음으로, gcc-fPIC나 fpic플래그를 사용해서 공유 라이브러리로 사용될 오브젝트 파일을 만들어라. -fPIC나 -fpic옵션은 ``위치에 독립적인 코드''를 만들어주고, 공유 라이브러리의 조건을 만족시킨다; 아래의 차이점을 보라. 그리고 이 형식을 따라서 공유라이브러리를 만들어라:

gcc -shared -Wl,-soname,your_soname \
    -o library_name file_list library_list

두개의 오브젝트 파일(a.o, b.o)를 만들고 이것들 모두를 포함하는 공유 라이브러리를 만드는 예제이다. 컴파일이 디버그 정보(-g)와 경고정보(-Wall)를 포함하는데, 이것들은 공유라이브러리를 위해 필요한것은 아니지만, 추천되는 정보라는 것을 주의하라. 컴파일은 오브젝트 파일을 만들고(-c), -fPIC옵션을 요구한다.

gcc -fPIC -g -c -Wall a.c
gcc -fPIC -g -c -Wall b.c
gcc -shared -Wl,-soname,libmystuff.so.1 \
    -o libmystuff.so.1.0.1 a.o b.o -lc

주의할 만한 가치가 있는 것들이 있다:

• 꼭 필요한 경우가 아니라면, 결과로 생긴 라이브러리를 분해하거나, 컴파일러 옵션으로 -fomit-frame-pointer 옵션을 주지마라. 결과로 나온 라이브러리는 잘 동작할 것이고, 위의 행동은 디버거를 무용지물로 만든다

• 코드를 생성하기 위해 -fPIC이나 -fpic을 사용하라. 코드를 생성하기 위해 -fPIC이나 -fpic을 사용하는 것은 타겟에 따라서 다르다. -fPIC을 사용하는것은 언제나 동작한다. 하지만, -fpic을 사용하는 것보다 큰 코드를 생성할 것이다(PIC은 더 큰코드를 위한것이라서 더 많은 양의코드를 만든다는 것을 기억하라). -fpic옵션은 작고 빠른 코드를 만든다. 하지만, 전역심볼이나 코드의 크기 같은 것에서 플랫폼에 독립적이다. 링커는 공유 라이브러리를 만들때 이 옵션이 맞는지 말해줄 것이다. 어느것을 써야 할지를 모를때, 나는 언제나 동작하는 -fPIC을 선택한다.

• 몇몇의 경우에서, 오브젝트 파일을 만들기위해 gcc를 호출하는 것은 ``-Wl,-export-dynamic'' 옵션을 포함할 것이다. 보통 동적 심볼테이블은 동적 오브젝트에 의해 사용되는 심볼만 포함한다. 이 옵션은(ELF파일을 만들때) 동적 심볼테이블에 모든 심볼을 추가한다(더 많은 정보를 위해 ld(1)를 참고하라). '역 의존성'이 있을때 이 옵션을 필요로 할 것이다. 즉, DL라이브러리가 라이브러리를 로드하는데 프로그램에서 필요한 심볼이지만, 관례에 의해 정의되지 않은 심볼을 필요할 경우 사용된다. ``역 의존성''이 작동하기 위해서, 주 프로그램은 심볼이 동적으로 동작하게 해야 한다. 리눅스 시스템에서만 사용한다면, ``-Wl,export-dynamic''대신에 ``-rdynamic''을 사용할수도 있을 것이다. 하지만, ELF문서에 따르면 ``-rdynamic''플래그는 리눅스가 아닌 시스템의 gcc에서 항상 작동하는 것은 아니다.

개발과정동안, 다른 많은 프로그램에서 사용되는 라이브러리를 수정하고 싶을때가 있을 것이다 -- 그리고 당신은 프로그램들이 ``개발상의''라이브러리를 사용하는것을 원치 않을 것이고, 어떤 특정 응용프로그램만이 그것을 사용하기를 원할것이다. ld의 ``rpath''옵션은 어떤 특정한 프로그램이 컴파일 될 때 실시간으로 라이브러리의 패스를 정해주는 역할을 한다. gcc에서 당신은 다음과 같은 방식으로 rpath를 지정해 줄 수 있다:

 -Wl,-rpath,$(DEFAULT_LIB_INSTALL_PATH)

당신이 라이브러리 클라이언트 프로그램을 설치할때 이 옵션을 사용한다면, 그것이 충돌을 일으키지 않거나, 라이브러리를 숨기는 다른 기술을 사용하도록 하기위해 LD_LIBRARY_PATH를 사용하는 것을 걱정할 필요가 없다.

3.5. 공유 라이브러리를 설치하고 사용하기

당신이 공유 라이브러리를 만들었다면 당신은 그것을 설치하고 싶어 할 것이다. 간단한 방법은 표준 디렉토리(예들를어, /usr/lib)중 하나에 카피하고 ldconfig(8)을 실행시키는 것이다.

첫째로, 당신은 공유라이브러리를 어딘가에 설치하고 싶어할 것이다. 그리고나서, 당신은 실제이름을 불리는이름으로 심볼릭링크를 걸어야만 할것이다(버전 숫자가 없는 불리는 이름이다. 즉, ``.so''로 끝나서 사용자들이 버전에 상관없이 사용하게 하는 것이다). 간단한 접근법은 다음을 실행시키는 것이다:

 ldconfig -n directory_with_shared_libraries

마지막으로, 너의 프로그램을 컴파일할때 당신이 쓰려하는 정적, 공유 라이브러리에 대해 링커에게 말해줘야 한다. -l이나 -L옵션을 쓰면 된다.

당신이 라이브러리를 표준 공간(예를들어, 당신은 /usr/lib을 수정해야하는 것은 아니다)에 설치하고 싶지 않을 경우, 다른 접근법이 있다. 이 경우에, 당신은 다른 어딘가에 설치하고 프로그램이 라이브러리를 찾도록 충분한 정보를 주면된다. 이 방법에는 여러가지가 있다. 간단한경우로 gcc의 -L 플래그를 줄 수 있다. ``표준이 아닌''공간에 있는 특정한 프로그램을 가지고 있다면 ``rpath''를 사용할 수 있다. 물론 환경변수를 사용해서 해결하는 방법도 있다. 특별히, 당신은 콜론으로 구분되어지는 표준공간에서 검색 전에 찾아지는 공유라이브러리들의 디렉토리들의 모임인 LD_LIBRARY_PATH를 사용할 수 있다. 만약 당신이 bash를 사용한다면, my_program은 다음과 같은 방법으로 될 수 있다:

LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH  my_program

몇 개의 함수를 오버라이드 하구 싶다면, 오버라이드 할 오브젝트 파일을 만들고 LD_PRELOAD를 설정하라;이 오브젝트 파일의 함수는 그 함수들을 오버라이드 할 것이다(다른 함수들은 원래 있던대로 있을 것이다).

보통은 당신이 라이브러리를 걱정없이 업데이트 할 수 있다; 만약 API가 바뀌면 라이브러리 제작자는 불리는 이름을 바꾸어야 한다. 이런방식으로, 한 시스템에 많은 라이브러리가 있을것이고, 정확한것이 각각의 프로그램에서 선택되어서 사용되어진다. 그러나, 어떤 프로그램이 같은 불리는 이름을 가지는 라이브러리에 대해서 업데이트 한것이 잘 동작하지 않는다면, 너는 예전 버전의 라이브러리를 다른곳에 옮겨두고 그 프로그램의 이름을 바꾸고(예전이름에다가 ``.orig''를 붙인다), 라이브러리 사용을 리셋하고 실제의 새로 이름이 붙은 프로그램을 부르는 작은 ``감싸는(wrapper)'' 스크립트를 만들수 있다. 당신이 원한다면, 숫자 관례가 허용하는 한 같은 디렉토리에다가 예전의 라이브러리를 다른곳에 옮겨 둘 수 있다. 감싸는 스크립트는 다음과 같다:

  #!/bin/sh
  export LD_LIBRARY_PATH=/usr/local/my_lib:$LD_LIBRARY_PATH
  exec /usr/bin/my_program.orig $*

당신이 프로그램을 쓸때 꼭 이것에 의존하지는 말아라; 프로그램의 라이브러리가 예전것과 호환이 되는지 확인하거나 호환되지 않는 개정을 했을때 버전넘버를 증가시켰는지 체크하라. 이것은 최악의 경우의 ``긴급'' 접근법이다.

당신은 공유 라이브러리의 리스트를 ldd(1)을 사용해서 볼수 있다. 따라서, 예를들어 당신은 ls에 사용되는 공유 라이브러리를 볼 수 있다.

  ldd /bin/ls

일반적으로 당신은 그 이름이 속해있는 디렉토리에 따라 관계되는 불리는 이름의 목록을 볼 것이다. 특별히 모든 경우에서 다음의 두가지의 의존성을 가질것이다:

• /lib/ld-linux.so.N (N은 1이상인데 보통 2이다). 이것은 다른 라이브러리를 로드하는 라이브러리이다.

• libc.so.N (N은 6이상이다). 이것은 C라이브러리이다. 다른 언어에서 C라이브러리를 사용하고자 하면(적어도 그들의 라이브러리에서 구현하려할때), 다른 대부분의 프로그램들이 이것을 포함할 것이다.

3.6. 호환되지 않는 라이브러리들

새버전의 라이브러리가 예전버전과 이진-호환이 안된다면, 불려지는 이름이 바뀌어야 한다. C에서는 이진 호환이 안되게 되는 4가지 기본 경우가 있다.

1. 함수의 내용이 바뀌어서 본래의 스펙과 맞게 동작하지 않는 경우.

2. 수출된(exported) 데이타 아이템이 변한경우(예외 : 데이터 구조가 계속 라이브러리 내에 존재한다면, 데이터 구조의 내부에 아이템을 추가하는 것은 괜찮다)

3. exported 함수가 제거될 경우

4. exported 함수의 인터페이스가 변할 경우

이런경우를 피하려한다면, 이진-호환이 되게 라이브러리를 유지할 수 있다. 다시 말해서 그런경우를 피하고 싶다면 응용 이진 인터페이스(ABI=Application Binary Interface)를 할 수 있다. 예들들어, 예전것들을 지우지 않고 새로운 함수를 추가하고 싶을 수 있다. 당신은 구조에 새로운 아이템을 추가할 수 있다. 하지만, 예전 프로그램이 새로운 아이템을 추가한 구조를 인식하지 못한다거나 (프로그램이 아닌)라이브러리가 새로운 공간을 할당하지 못하거나, 추가의 아이템을 옵션으로 만드는것(또는 라이브러리가 그것들을 채우게 하는것)등등을 확실히 해야한다는 것을 주의하라. 주의하라 - 유저가 배열에 구조를 사용하고 있다면 당신은 배열의 구조를 늘릴수 없다.

C++(그리고 컴파일된 템플릿이나 다른 디스패치된 메소드를 지원하는 언어)에서 상황은 교묘해진다. 위의 모든 상황이 이루어져야 하고, 더 해주어야 할 이슈들이 있다. 상황은 컴파일된 코드에서 ``보이지 않게'' 구현되기 때문에 C++이 어떻게 구현되었는지 알지 못하면 애매모호해지는 의존성을 낳는 정보들 때문에 일어난다. 엄밀하게 말하면, 이것은 ``새로운'' 이슈는 아니다. 단지, 컴파일된 C++코드가 너에게 놀라게 할 수 있을것이다. 다음에 나오는 것들은 (아마도 부족하겠지만) Troll Tech's Technical FAQ에 나오는 이진 호환을 유지하기 위해 C++에서 사용하면 안되는 것들의 목록이다.

1. 가상함수를 재 구현하는것(그렇지 않으면 원래의 구현에서는 안전하다). 왜냐하면 컴파일러는 컴파일시에(링크시가 아니라) SuperClass::virtualFunction()를 구하기 때문이다.

2. 가상 멤버함수를 더하거나 제거하는것. 왜냐하면 이것은 모든 서브클래스의 vtlb의 크기와 구조를 바꾸기 때문이다.

3. 데이터 멤버의 타입을 바꾸거나 인라인 멤버함수를 통해 접근할 수 있는 데이터 멤버를 옮기는것.

4. 새 노드를 추가하는 것 이외에 클래스 구조를 바꾸는것.

5. private데이터 멤버를 추가하거나 삭제하는것. 왜냐하면 이것은 모든 서브클래스의 크기와 구조를 바꾸기 때문이다.

6. 인라인이 아닌 public, protected 멤버 함수를 제거하는것.

7. public, protected 멤버함수를 inline으로 만드는것.

8. inline함수를 바꾸어서, 예전버전이 제대로 작동하지 않는것.

9. 포팅할 프로그램의 멤버 함수의 접근권한(public, protected, private)을 바꾸는것. 왜냐하면, 어떤 컴파일러는 함수의 이름에 접근권한을 붙이기 때문이다.

위의 주어진 목록대로, C++라이브러리 개발자들은 때때로 이진 호환성을 깨는 업데이트를 계획해야만한다. 다행스럽게도, 유닉스 기반 시스템은 동시에 로드되는 라이브러리의 많은 버전을 가지고 있어서, 디스크 공간을 조금 할당한다면, 유저들은 예전의 라이브러리를 요구하는 ``예전''프로그램을 돌릴수 있다.