.so.2 파일이란 무엇입니까?

Question

GCC를 사용하여 소스에서 인텔 TBB를 컴파일했습니다. libtbb.so 및 littbb.so.2를 생성합니다. .so.2 파일이 실제 공유 라이브러리 인 것처럼 보입니다. libtbb.so는 텍스트 줄만 포함합니다. INPUT (libtbb.so.2)

두 파일 대신 하나의 파일을 생성하는 목적은 무엇입니까? INPUT (libtbb.so.2)의 경우 구문은 무엇입니까? 나는 그것에 대해 더 알고 싶다.

Answer 1

일반적으로 공유 객체 (.so)를 빌드하면 mylib.so.2.3.1과 같은 접미사를 추가하여 버전을 관리합니다. 프로그램은 당신이 이름 그래서

mylib.so -> mylib.so.2.3.1 
mylib.so.2 -> mylib.so.2.3.1 
mylib.so.2.3 -> mylib.so.2.3.1 

와 링크를 만들이 lib 디렉토리 또는 다른 이상 버전을로드 할 수 있는지 확인하기 위해, 모든 .so를가 version.sub-version.build 나타냅니다 후 (또는 유사) 또한, 그것은 가능합니다 이 스키마와 공존 할 수있는 동일한 lib의 버전이 두 개 이상 있습니다. 특정 버전을 사용하도록 프로그램을 전환하는 데 필요한 모든 것이 적절한 링크가 있어야합니다.

Answer 2

동적으로 연결된 ELF 바이너리 (다른 라이브러리 또는 실행 파일)는 실행시 실행 파일과 링크되어야하는 라이브러리를 식별하기 위해 shared-object name or soname을 사용합니다.

라이브러리가 ELF 공유 라이브러리로 생성되면 컴파일 타임 링크 편집기는 라이브러리의 SONAME이 라이브러리 자체에있는 실행 파일에 DT_SONAME 필드를 삽입합니다. DT_SONAME는 같은 ELF standard에 정의되어

는

이 요소는 공유 객체의 이름을주고, 널 종료 문자열에 대한 문자열 테이블 옵셋을 보유하고 있습니다. 오프셋은 DT_STRTAB 항목에 기록 된 테이블에 대한 인덱스 입니다. 이러한 이름에 대한 자세한 내용은 아래의 ''공유 객체 종속성 ''을 참조하십시오.

이제 실행 파일을 만들면 SONAME이 포함됩니다. 실행 파일이 실행될 때 동적 라이브러리의 미리 정의 된 위치에있는 파일에서 라이브러리를 찾기 위해 링커에서 사용됩니다. Windows에서 사전 정의 된 위치는 DLL이 상주하는 모든 위치에 있습니다. Linux 및 Mac OS X 및 다른 System V 호환 시스템에서 그들은 /lib 및 /usr/lib이고 가능한 다른 지점은 사용 된 링커에 따라 다르며 링커 자신의 구성에서 정의 할 수 있습니다.

모든 이벤트에서 링커는 soname 항목에 명명 된 라이브러리가 해당 위치에 존재하는지 확인합니다 (사용하는 경우).

가 불리는이 libmyname.so.A을 할 수 있도록 라이브러리 파일 이름이 libmyname 수 있도록 : 표준이 불리는이 문자열 및 버전 관리 규칙은 사실 이후 사실상의 표준이되었고, 이런 식 것을 말한다

참고. so.AB 또는 libmyname.so.ABC (MacOSX에서는 libmyname.ABdylib). 소프트 링크를 libmyname.so.A.B[.C]?에서 libmyname.so.A으로 만듭니다.

A은 라이브러리의 ABI가 동일하게 유지되는 동안 동일하게 유지됩니다.

B (또는 B.C)은 부 버전이됩니다.

Linux에서는 라이브러리 버전이 패키지 버전 번호와 동일하다는 것이 일반적입니다.이것은 장단점이 있습니다.

libtool이 형식화

GNU의 libtool이는 동적 라이브러리를 구축하기 위해 많이 사용하고, 더 공식적인 버전 관리 시스템을 가지고 있으며, 그것을 위해 강력한 논리를 가지고있다. sonames에 대한 libtool 버전 ​​관리 시스템은 매우 잘 작동하며 복잡한 라이브러리가 상황을 똑바로 유지하기 위해 채택합니다. libtool이 아래

는 버전은 아래에로이다 :

현재 libmylib-. 릴리스. 아이디어를 libtool에서

연령은 라이브러리 진화가 추가 기능을 제거하는 것입니다.

라이브러리를 개발한다고 가정 해 보겠습니다. 0.0.0과 같은 버전을 사용하여 시작하십시오.

이제 몇 가지 버그를 수정했다고 가정하면 릴리스가 개로 늘어납니다.

그래서 새 이름은 libmylib.0.1.0 또는 libmylib.0.2.0 등이 될 것입니다. 버그를 수정하지만 ABI를 변경하지 않는 모든 릴리스에 대해.

길을 따라 가세요. 아! 이 하위 기능을 더 잘 수행 할 수 있었으므로 새로운 기능 세트를 추가하여 더 나은 기능을 수행 할 수 있습니다. 그러나 다른 사용자가 여전히 라이브러리를 사용하고 있기 때문에 기존의 (더 이상 사용되지 않는) 기능을 그대로 두었습니다.

규칙은 아래 같습니다

1. 시작의 버전 정보와 함께 각 libtool이 라이브러리에 대한 '0 : 0 : 0'.

2. 소프트웨어의 공개 릴리스 직전에만 버전 정보를 업데이트하십시오. 더 빈번한 업데이트는 불필요하며 은 현재 인터페이스 번호가 더 빨라진다는 것을 보증합니다.

3. 마지막 개정 이후 라이브러리 소스 코드가 변경된 경우 개정판이 증가합니다 ('c : r : a'는 'c : r + 1 : a'가됩니다).

4. 어떤 인터페이스가 추가, 삭제, 또는 마지막 업데이트 이후로 변경 한 경우, 현재 증가하고있는 인터페이스가 마지막 공개용 이후에 추가 된 경우 0

5. 로 설정 개정 후 증가 나이.

6. 마지막 공개 릴리스 이후 인터페이스가 제거되었거나 변경된 경우 age를 0으로 설정하십시오.

예를 들어 버전 1 또는 버전 3, 버전 4.2, 반대로 당신은 libtbb.so의 libtool documentation