현재 소스에서 GDAL3.0.4 라이브러리를 컴파일하고 설치했는데, 이를 위해서는 Proj6.0.0도 컴파일하고 설치해야 합니다. 좋은 결과.
그래서 다음 부분은 소스에서 다시 컴파일할 필요 없이 다른 서버에 설치할 수 있도록 실행 파일(아마도 바이너리)을 패키지화하는 것입니다.
나는 이것에 정말로 새로운 것입니다. 그래서 전체 폴더를 들어 올려 이동하고, 압축하여 다른 서버로 옮기고, sudo make install새 서버에서 GDAL을 사용해 보았습니다. 작동하는 것 같지만 gdalinfo: error while loading shared libraries: libproj.so.15: cannot open shared object file: No such file or directorygdalinfo 명령을 호출하면 오류가 발생합니다. 이로 인해 proj6에 대한 samw를 수행하게 되었습니다. 하지만 지금은 g++를 사용할 수 없기 때문에 proj6에서도 동일한 작업을 수행해야 합니다.
이 서버에서 리포지토리가 비활성화된 redhat7.7을 실행 중입니다.
내 현재 접근 방식이 완전히 잘못되었을 수 있으므로 조언을 듣고 싶습니다. 궁극적인 목표는 소스에서 컴파일하지 않고 다른 서버에 설치할 수 있도록 gdal 버전을 패키징하는 것입니다.
편집: 그래서 rpm을 통해 빌드할 수 있다는 것을 알았으므로 이에 대한 사양 파일을 직접 작성해야 합니까?
답변1
나는 항상 독서를 권합니다.RPM 패키징 가이드rpm 패키지를 시작하는 사람들을 위한 것입니다.
rpm 사양 파일을 사용하려면 "rpmdevtools" 패키지를 설치하는 것이 좋습니다. 이 가이드에서는 사용할 수 있는 여러 샘플 사양 파일도 제공합니다. 이 rpmdev-newspec명령은 템플릿(Python, Perl, 라이브러리 등)에서 다양한 유형의 패키지를 생성할 수 있습니다.
사양 파일이 있으면 다양한 도구를 사용하여 패키지를 빌드할 수 있습니다. 이 mock명령은 chrooted 빌드 프로세스에서 모든 것을 빌드하므로 빌드 시스템을 오염시키거나 빌드 시스템이 패키징 프로세스를 오염시키는 것에 대해 걱정할 필요가 없기 때문에 이 명령을 선호합니다 . 또한 다른 버전을 빌드할 수도 있으므로 Fedora 시스템에서 RHEL 패키지를 빌드할 수 있습니다.