Linux 정적 링크가 죽었습니까?
사실, Linux의 -static gcc 플래그는 현재 작동하지 않습니다. GNU libc FAQ에서 인용하겠습니다.
2.22. 정적으로 연결된 프로그램조차도 나에게 허용되지 않는 공유 라이브러리가 필요합니다. 어떡해?
{AJ} NSS (자세한 내용은`info libc "Name Service Switch" '입력)는 공유 라이브러리 없이는 제대로 작동하지 않습니다. NSS는 프로그램을 다시 연결하지 않고 하나의 구성 파일 (/etc/nsswitch.conf) 만 변경하여 다른 서비스 (예 : NIS, 파일, db, hesiod)를 사용할 수 있습니다. 유일한 단점은 이제 정적 라이브러리가 공유 라이브러리에 액세스해야한다는 것입니다. 이것은 GNU C 라이브러리에 의해 투명하게 처리됩니다.
해결책은 --enable-static-nss로 glibc를 구성하는 것입니다. 이 경우 서비스 dns 및 파일 만 사용하는 정적 바이너리를 만들 수 있습니다 (이를 위해 /etc/nsswitch.conf 변경). 이러한 모든 서비스에 대해 명시 적으로 링크해야합니다. 예를 들면 :
gcc -static test-netdb.c -o test-netdb \ -Wl,--start-group -lc -lnss_files -lnss_dns -lresolv -Wl,--end-group이 접근 방식의 문제는 NSS 루틴을 사용하는 모든 정적 프로그램을 모든 라이브러리와 연결해야한다는 것입니다.
{UD} 사실,이 옵션으로 컴파일 된 libc가 NSS를 사용하고 있다고 더 이상 말할 수 없습니다. 더 이상 스위치가 없습니다. 따라서이되어 매우 권장 하지 이 시스템의 일관성에 대한 프로그램의 동작을하게하기 때문에 --enable-정전기 NSS를 사용합니다.
그 사실과 관련하여 Linux에서 완전한 기능의 정적 빌드를 만드는 합리적인 방법이 있습니까? 아니면 Linux에서 정적 링크가 완전히 죽었습니까? 나는 정적 빌드를 의미합니다.
- 동적 빌드와 똑같은 방식으로 동작합니다 (일관되지 않은 동작을 가진 static-nss는 악합니다!).
- glibc 환경 및 Linux 버전의 합리적인 변형에서 작동합니다.
그 사실과 관련하여 Linux에서 완전한 기능의 정적 빌드를 만드는 합리적인 방법이 있습니까? 아니면 Linux에서 정적 링크가 완전히 죽었습니까?
역사적인 참조를 어디서 찾을 수 있는지 모르겠지만 네, GNU 시스템 에서는 정적 링크 가 작동하지 않습니다 . (libc4 / libc5에서 libc6 / glibc 2.x로 전환하는 동안 죽었다고 생각합니다.)
이 기능은 다음과 같은 관점에서 쓸모없는 것으로 간주되었습니다.
보안 취약점. 정적으로 연결된 응용 프로그램은 libc의 업그레이드도 지원하지 않습니다. 앱이 lib 취약점을 포함하는 시스템에 링크 된 경우 정적으로 링크 된 실행 파일 내에서 영구적으로 유지됩니다.
코드 팽창. 많은 정적으로 연결된 응용 프로그램이 동일한 시스템에서 실행되는 경우 모든 응용 프로그램이 자체적으로 모든 복사본을 포함하기 때문에 표준 라이브러리가 재사용되지 않습니다. (
du -sh /usr/lib문제의 정도를 이해하십시오.)
10-15 년 전의 LKML 및 glibc 메일 목록 아카이브를 파헤쳐보십시오. 나는 오래 전에 LKML과 관련된 것을 보았다고 확신합니다.
나는 이것이 매우 성가신 일이라고 생각하고 특정 사용 사례를 처리하는 데 문제가 있기 때문에 기능을 "쓸모없는"이라고 부르는 것이 오만하다고 생각합니다. glibc 접근 방식의 가장 큰 문제는 시스템 라이브러리 (gconv 및 nss)에 대한 경로를 하드 코딩하기 때문에 사람들이 빌드 된 것과 다른 Linux 배포판에서 정적 바이너리를 실행하려고하면 중단된다는 것입니다.
어쨌든 GCONV_PATH를 적절한 위치를 가리 키도록 설정하여 gconv 문제를 해결할 수 있습니다. 이렇게하면 Ubuntu에서 빌드 된 바이너리를 가져와 Red Hat에서 실행할 수 있습니다.
정적 연결은 Linux 세계에서 많은 사랑을받지 못하는 것 같습니다. 여기 내 생각입니다.
정적 링크의 매력을 보지 못하는 사람들은 일반적으로 커널 영역과 하위 수준 운영 체제에서 작업합니다. 많은 * nix 라이브러리 개발자들은 끊임없이 변화하는 수백 개의 라이브러리를 함께 연결하려는 피할 수없는 문제를 처리하는 데 평생을 보냈습니다. 그들이 편안하게 수행하는 백 플립을 알고 싶다면 autotools를 살펴보십시오.
그러나 다른 사람들은 이것에 대부분의 시간을 할애해서는 안됩니다. 정적 연결은 라이브러리 변동으로 인해 버퍼링되는 데 큰 도움이됩니다. 개발자는 새 라이브러리 버전이 나타나는 순간 강제로 수행하지 않고 소프트웨어의 일정에 따라 소프트웨어의 종속성을 업그레이드 할 수 있습니다. 이는 필연적으로 의존하는 많은 하위 수준 라이브러리의 흐름을 제어해야하는 복잡한 사용자 인터페이스가있는 사용자 대면 응용 프로그램에 중요합니다. 이것이 제가 항상 정적 연결의 팬이되는 이유입니다. 교차 컴파일 된 이식 가능한 C 및 C ++ 코드를 정적으로 연결할 수 있다면 복잡한 소프트웨어를 전 세계적으로 계속 성장하는 다양한 장치에 더 빠르게 제공 할 수 있으므로 세상을 거의 굴처럼 만들 수 있습니다.
다른 관점에서 볼 때 동의하지 않는 것이 많으며 오픈 소스 소프트웨어가 모두를 허용한다는 것이 좋습니다.
NSS 서비스에 동적으로 연결해야한다고해서 다른 라이브러리에 정적으로 연결할 수 없다는 의미 는 아닙니다 . 자주 묻는 질문 말하는 것을 모두도 "정적"연결 프로그램이 즉 일부 동적 링크 라이브러리. 정적 링크가 "불가능"하거나 "작동하지 않는다"는 말이 아닙니다.
정적 연결이 다시 부상하고 있습니다!
- 많은 (대부분?) Go 프로그래밍 언어 실행 파일이 정적으로 연결되어 있습니다.
- 향상된 이식성과 이전 버전과의 호환성 은 인기있는 이유 중 하나입니다.
- 다른 프로그래밍 언어는 정적 링크를 정말 쉽게 만들기 위해 비슷한 노력을하고 있습니다. 예를 들어 Haskell (저는이 노력을하고 있습니다 ).
- 구성 가능한 Linux 배포판 / NixOS / nixpkgs 와 같은 패키지 세트를 사용하면 패키지의 많은 부분
pkgsStatic을 정적으로 링크 할 수 있습니다 (예를 들어, 패키지 세트는 모든 종류의 정적으로 링크 된 실행 파일을 제공 할 수 있습니다). - 정적 링크는 링크 타임에 사용되지 않는 코드 를 더 잘 제거 하여 실행 파일을 더 작게 만들 수 있습니다.
- musl과 같은 libcs 는 정적 링크를 쉽고 정확하게 만듭니다.
- 일부 대형 소프트웨어 업계 리더는 이에 동의합니다. 예를 들어 Google은 정적 링크를 대상으로하는 새로운 libc를 작성하고 있습니다 ( "정적 비 PIE 및 정적 PIE 링크 지원" , "현재 동적로드 및 링크 지원에 투자 할 계획이 없습니다" ).
다른 답변에 추가 :
다른 답변에서 언급 한 이유 때문에 대부분의 Linux 배포판에는 권장되지 않지만 실제로 정적으로 연결된 바이너리를 실행하도록 특별히 만들어진 배포판이 있습니다.
stali 설명에서 :
정적 리눅스는 각 작업과 정적으로 연결된 각 도구 (st, surf, dwm, dmenu와 같은 일부 X 클라이언트 포함)에 대해 손으로 선택한 최고의 도구 모음을 기반으로합니다.
It also targets binary size reduction through the avoidance of glibc and other bloated GNU libraries where possible (early experiments show that statically linked binaries are usually smaller than their dynamically linked glibc counterparts!!!). Note, this is pretty much contrary to what Ulrich Drepper reckons about static linking.
Due to the side-benefit that statically linked binaries start faster, the distribution also targets performance gains.
Statically linking also helps to for dependency reduction.
You can read more about it in this question about static vs dynamic linking.
참고URL : https://stackoverflow.com/questions/3430400/linux-static-linking-is-dead
'code' 카테고리의 다른 글
| MySQL의 텍스트 열에서 문자열 검색 (0) | 2020.12.04 |
|---|---|
| 여러 개의 try-catch 또는 하나? (0) | 2020.12.04 |
| 이름이 259 자보다 긴 파일을 처리하는 방법은 무엇입니까? (0) | 2020.12.04 |
| Tomcat 7을 사용한 @WebServlet 주석 (0) | 2020.12.04 |
| 주어진 문자열에 주어진 하위 문자열이 포함 된 경우 관용적 스칼라 검색 방법은 무엇입니까? (0) | 2020.12.04 |