저는 이런 질문을 계속해서 봅니다.
우리가 일반적으로 추진하는 솔루션 유형은 다음과 같습니다.
이것이 정말로 우리가 할 수 있는 최선인가? 이와 같은 디렉터리에 압축을 풀고 /opt/myglibc설정하거나 $LD_LIBRARY_PATH문제 없이 원하는 애플리케이션을 실행할 수 있는 GLIBC의 바이너리 버전이 있습니까?
최신 버전의 Chrome(28+)과 같은 애플리케이션에는 GLIBC 2.14가 필요한 것 같습니다.
노트:이 게시물의 제목은 다음과 같습니다.Google Chrome 29 출시 – RHEL/CentOS 6 및 Fedora 19/15에 설치됨마침내 이것에 대해 생각하게되었습니다.
인용하다
답변1
glibc가 아닌 다른 라이브러리라면... 빠른 방법은 없을 것 같습니다. glibc는 모든 것이 "하드코드"되어 있는 곳이기 때문입니다. glibc는 커널 버전에 적합하며 해당 로더는 실제로 LD_LIBRARY_PATH.
아마도 올바른 방법은 다음과 같습니다.
LD_LIBRARY_PATH="/opt/myglibc/;..." /opt/myglibc/ld-linux.so.2 the_program`
그러나 이것이 작동하는지 확실하지 않습니다.
어쨌든 대체 glibc를 사용하려면 아직 구현되지 않은 프레임워크가 필요하다고 생각합니다. 검색 경로가 때때로 연결되어 있고 glibc는 항상 OS/커널에 적합해야 하므로 범용 바이너리가 있을 수 없기 때문입니다. IMO. 데비안의 다중 아키텍처는 이것이 사소한 일이 아니지만 여전히 수행될 수 있음을 보여줍니다. 대상 아키텍처 외에 라이브러리를 식별하는 다른 방법이 있는 경우.
이 사이트는 나에게 또 다른 관련 주제를 제공했습니다.
거기에서 허용되는 답변에는 다음과 같은 프로그램에 대한 링크가 포함됩니다.RTDI, glibc 문제를 해결하는 것 같습니다. 2004년 버전이므로 더 이상 링커에서 직접 실행되지는 않지만 살펴볼 가치가 있습니다. 소스는 GPLv2입니다.
여호와, 여호와
내 친구가 공유 라이브러리의 실제적인 사용이 과대평가되어 있다는 생각을 제기한 적이 있습니다. 그는 요점을 가지고 있습니다. 공유 라이브러리는 훌륭하고 컴퓨터 메모리를 중복 항목으로 채우지 않지만 단일 애플리케이션 인스턴스를 고려하면 불과 몇 MB에 불과합니다.
자체 glibc 제공과 같은 우리 측의 조치가 필요한 애플리케이션은 소수에 불과합니다. 긴 분석을 저장하기 위해 그 자체로 유용하고 작업을 완료하는 "인스턴트 앱"이라고 부르겠습니다. 예를 들어, 웹 브라우저, 메일 사용자 에이전트, 오피스 제품군, 음악 플레이어를 사용하면 사용자당 몇 개의 인스턴스만으로 원하는 것을 얻을 수 있습니다. 반면에 시스템 서비스, 창 관리자, 심지어 전체 데스크톱 환경도 중요하지만 단지 지원적일 뿐이며 사람들이 자신만의 glibc를 기꺼이 제공할 만큼 드물거나 중요하지 않은 경우가 많습니다.
"인스턴트 앱"의 수는 확실히 사용자당 상당히 적으며, 오늘날 생산되는 "기본" 운영 체제 및 데스크톱 환경에 비해 상대적으로 적습니다. Chrome, Firefox와 같은 직접 애플리케이션을 정적으로 컴파일하는 경우 평균 시스템의 추가 메모리 요구 사항은 수백 MB입니다. 이 주장은 오늘날 많은 GB 시스템에서는 별로 의미가 없으므로 직접 애플리케이션의 정적 연결이 옵션일 수 있습니다.
또한 매우 빠른 스왑 인/아웃을 허용하고 증가된 메모리 요구 사항을 처리하는 데 도움이 되는 스왑 공간 및 SSD 개념도 있습니다.
여기에서 논의된 glibc 문제는 실제로 정적 링크로 해결되지는 않지만 웹 브라우저와 같은 응용 프로그램의 경우 X 프로토콜, 일부 사운드 데몬 및 일부 커널 방법을 유일한 인터페이스로 사용하여 자체 포함 배포 형식을 생각할 수 있습니다. 장점은 라이브러리 버전이 호환되지 않는 경우가 적다는 것입니다.