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
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
What should happen is that the RPATH/RUNPATHs of the executables in a component should be read and their
$ORIGINs should be mapped appropriately onto the dependent component folders. Suppose that in
CPackConfig.cmake we have:
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
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