É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
