Sign up ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Suppose I want to create a package with multiple shared libraries - call it libfoo, which contains and Now, say uses a symbol from If I compile like this, then everything is OK:

cc   -shared -fPIC -Wl,-soname, -o libb.c
cc   -shared -fPIC -Wl,-soname, -o liba.c

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, -o libb.c
cc   -shared -fPIC -Wl,-soname, -o liba.c

Now doesn't have 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/ found in none of the libraries.

This happens because symbol b is defined in, 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).

share|improve this question
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

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.