왜 정적으로 연결된 glibc가 낙담하는가?
대부분의 온라인 소스는 glibc를 정적으로 연결할 수 있지만 그렇게 하는 것을 주저한다고 명시한다. 예를 들어 centos package repo:
glibc 정전기 패키지는 정전기 연결을 위한 C 라이브러리 정전기 라이브러리를 포함하고 있다.정적으로 연결하지 않는 한, 이것들은 필요하지 않다. 그것은 매우 낙담된다.
이런 소식통들은 왜 그것이 나쁜 생각인지 거의 말하지 않는다.
다른 답변에 제시된 이유는 맞지만 가장 중요한 이유는 아니다.
glibc가 정적으로 연결돼서는 안 되는 가장 중요한 이유는 nss(이름 서비스 스위치) 모듈과 변환을 로딩하기 위해 광범위한 내부 활용을 하기 때문이다.모듈 자체가 C 라이브러리 기능을 가리킨다.메인 프로그램이 C 라이브러리와 동적으로 연계되어 있다면 그건 문제가 되지 않는다.하지만 만약 메인 프로그램이 C 라이브러리와 정적으로 연결되어 있다면,dlopen모듈 부하 요구 사항을 충족하려면 C 라이브러리의 두 번째 사본을 로드해야 한다.
이것은 당신의 "정적으로 연결된" 프로그램이 여전히libc.so.6 NSS에 iconv또는 어떤 모듈 자체, 그리고 모듈들이 필요로 할 수 있는 다른 동적 라이브러리들, 예를 들어ld-linux.so.2libresolv.so.2, 등. 이것은 사람들이 프로그램을 정적으로 연결할 때 보통 원하는 것이 아니다.
그것은 또한 정적으로 연결된 프로그램이 주소 공간에 C 라이브러리의 복사본 2개를 가지고 있고, 그들은 누구를 두고 싸울지도 모른다는 것을 의미한다.stdout버퍼는 누가 전화를 걸어야 하는지를 사용한다.sbrk0이 아닌 논쟁으로, 그런 종류의 것.glibc 내부에는 이 일을 성사시키려고 하는 방어논리가 산적해 있지만, 그것이 제대로 작동하도록 보장된 적은 없다.
프로그램이 이 문제를 걱정할 필요가 없다고 생각할 수도 있다.getaddrinfo또는iconv로케일 지원에서 사용iconv내부, 즉 어떤 기능이든 호출을 트리거할 수 있다는 의미dlopen사용자 환경 변수 설정에서 제어하는 것이 아니라
그리고 만약 당신의 프로그램이 전화를 한다면iconv예를 들어, 특히 "정적으로 연결된" 실행 파일이 한 디스트로에 구축되었다가 다른 디스트로에 복사될 때 상황은 더욱 악화된다.그iconv모듈은 때때로 서로 다른 디스트로의 다른 장소에 위치하기 때문에, 예를 들어, Red Hat 디스트로에 구축된 실행 파일이 데비안 디스트로는 제대로 실행되지 못할 수 있다. 이것은 사람들이 정적으로 연결된 실행 파일로부터 원하는 것과 정반대다.
프로그램/glibc인터페이스는 POSIX, C 및 C++ 표준 등에 의해 표준화 및 문서화된다.예를 들어,fopen()함수는 C 표준에 따라 동작한다.pthread_mutex_lock()POSIX 단위로.
그glibc/커널 인터페이스가 표준화되지 않음.한다fopen()사용하다open()덫에 걸려서?아니면 그것을 사용하는가?openat()아니면 다른 거?그것은 내년에 무엇을 사용할 것인가?당신은 모릅니다.
만약glibc 것을 /인테스트레스, 정적 는 로그램이다.glibc더 이상 안 먹힐 거야
15년 이상 전에 Solaris는 의 모든 정적 버전을 제거했다.libc바로 이런 이유로
Solaris 10에서는 더 이상 정적 실행 파일을 빌드할 수 없다.ld(1)가 정적 링크나 아카이브 사용을 허용하지 않는 것이 아니라, 단지 libc.so.1의 아카이브 버전인 libc.a가 더 이상 제공되지 않는 것이다.이 라이브러리는 사용자 땅과 커널 사이의 인터페이스를 제공하며, 이 라이브러리가 없으면 어떤 형태의 응용 프로그램도 만들기가 어렵다.
우리는 한동안 사용자들에게 고정적인 연결을 하지 말라고 경고해 왔으며, 특히 libc.a와의 연결은 문제가 되어왔다.모든 Solaris 릴리스 또는 업데이트(일부 패치까지)는 libc.a에 대해 구축된 일부 애플리케이션을 실패하게 만들었다.문제는 libc가 애플리케이션을 사용자/커널 경계에서 분리하도록 되어 있는데, 이 경계는 릴리스에서 릴리스로 변경될 수 있다.
애플리케이션이 libc.a에 대해 구축된 경우, 애플리케이션이 참조하는 커널 인터페이스는 아카이브에서 추출되어 애플리케이션의 일부가 된다. 따라서 이 애플리케이션은 사용되는 커널 인터페이스와 동기화되는 커널에서만 실행될 수 있다. 이러한 인터페이스가 변경될 경우 애플리케이션은 불안정한 토대를 밟고 있다.
...
편집:
리눅스 커널 인터페이스의 안정성을 심각하게 과대평가하고 있는 것 같다.자세한 내용은 Linux 커널 API 변경/추가 내용을 참조하십시오.요약하면:
참조URL: https://stackoverflow.com/questions/57476533/why-is-statically-linking-glibc-discouraged
'programing' 카테고리의 다른 글
| JSON의 끈을 어떻게 벗어나야 할까? (0) | 2022.04.23 |
|---|---|
| Vue.js 계산 함수에서 다중 차원 배열 필터링 (0) | 2022.04.23 |
| 값 쌍의 Java 컬렉션?(튜플이요?) (0) | 2022.04.23 |
| Vuejs는 이것을 타이프로 표현한다.$refs..값이 존재하지 않음 (0) | 2022.04.23 |
| 최대 절전 모드 사용 시 매개 변수 값으로 쿼리 문자열을 인쇄하는 방법 (0) | 2022.04.23 |