Suppose I want to create a package with multiple shared libraries - call it libfoo, which contains liba.so.1 and 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

Now 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):

   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 libb.so.1, but 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 liba and libb as 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 liba).

  • Stupid question: why do you need libb and liba to be two different libs? – Mat Nov 15 '11 at 22:13
  • I'm packaging someone else's code. – lutzky Dec 3 '11 at 14:48
  • Or if you’ve written a library with python bindings, you’re have two libraries as well. – wesanyer Oct 23 '18 at 21:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.