glibc 2.1.3에서는 사용자가 e2fsck(8) 컴파일 오류로 인해 데이터 손실이 발생했다고 불평할 때 링크 타임 경고를 추가합니다.
"이
llseek기능은 위험할 수 있습니다. 대신 `lseek64를 사용하세요."이로 인해 경고 없는 컴파일이 필요한 경우 함수를 사용할 수 없게 됩니다.
glibc 2.28부터 이 함수 기호는 새로 연결된 응용 프로그램에서 더 이상 사용할 수 없습니다.
이 뒤에 숨겨진 이야기는 무엇입니까?
답변1
문제는 glibc의 llseek헤더 파일에 해당 선언이 없는 기호가 포함되어 있다는 것입니다. e2fsck구성 스크립트는 이 기호를 감지하고 이것이 기능을 사용할 수 있음을 의미한다고 가정합니다. 그러나 암시적 함수 선언이 함수가 예상하는 것과 일치하지 않아 함수 호출이 잘못 컴파일되게 됩니다. 특히 llseek64비트 오프셋이 필요하지만 암시적 선언으로 인해 int매개변수가 생성됩니다. 이로 인해 e2fsck예상과 다른 오프셋에서 변경이 이루어지기 때문에 데이터 손실이 발생합니다.
e2fsck이를 사용하는 이유는 llseeklibc5(Linux의 glibc의 전신)가 이를 선언하고 사용 가능하게 만들기 때문입니다(위치 unistd.h). 따라서 e2fscklibc5에 대해 빌드할 때는 올바르게 작동 llseek하지만 glibc에 대해 빌드할 때는 빌드가 성공하지만 작동하지 않습니다.
이 문제는 e2fsprogs 1.12에서 수정되었으며 변경 로그 항목은 다음과 같습니다.
E2fsprogs는 이제 glibc와 함께 작동합니다(적어도 RedHat 5.0과 함께 제공되는 버전에서는). llseek()가 존재하지 않더라도 ext2fs_llseek() 함수는 이제 i386 ELF 공유 라이브러리에서 작동합니다. 또한 (a) llseek가 libc에 있는지, (b) llseek가 시스템 헤더 파일에 선언되어 있는지 확인하기 위해 명시적인 구성 테스트를 수행합니다. (libc 개발자가 이전 버전의 libc와의 호환성 개념을 이해하지 못한다는 표준 불만 사항을 참조하세요.)
llseek코드가 ;를 사용하려고 시도할 때 경고하도록 C 라이브러리도 변경되었습니다.토론은 메일링 리스트 아카이브에서 찾을 수 있습니다..