배포판 이름, glibc, 컴파일러: 설치 프로그램이 확인하는 것

설치 프로그램이 “unsupported distribution”을 출력하고, 문자열 하나를 고치면 일 분 뒤 로더 오류로 실패할 때까지 진행됩니다. 그 순서가 바로 알아볼 만한 증상입니다. 첫 실패는 인식 검사였고, 두 번째는 호환성 경계입니다. 같은 터미널에 우연히 나타난 서로 다른 두 문제입니다. 검사를 고치는 일은 첫 번째에서 두 번째로 옮겨 줄 뿐입니다.

증상: 설치 프로그램이 파생 배포판에서 멈춘다

배포판 이름을 읽고 계속하기를 거부하는 스크립트는 작성자가 당신의 파생판을 시험하지 않았다고 말하고 있습니다. 그것은 기술적 사실이 아니라 지원 방침이며, 패키지가 잘 돌아갔을 것이라는 점에서 흔히 틀립니다.

문제는 우회책이 계획이 될 때 시작됩니다. 식별 파일을 바꾸면 검사는 통과하고, 패키지는 실제로 설치된 런타임을 상대로 로드되거나 로드되지 않습니다. 거기서 실패하면 식별 정보를 더 고쳐도 소용없습니다.

그래서 유용한 행동은 설치 프로그램이 어떤 질문을 했는지 알아내고, 그다음 그 답이 중요했을지 알아내는 것입니다. 이는 별개의 두 조사이며, 패키지가 동작할지를 예측하는 것은 두 번째뿐입니다.

사람들이 시스템 버전이라고 부르는 세 가지 버전

배포판 릴리스는 패키징된 환경을 가리킵니다. C 라이브러리 버전은 런타임 구현과 그 릴리스를 가리킵니다. 컴파일러 버전은 툴체인을 가리킵니다. 대화에서는 셋 다 “시스템 버전”이라고 부르지만, 설치 프로그램 안에서는 서로 바꿔 쓸 수 없습니다.

cat /etc/os-release
ldd --version | head -1
gcc --version | head -1
uname -m

미리 빌드된 애플리케이션은 링크될 당시 존재하던 런타임을 기대합니다. 호스트의 컴파일러를 바꿔도 다시 링크되지 않으며, 더 새로운 툴체인도 바이너리가 요구하는 로더 심볼을 바꾸지 않습니다. 아키텍처는 또 별개로 중요합니다. 64비트 시스템에서 32비트 패키지가 실패하는 이유는 어떤 버전 문자열로도 설명되지 않습니다.

네 가지 출력을 보고서와 함께 보관하십시오. 모으는 데 십 초면 충분하고, 메인테이너가 메일로 물어볼 질문 대부분에 답이 됩니다.

검사가 아니라 오류를 읽으십시오

첫 실행 오류가 증거입니다. 공유 객체가 없다거나 로더가 만족시킬 수 없는 심볼 버전이라는 메시지는 런타임 의존성 문제입니다. 배포판 이름을 되풀이하는 메시지는 다른 자리에서 다시 나타난 인식 검사입니다.

동적 링커 문서에는 라이브러리 검색이 어떻게 동작하고 로더가 어디를 찾는지 설명되어 있습니다. 배포판 레이블을 바꿔도 그 검색 경로에 디렉터리가 추가되지는 않습니다. 그래서 두 번째 실패가 첫 번째와 무관해 보이는 것입니다.

내려받은 실행 파일에 ldd 를 흔한 첫 단계로 쓰지 마십시오. 그 자체 매뉴얼이 어떤 상황에서는 프로그램을 실행할 수 있다고 경고하며, 신뢰할 수 없는 설치 프로그램을 실행하는 것이 바로 그 경고가 말하는 경우입니다.

문자열을 고쳐도 도움이 되지 않는 이유

운영 체제 식별 정보를 속이면 기계의 모든 프로그램이 자신을 보는 방식이 달라집니다. 패키지 관리자, 지원 도구, 다른 애플리케이션이 같은 파일을 읽으며, 한 설치 프로그램을 만족시키는 값이 몇 달 뒤 다른 무언가를 혼란스럽게 할 수 있습니다.

호스트 라이브러리를 다른 배포판의 파일로 바꾸는 것은 더 나쁩니다. 무관한 소프트웨어를 깨뜨릴 수 있고, 패키지 관리자에게는 보이지 않으며, 아무도 적지 않는 유지보수 계획을 필요로 합니다. 그런 변경은 제한적인 설치 프로그램 하나로 정당화되지 않습니다.

검사가 정말 인식 결함이라면 메인테이너가 확인하고 지원되는 수정을 설명할 수 있습니다. 결함이 아니라면 지원되는 경로는 당신의 플랫폼을 위한 빌드이며, 문자열을 고쳤다는 이유로 그 답이 달라지지는 않습니다.

메인테이너가 조치할 수 있는 보고서를 쓰십시오

배포판과 릴리스, 아키텍처, VPN 릴리스, 거부된 정확한 조건, 그리고 거기까지 갔다면 첫 런타임 오류를 기록하십시오. 무엇이든 수정했는지 적으십시오. 수정된 시스템에서 나온 보고서는 다른 보고서이기 때문입니다.

원래 설치 프로그램을 그대로 두고 우회하는 대신 검사를 설명하십시오. 그 구분이 있어야 메인테이너가 지나치게 좁은 인식 규칙과 실제 바이너리 호환성 경계를 분리할 수 있습니다. 둘은 아주 다른 버그이고 수정도 아주 다릅니다.

당신의 플랫폼이 지원되지 않는다는 답이 돌아온다면 그것도 쓸모 있는 결과입니다. 애초에 문제가 아니었던 식별 파일에 저녁을 하나 더 쓰는 대신 지원되는 빌드를 찾으라고 알려 주는 것입니다.