CPack Deb: dpkg-shlibdeps fails when library and executable in separate components
If you have an executable E (in component B) which depends on a library L (in component A), then even if the INSTALL_RPATH is correctly set (e.g. $ORIGIN:$ORIGIN/../lib
) and B is declared to depend on A via cpack_add_component
, then dpkg-shlibdeps
will fail to find L when it scans E.
CMake 3.20 provides a hook to hack around this with CPACK_DEBIAN_PACKAGE_SHLIBDEPS_PRIVATE_DIRS
(which, by the way, is incorrectly documented as using EDIT: fixed in !5835 (merged)), but this should be automatic (and this is hard to populate ahead of time without anticipating CPack's directory structure).-d
when it correctly uses -l
What should happen is that the RPATH/RUNPATHs of the executables in a component should be read and their $ORIGIN
s should be mapped appropriately onto the dependent component folders. Suppose that in CPackConfig.cmake
we have:
set(CPACK_COMPONENT_B_DEPENDS A)
And on the filesystem, there are these files:
_CPack_Packages/Linux/DEB/Project-Version/B/usr/bin/E # RPATH=$ORIGIN:$ORIGIN/../lib
_CPack_Packages/Linux/DEB/Project-Version/A/usr/lib/libL.so.Version
CPackDeb should look at B's RPATH and decide that $ORIGIN == ./usr/bin:./usr/bin/../lib
.
Then it should take that and look in component A and see that there's no bin
dir there, so it can discard that path. But then the second path does exist and so _CPack_Packages/Linux/DEB/Project-Version/A/usr/lib
should be added to the list of search directories for dpkg-shlibdeps
. That can either be done by adding another -l
flag or by adding to LD_LIBRARY_PATH
.
I will try to pull a concrete reproducer together soon. My current workaround is to set LD_LIBRARY_PATH
pointing into the build dir before calling cpack
.