[Debian-med-packaging] Bug#966470: fix for #966470: biobambam2 autopkgtest failures
John Marshall
John.W.Marshall at glasgow.ac.uk
Mon Aug 10 12:04:05 BST 2020
Étienne Mollier wrote:
> I had a look at the autopkgtest failure affecting biobambam2,
> and since these segmentation faults were showing up only in my
> autopkgtest environment, and not when using the package directly
> on my system, it felt like a missing dependency. So I trapped
> system calls issued by the `bamsormadup` command using `strace`
> within the run-unit-test script, and it turned out the program
> was searching for a libz.so library.
>
> After appending the zlib1g-dev package to dependencies of the
> biobambam2 package,
It is in fact libmaus2 that is dlopening "libz.so", so it would be better to add to the dependencies of that package, which is a prerequisite of biobambam2.
However this is really a bug in libmaus2, as it is incorrect to use that file with that name at runtime [1]. So the better fix would be to patch libmaus2 to use the runtime filename ("libz.so.1") that is provided by Debian's zlib1g (and ensure that libmaus2 depends on zlib1g -- without ‑dev) in anticipation of upstream libmaus2 making a similar fix.
Thus (as Debian controls exactly the libz.so.1 filename, unlike for the upstream patch):
+++ b/src/libmaus2/lz/ZlibInterface.hpp
@@ -53,7 +53,7 @@ namespace libmaus2
static std::string getDefaultZLibName() {
return
"../lib/libz_cf.so\ti386:sse4_2,i386:pclmulqdq\n"
- "libz.so\t\n";
+ "libz.so.1\t\n";
}
John
[1] https://gitlab.com/german.tischler/libmaus2/-/issues/31
More information about the Debian-med-packaging
mailing list