Bug#850828: New .symbols file

[Eriberto]

Hi Hilko,

Sorry for my delay. I had some problems in my work.


2017-01-19 9:37 GMT-02:00 Hilko Bengen <bengen at debian.org>:
> 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.


Ok. I can see the problem here. However, I can't have time (because
the freeze stage) to do tests (I need tests to understand better the
process to split these symbols, uploading to experimental before
unstable). So, I think that the best way is remove all optional
entries and improve it after freeze. I will start to package the 4.4
upstream version now.


> 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.

Ok. I can change version to 4.3.0 instead of use the
dpkg-parsechangelog command. I will do it.


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


Cheers,

Eriberto