2016-10-28 8 views
1

RPM은 기본적으로 제공된 .so 바이너리 집합을 패키징하여 RPM을 통해 설치되는 내부 애플리케이션에서 사용할 수 있도록합니다.rpmbuild는 심볼릭 링크 공유 객체를 포함하지 않습니다.

라이브러리 중 하나에는 libexample_base.so 및 libexample_debug.so와 같은 여러 버전이 있습니다. 현재 RPM에 포함되어 있으므로 (개발자가 필요에 따라 서로 전환 할 수 있도록) 패키지를 만들려고합니다. 그러나 % install 중에 심볼릭 링크를 만들어 libexample_base.so를 기본 버전으로 선택하면 다음과 같이 패키지됩니다. RPM에있는 파일.

%install 
[... Copy the files from the tarball to the buildroot ...] 
pushd %{buildroot}%{_libdir} 
ln -sf libexample_base.so libexample.so 
popd 

하나의 문제를 제외하고이 기능은 훌륭합니다. 그것은 자동 종속성 생성을 사용하고 있으며 실제 파일이있는 모든 공유 객체를 제공하지만 심볼릭 링크가 % 파일에 있고 제대로 설치되었지만 libexample.so를 제공하지 않습니다. 불행하게도, 벤더 라이브러리는 SONAME 엔트리를 제공하지 않으며, 바이너리 블롭이기 때문에 쉽게 추가 할 수 없기 때문에 RPM은 실제 파일 이름에 의존합니다. 모든 다운 스트림 RPM에는 libexample.so가 필요하며,이 RPM은 요구 사항으로 나열되어 있지 않으므로 실제로 작동하더라도 (ldconfig는 libexample.so를 문제없이 찾을 수 있음) 누락 된 종속성으로 인해 설치를 거부합니다.

rpmbuild가 심볼릭 링크를 구문 분석하도록 프롬프트하는 방법에 대한 아이디어가 있습니까?

+0

하나의 해킹 된 해결 방법을 찾았습니다. symlink 대신 파일을 하드 링크하면 작동합니다. 나는 정말로 그렇게하지 않을 것이다. 왜냐하면 그것은 전체 파일을 두 번 포함하고 링크가 가리키는 곳을 변경할 수 있도록 의도 되었기 때문이다. – matthock

+0

명시 적으로'ln -s'를 호출하는 대신, spec 파일의 % post 섹션에/usr/sbin/ldconfig를 넣어야합니다. –

답변

1

추가 조사가 끝나면, 내가하려고하는 일이 이유뿐만 아니라 가능하지 않다고 결정했습니다. 핵심 문제는 올바르게 생성 된 공유 객체를 SONAME 항목과 함께 처리하기 위해 빌드 된 rpmbuild의 동작입니다. 명시 적으로 제공되는 .so로 끝나는 공유 객체에 대한 심볼릭 링크는 나열되지 않습니다. 이는 정상적인 동작에서 버전이있는 공유 객체 (.so. #. #)를 가리키고 응용 프로그램이 해당 버전 객체에 의존하기 때문입니다. symlink는 링커에게 최신 항목을 찾는 방법을 제공하기 위해 devel 패키지에 포함되도록되어 있습니다.

RPM과 GCC 둘 다에 대해 SONAME이 없으면 파일 이름을 사용하여 올바르게 수행되지 않은 경우의 백업으로 사용되는 두 번째 케이스로 실행 중입니다. GCC를 실행할 때 파일 이름은 libexample.so (실제 파일과의 심볼릭 링크)이며 SONAME이 없으므로 libexample.so와 연결되도록 구성됩니다. rpmbuild는 이것을보고 응용 프로그램 RPM에 필요한 것으로 설정합니다. 그러나 rpmbuild는 devel 링크처럼 보이기 때문에 rpm 라이브러리에서 해당 이름을 명시 적으로 제외하므로 두 RPM을 조정할 방법이 없습니다.

해결책? 지금은 필자가 해결 방법을 사용하고 있습니다. 파일의 복사본을 만드는 것입니다. 그 이름을 가진 실제 파일이있을 때 작동합니다. 올바른 방법은 공유 객체를 수정하는 것입니다.하지만이를 업스트림 벤더에게 전달해야합니다.

+0

돌아와서 대답 해 주셔서 감사합니다. 이제 모든 링크가 작동 했으므로 RPM에 심볼릭 링크를 남겨두고 spec 파일에 "Provides : libexample.so'"를 추가 할 수 있습니까? –

+0

이것은 저에게 효과적이지만 더 좋은 방법이 있어야합니다 ... –