主链接共享库是一个符号链接?
Main linked shared library is a symlink?
我正在尝试使用 tarball 和 RPM specfile provided in RPMFusion 从源代码构建 libxvidcore
。我有重新包装这个的理由。
%global _hardened_build 1
# can't seem to find debug info for now
%global debug_package %{nil}
%define package_name libxvidcore
%define package_version 1.3.4
%define package_release 1
Name: %{package_name}
Summary: A video decoder and encoder library aimed at providing the best compression efficiency and picture quality possible.
Version: %{package_version}
Release: %{package_release}%{?dist}
License: GPL
Source: http://downloads.xvid.org/downloads/xvidcore-%{package_version}.tar.bz2
%ifarch %{ix86} x86_64
BuildRequires: nasm
%endif
%description
A video decoder and encoder library aimed at providing the best compression efficiency and picture quality possible.
%prep
%setup -n xvidcore
%build
cd build/generic
%configure
make %{?_smp_mflags}
%install
make -C build/generic install DESTDIR=$RPM_BUILD_ROOT
%files
%{_libdir}/libxvidcore.so.4
%{_libdir}/libxvidcore.so.4.3
%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig
%package devel
Summary: libxvidcore-devel
Requires: libxvidcore = %{package_version}
%description devel
libxvidcore-devel
%files devel
%{_includedir}/xvid.h
%{_libdir}/libxvidcore.so
%exclude %{_libdir}/libxvidcore.a
共享库发生了一件非常奇怪的事情。 libxvidcore
提供的文件是:
/usr/lib64/libxvidcore.so.4 -> /usr/lib64/libxvidcore.so.4.3
/usr/lib64/libxvidcore.so.4.3
libxvidcore-devel
包依赖于 libxvidcore
。但是,由于以下错误,我无法安装 libxvidcore-devel
:
$ sudo rpm -ivh RPMS/x86_64/libxvidcore-1.3.4-1.fc23.x86_64.rpm \
RPMS/x86_64/libxvidcore-devel-1.3.4-1.fc23.x86_64.rpm
error: Failed dependencies:
libxvidcore.so.4()(64bit) is needed by libxvidcore-devel-1.3.4-1.fc23.x86_64
如上所述,此共享库 (libxvidcore.so.4
) 是 libxvidcore.so.4.3
的符号链接,后者是真正的 ELF 共享库。由于我没有定义此构建的运行方式,因此我不确定如何解决这个问题。
这是包的布局:
$ rpm -qp --provides --fileprovide RPMS/x86_64/libxvidcore-1.3.4-1.fc23.x86_64.rpm
libxvidcore = 1.3.4-1.fc23
libxvidcore(x86-64) = 1.3.4-1.fc23
/usr/lib64/libxvidcore.so.4
/usr/lib64/libxvidcore.so.4.3
$ rpm -qp --provides --fileprovide RPMS/x86_64/libxvidcore-devel-1.3.4-1.fc23.x86_64.rpm
libxvidcore-devel = 1.3.4-1.fc23
libxvidcore-devel(x86-64) = 1.3.4-1.fc23
/usr/include/xvid.h
/usr/lib64/libxvidcore.so
为了理智起见,以下是 file
报告的共享库信息:
$ file /usr/lib64/libxvidcore.so.4{,.3}
/usr/lib64/libxvidcore.so.4: symbolic link to libxvidcore.so.4.3
/usr/lib64/libxvidcore.so.4.3: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=86c2c379f2ca0dc2f3d3f1306c55de29b1d76738, not stripped
这里有一些关于 libxvidcore 包的更多信息:
$ rpm -qi --qf 'Arch : %{arch}\n' --provides libxvidcore
Name : libxvidcore
Version : 1.3.4
Release : 1.fc23
Architecture: x86_64
Install Date: Mon 25 Jan 2016 01:28:08 AM UTC
Group : Unspecified
Size : 2697952
License : GPL
Signature : (none)
Source RPM : libxvidcore-1.3.4-1.fc23.src.rpm
Build Date : Mon 25 Jan 2016 01:27:50 AM UTC
Build Host : fedora23
Relocations : (not relocatable)
Summary : A video decoder and encoder library aimed at providing the best compression efficiency and picture quality possible.
Description :
A video decoder and encoder library aimed at providing the best compression efficiency and picture quality possible.
Arch : x86_64
libxvidcore = 1.3.4-1.fc23
libxvidcore(x86-64) = 1.3.4-1.fc23
有没有办法正确处理奇怪的符号链接?
首先总结一下库'base'包和对应的库'base'-devel包的习惯组织方式可能会有所帮助:
file package function
-------------------------------------------------------------
libmy.so.x.y my actual implementation
libmy.so.x my SONAME reference for dynamic linking
(relative symlink to mylib.so.x.y)
libmy.so my-devel linker library
(relative symlink to mylib.so.x)
mylib.h my-devel source header
因为链接器库是指向 SONAME 库的符号链接,所以 'base'-devel 包需要 'base' 包是很自然的结果。我认为您的 libxvidcore-devel 包运行正常。当两个包都在 Yum 存储库中并且请求 'base'-devel 包时,Yum 将解决需求并安装它们。
对于开发工作,如果您直接使用 'rpm' 命令来安装软件包,您只需在安装命令中同时指定:
rpm -i <base> <base>-devel
希望对您有所帮助。
问题是 rpm 是 "smart"。它只扫描在 rpmbuild
过程中提供的库具有执行权限的库。
出于某种原因,xvidcore 构建已损坏(在这方面)并且没有安装具有执行权限的库。
解决这个问题(正如我在 %install
部分调用 chmod
进行的快速测试中所做的那样,但您可能应该寻找更好的解决方案)并且您会得到 libxvidcore.so.4()(64bit)
在 --requires
输出中符合预期。
我不知道为什么构建本身不会这样做;我觉得应该可以。
我正在尝试使用 tarball 和 RPM specfile provided in RPMFusion 从源代码构建 libxvidcore
。我有重新包装这个的理由。
%global _hardened_build 1
# can't seem to find debug info for now
%global debug_package %{nil}
%define package_name libxvidcore
%define package_version 1.3.4
%define package_release 1
Name: %{package_name}
Summary: A video decoder and encoder library aimed at providing the best compression efficiency and picture quality possible.
Version: %{package_version}
Release: %{package_release}%{?dist}
License: GPL
Source: http://downloads.xvid.org/downloads/xvidcore-%{package_version}.tar.bz2
%ifarch %{ix86} x86_64
BuildRequires: nasm
%endif
%description
A video decoder and encoder library aimed at providing the best compression efficiency and picture quality possible.
%prep
%setup -n xvidcore
%build
cd build/generic
%configure
make %{?_smp_mflags}
%install
make -C build/generic install DESTDIR=$RPM_BUILD_ROOT
%files
%{_libdir}/libxvidcore.so.4
%{_libdir}/libxvidcore.so.4.3
%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig
%package devel
Summary: libxvidcore-devel
Requires: libxvidcore = %{package_version}
%description devel
libxvidcore-devel
%files devel
%{_includedir}/xvid.h
%{_libdir}/libxvidcore.so
%exclude %{_libdir}/libxvidcore.a
共享库发生了一件非常奇怪的事情。 libxvidcore
提供的文件是:
/usr/lib64/libxvidcore.so.4 -> /usr/lib64/libxvidcore.so.4.3
/usr/lib64/libxvidcore.so.4.3
libxvidcore-devel
包依赖于 libxvidcore
。但是,由于以下错误,我无法安装 libxvidcore-devel
:
$ sudo rpm -ivh RPMS/x86_64/libxvidcore-1.3.4-1.fc23.x86_64.rpm \
RPMS/x86_64/libxvidcore-devel-1.3.4-1.fc23.x86_64.rpm
error: Failed dependencies:
libxvidcore.so.4()(64bit) is needed by libxvidcore-devel-1.3.4-1.fc23.x86_64
如上所述,此共享库 (libxvidcore.so.4
) 是 libxvidcore.so.4.3
的符号链接,后者是真正的 ELF 共享库。由于我没有定义此构建的运行方式,因此我不确定如何解决这个问题。
这是包的布局:
$ rpm -qp --provides --fileprovide RPMS/x86_64/libxvidcore-1.3.4-1.fc23.x86_64.rpm
libxvidcore = 1.3.4-1.fc23
libxvidcore(x86-64) = 1.3.4-1.fc23
/usr/lib64/libxvidcore.so.4
/usr/lib64/libxvidcore.so.4.3
$ rpm -qp --provides --fileprovide RPMS/x86_64/libxvidcore-devel-1.3.4-1.fc23.x86_64.rpm
libxvidcore-devel = 1.3.4-1.fc23
libxvidcore-devel(x86-64) = 1.3.4-1.fc23
/usr/include/xvid.h
/usr/lib64/libxvidcore.so
为了理智起见,以下是 file
报告的共享库信息:
$ file /usr/lib64/libxvidcore.so.4{,.3}
/usr/lib64/libxvidcore.so.4: symbolic link to libxvidcore.so.4.3
/usr/lib64/libxvidcore.so.4.3: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=86c2c379f2ca0dc2f3d3f1306c55de29b1d76738, not stripped
这里有一些关于 libxvidcore 包的更多信息:
$ rpm -qi --qf 'Arch : %{arch}\n' --provides libxvidcore
Name : libxvidcore
Version : 1.3.4
Release : 1.fc23
Architecture: x86_64
Install Date: Mon 25 Jan 2016 01:28:08 AM UTC
Group : Unspecified
Size : 2697952
License : GPL
Signature : (none)
Source RPM : libxvidcore-1.3.4-1.fc23.src.rpm
Build Date : Mon 25 Jan 2016 01:27:50 AM UTC
Build Host : fedora23
Relocations : (not relocatable)
Summary : A video decoder and encoder library aimed at providing the best compression efficiency and picture quality possible.
Description :
A video decoder and encoder library aimed at providing the best compression efficiency and picture quality possible.
Arch : x86_64
libxvidcore = 1.3.4-1.fc23
libxvidcore(x86-64) = 1.3.4-1.fc23
有没有办法正确处理奇怪的符号链接?
首先总结一下库'base'包和对应的库'base'-devel包的习惯组织方式可能会有所帮助:
file package function
-------------------------------------------------------------
libmy.so.x.y my actual implementation
libmy.so.x my SONAME reference for dynamic linking
(relative symlink to mylib.so.x.y)
libmy.so my-devel linker library
(relative symlink to mylib.so.x)
mylib.h my-devel source header
因为链接器库是指向 SONAME 库的符号链接,所以 'base'-devel 包需要 'base' 包是很自然的结果。我认为您的 libxvidcore-devel 包运行正常。当两个包都在 Yum 存储库中并且请求 'base'-devel 包时,Yum 将解决需求并安装它们。
对于开发工作,如果您直接使用 'rpm' 命令来安装软件包,您只需在安装命令中同时指定:
rpm -i <base> <base>-devel
希望对您有所帮助。
问题是 rpm 是 "smart"。它只扫描在 rpmbuild
过程中提供的库具有执行权限的库。
出于某种原因,xvidcore 构建已损坏(在这方面)并且没有安装具有执行权限的库。
解决这个问题(正如我在 %install
部分调用 chmod
进行的快速测试中所做的那样,但您可能应该寻找更好的解决方案)并且您会得到 libxvidcore.so.4()(64bit)
在 --requires
输出中符合预期。
我不知道为什么构建本身不会这样做;我觉得应该可以。