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@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 _______________________________________________ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel