if a library is released (as different versions) with different exported symbols, any "consumer" of the library (that is, each application / library dynamically linked to it) should keep track of which specific version of the library it needs.
eg. if the application uses only the symbol "dht :: FindNodeRsp :: FindNodeRsp ()", and this symbol was entered with version 0.7 of the library, then your application requires at least version 0.7 of the library (even if the current version is 0.9)
on debian, this process (or maybe) is automated using a "character" file. for example, if you pack the application, the packaging process (to be precise: dpkg-shlibdeps) will check which characters your application imports from the library, and cross-check with the symbol file of the package library to get an estimate of the desired library, version.
It seems your package already has a symbol file (good!)
the only thing you need to do is update this file based on existing information. you must do this manually by comparing the diff output in the build log with the actual character file and adding the appropriate lines to your character file.
example (adding a new character)
eg. Imagine your build log contains the following line:
+ _ZThn52_N3dht11FindNodeRspD1Ev@Base 1.3.0
this means that in version 1.3.0 library a new symbol is added _ZThn52_N3dht11FindNodeRspD1Ev@Base ( + ). since the search name is hardly readable (at least for people), you can run it through c++filt to undo it:
$ echo _ZThn52_N3dht11FindNodeRspD1Ev@Base | c++filt non-virtual thunk to dht::FindNodeRsp::~FindNodeRsp()@Base
in this case you should add a new line to your character file:
(c++)"non-virtual thunk to dht::FindNodeRsp::~FindNodeRsp()@Base" 1.3.0
note that you should probably cancel the suffix of the local version, for example. 1.3.0-0ubuntu0~ppa4 should become 1.3.0-0ubuntu0~ (leave the back tilde in place)
example (delete character)
Unfortunately, your result indicates that several characters have been deleted from your library. this is bad, as it violates compatibility! (if your application (only) uses the dht::FindNodeRsp::~FindNodeRsp() symbol, which was introduced in version 1.0.3 but removed in version 2.3.0, you can associate it with version 1.0.3, but you also you can use version 1.2.5, since it still provides this symbol, your application will not care about other symbols that may or may not be present in the library).
since it violates compatibility, the first thing you need to make sure is to add the main version of your library number - packagename .
eg. if your library deleted the character between the (upstream) release "1.0.3" and "1.0.4" and the original (binary) package name was "libfoo1" (used to package upstream "1.0.3"), then you should change the name of the binary package to "libfoo2" (although the upstream version is still 1.something)
it MUST be dictated by Debian policy!
renaming the binary package name most likely involves renaming the symbol file from debian/libfoo1.symbols to debian/libfoo2.symbols
as soon as you do this, remove the offending lines from the character file.
architecture issues: 32 bit vs 64 bit
you may have problems with some types that "look" differently at different architectures, in particular, 64-bit systems and 32-bit systems. the most common of these types is size_t , which can expand to unsigned long or unsigned int , depending on your architecture.
Fortunately, there are tools to handle (some of) these cases, for example. replacement pkgkde-gensymbols for dpkg-gensymbols that comes with pkg-kde-tools
to use it, change the corresponding entries in your symbol file to the following: (if your library exports the symbol "foo :: bar (size_t n)"
(c++|subst)"foo::bar({c++:size_t})@Base" 1.2.3
you must tell your debian/rules file to use pkgkde-gensymbols instead of the standard one. if you use CDBS for packaging, add the following line immediately after the usual one:
include /usr/share/pkg-kde-tools/makefiles/1/cdbs/symbolshelper.mk
refer to README.Debian from pkg-kde-tools for information on how to do this for other build systems, for example. dh and / or "standard" simple KDE packages.