Hi Hilko, Sorry for my delay. I had some problems in my work.
2017-01-19 9:37 GMT-02:00 Hilko Bengen <ben...@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@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 _______________________________________________ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel