☰

사용자 정의 바이너리/문서 이름으로 bash(또는 대체 Linux 패키지) 빌드

tag-icon • tag-icon bash compiling rpm configure autoconf
사용자 정의 바이너리/문서 이름으로 bash(또는 대체 Linux 패키지) 빌드

저는 기본적으로 3.2.25를 사용하는 Enterprise Linux 5 시스템에서 사용하기 위해 Bash 4.2를 RPM 패키지로 빌드하려고 합니다. 이것은 성공적으로 작동했지만 시스템 패키지와의 충돌을 피하고 시스템/기타 스크립트가 호환 가능한 bash3을 계속 사용할 수 있도록 두 버전이 시스템에 공존하기를 바랍니다.

내 계획은 다음과 같습니다.

  • 패키지 이름을 "bash4"로 바꾸세요. "bash"와 충돌하지 않거나 "sh"를 제공하세요.
  • 바이너리 이름 "bash4"로 빌드하도록 bash를 구성하고 그에 따라 문서 또는 지원 파일의 경로를 변경합니다.

이론적으로 이것은 간단합니다. Vim은 구성 스크립트에 바이너리 접두사/접미사를 제공하지만 bash에는 이 기능이 없는 것 같습니다. 내가 찾은 가장 가까운 것은 실행 가능한 확장자(예: Windows의 .exe)에 대한 지원을 제공하는 automake의 EXEEXT이지만 실제로는 내가 원하는 작업에 맞게 설계되지 않았으며 문서 문제를 해결하지 않습니다.

답변1

bashautoconf 버전(2.63)은 약간 오래된 버전(2008년 9월) 이지만 지원 --program-transform-name및 --program-suffix기능을 제공합니다. 불행히도 bash 빌드 프로세스는 이러한 기능을 사용하지 않습니다.자세한 지침은 문서에 제공됩니다., 매뉴얼 페이지의 빌드 타임 처리를 허용하기 위해 매개변수를 사용하지도 않습니다.

파일 개수와 변경 사항이 적기 때문에 설치 전에 변경 사항을 적용하기 위해 작은 스크립트를 작성하는 반 수동 접근 방식을 권장합니다. 선택해서 사용하시면 됩니다시계 설치설치 과정에서 모든 것을 캡처해야 하지만 bash실제로는 거의 캡처하지 마십시오. (FWIW, FreeBSD bash 포트와 Debian bash 패치를 잠깐 살펴보았는데 적절한 수정 징후가 없었습니다.)

빌드를 깨는 재미있는 방법인 경우가 많지만할 수 있는여기에서 학대당함 EXEEXT:

ac_cv_exeext=42 ./configure [...]
make
./bash42 -c 'echo $BASH_VERSION'
4.2.42(1)-release

이름을 바꾸는 것만으로도 절약할 수 있으므로 권장하지 않습니다 ;-)

또한 다음과 같은 이점도 있습니다.

./configure [...]
make -e Program=bash42

이는 생성된 스크립트의 변경 사항도 반영하기 때문입니다 bashbug(이름은 바뀌지 않았지만).

관련 정보