My application uses some private shared libraries, which i need to package with the binary, and as per Debian Policy Rules
It is recommended that supporting files and run-time support programs
that do not need to be invoked manually by users, but are nevertheless
required for the package to function, be placed (if they are binary)
in a subdirectory of /usr/lib, preferably under /usr/lib/package-name.
So, I put my shared library e.g. libabc.so in /usr/lib/myapp/ directory. After creating the debian package the binary fails to load as /usr/lib/myapp/ is not searched by the loader to load the directory. They don’t recommend using RPATH in the binary. So what changes should i make in the debian package, or in the compilation of binary or anything else to make it work.
If your shared-library can be of any use to other (potentially future) applications and there is a public interface to the library, you might consider installing it into
/usr/lib/directly (or rather/usr/lib/<host-triplet>for multiarch support).If this is not an option (since your shared-lib is really private), check how other applications deal with that. a quick survey on my system reveals that both
ardourandgedithave private shlibs in/usr/lib/<pkgname>/.ardour
ardouruses an (imo) rather hackish way: the executable/usr/bin/ardour2is really only a shellscript that warps calling the real binary with some LD_LIBRARY_PATH fudge:gedit
With
gedit, upstream has properly moved to installinglibgedit-private.soaspkglib(the autotools lingo for libs that go to/usr/lib/<pkgname>).autotoolshandles the resolving automatically (presumably with something likerpath).Finally, as I read the debian-policy,
rpathis frowned upon for non-private libraries (libs potentially used by other applications). I don’t think that this is an issue here but of course this is my interpretation of the policy. You might want to check back with one of the Debian channels like their IRC or some mailing list.