Suppose I want to create a package with multiple shared libraries - call it
libfoo, which contains
libb.so.1. Now, say
liba.so.1 uses a symbol from
libb.so.1. If I compile like this, then everything is OK:
cc -shared -fPIC -Wl,-soname,libb.so.1 -o libb.so.1 libb.c cc -shared -fPIC -Wl,-soname,liba.so.1 -o liba.so.1 liba.c libb.so.1
However, that takes some extra work (I have to manually figure out the dependencies and code them into my makefile, and scons doesn't seem to do this automatically). Compiling the easy way creates an interesting problem:
cc -shared -fPIC -Wl,-soname,libb.so.1 -o libb.so.1 libb.c cc -shared -fPIC -Wl,-soname,liba.so.1 -o liba.so.1 liba.c
liba.so.1 doesn't have
libb.so.1 in its
DT_NEEDED header (visible using
objdump -p), and when building a debian package I get the following message (and this step takes MUCH longer):
dh_shlibdeps dpkg-shlibdeps: warning: symbol b used by debian/libfoo1/usr/lib/liba.so.1 found in none of the libraries.
This happens because symbol
b is defined in
dpkg-shlibdeps has no way of knowing that.
I should note that there doesn't seem to be a real problem here - the actual binary has both
DT_NEEDED, and they are both loaded at run-time... have been for years. This problem only arose when trying to create a proper, cleanly-building debian package.
How should I solve this? (should I solve this?) The libraries really should (TM) be in the same debian package. (For bonus points, solve for circular dependencies, i.e.
libb also uses a symbol from