Bug#850828: New .symbols file

[Hilko Bengen]

Hi Eriberto,

I see that you have simply marked many symbols optional instead of
splitting the .symbols file. Please reconsider that decision.

You approach works in the sense that the package no longer fails to
build on architectures where not all defined symbols aren't present.
However, there are few subtle problems with this. On 32bit
architectures, many symbols that are not defined in the .symbols file
get added automatically. Those symbols are then annotated with the wrong
default version number.

Example from the current i386 build log[1]:

While a symbol is removed without causing an error because it has been
declared optional, another symbol for the equivalent function is added,
but with a different version number:

- (optional|c++)"TskDbSqlite::getFsInfos(long, std::vector<_TSK_DB_FS_INFO, std::allocator<_TSK_DB_FS_INFO> >&)@Base" 4.3.0
  [...]
+ _ZN11TskDbSqlite10getFsInfosExRSt6vectorI15_TSK_DB_FS_INFOSaIS1_EE at Base 4.3.1

This is the demangled version of the added symbol:

TskDbSqlite::getFsInfos(long long, std::vector<_TSK_DB_FS_INFO, std::allocator<_TSK_DB_FS_INFO> >&)@Base

The second symbol represents the same function as the first; on 32bit
architectures the C++ compiler (or rather the preprocessor) replaces the
first argument type "int64_t" with "long long" instead of "long" ... and
thus name mangling produces a different symbol.

The version number is important because dpkg-shlibdeps uses it to infer
the automatic dependencies it generates for ${shlibs:Depends}. Building
a different package that uses only a subset of the libtsk functions
would get a "libtsk13 (>= 4.3.0)" dependency on some architectures while
the same package might get a "libtsk13 (>= 4.3.1)" dependency on other
architectures. This is clearly broken.

Normally, the added version number would even contain the Debian
revision which would get marked as an error by Lintian for half of the
architectures. This does not happen because you added an override for
the version number (override_dh_makeshlibs), thereby hiding the actual
problem.

Cheers,
-Hilko

[1] https://buildd.debian.org/status/fetch.php?pkg=sleuthkit&arch=i386&ver=4.3.1-5&stamp=1484596774&raw=0