/lib32/libc.so.6에 두 개의 "fopen"기호가있는 이유는 무엇입니까? 여기

Question

nm -D /lib32/libc.so.6 | grep '\<fopen\>' 
0005d0c0 T fopen 
00109750 T fopen 

readelf -s /lib32/libc.so.6 | egrep '0005d0c0|00109750' 
181: 0005d0c0 50 FUNC GLOBAL DEFAULT 12 fopen@@GLIBC_2.1 
182: 00109750 136 FUNC GLOBAL DEFAULT 12 fopen@GLIBC_2.0 
679: 0005d0c0 50 FUNC GLOBAL DEFAULT 12 _IO_fopen@@GLIBC_2.1 
680: 00109750 136 FUNC GLOBAL DEFAULT 12 _IO_fopen@GLIBC_2.0 

내 질문은 :

1. /lib32/libc.so.6이 두 fopen을 기호가 왜? 동일한 대상 파일에서 동일한 기호는 금지되어야합니다.

2. 왜 readelf는 fopen을 @@ GLIBC_2.1을 버리고 대신하면 fopen의 fopen@GLIBC_2.0 -s?

감사

같은 기호의

Answer 1

사실 여러 정의는 잘하고 여러 가지 방법으로 발생할 수 있습니다. 그 중 하나 (여기서는 그렇지 않습니다)는 약한 기호입니다. 여기에 어떻게됩니까

는 glibc는 동적 링커가 심볼 버전을 지원하며, glibc는 그를 사용한다는 것입니다. glibc 2.1에서 fopen 버전을 내보내고 glibc 2.0에서 이전 버전과 호환되는 버전을 다른 인터페이스로 내 보냅니다. 동적 링크시

응용 프로그램은 특정 버전 또는 기본 하나를 선택할 수 있습니다. 먼저 전통적으로 처리 된 방법 이진 호환성 이해할 필요가 여기에 무슨 일이 일어나고 있는지 이해하기 위해

Answer 2

.

"외부 버전"으로 사용되는 메커니즘입니다. libfoo.so.1으로 시작했고 기존 함수의 ABI를 변경해야 할 때 libfoo.so.2을 사용해야했습니다.

libfoo.so.2 이전 ABI와 libfoo.so.1를 계속 사용하기 전에 연결되어 있던 응용 프로그램, 새로운 ABI와 libfoo.so.2을 사용하는 새로운 aplications에.

이

모든 몇 가지 세부 here에 설명되어 있습니다.

그러나 glibc는 extension을 도입했습니다. 여기서 새로운 라이브러리 (이전 버전과 99 %의 코드를 공유 함) 대신 기존 라이브러리에 새 심볼을 도입했습니다. 확장 된 바이너리가 작동 할 수 있도록하면서, 년의 버전 6 요지 libc.so.6을 허용하고, ABI에 대한 진화 무엇을하는지

. fopen의 특정한 경우

, struct FILE에 호환 변화의 glibc 버전 2.1로 하였다. 의 glibc-2.0 시스템에서 링크 된 바이너리는 이전 struct FILE (다시 사용할 수 있었던 하나)을 사용하고, ( fopen@GLIBC_2.0 별칭 인 경우) _IO_old_fopen 전화를 계속합니다. glibc-2.1 이상에 연결된 바이너리는 새로운 struct FILE을 사용하고 _IO_new_fopen ( fopen@GLIBC_2.1은 별칭 임)으로 전화하십시오.

@@은 현재 기본값 인 기호 버전을 보여주는 단순한 표기입니다.