Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers. Visit Stack Exchange

Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.

Sign up to join this community

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

I know this is basically the exact question as in https://stackoverflow.com/questions/48306849/ , but the answer there does not seems right to me, as they all saying creating a libz.so.1 symlink. However,

In my Debian bullseye, I already have libz.so and libz.so.1 , both symlinking to libz.so.1.2.11 .

So this seems to be a problem that libpng16.so.16 insists on a lower version of ZLIB (v1.2.9), while mine is already v.1.2.11 , right?

Here are all the details:

$ mitmweb
/usr/bin/x-www-browser: /tmp/_MEIi9PAKI/libz.so.1: version `ZLIB_1.2.9' not found
 (required by /lib/x86_64-linux-gnu/libpng16.so.16)
cd /usr/lib/x86_64-linux-gnu
$ ls -l libz.so*
lrwxrwxrwx 1 root root     36 2020-02-24 16:07 libz.so -> /lib/x86_64-linux-gnu/libz.so.1.2.11
lrwxrwxrwx 1 root root     14 2020-02-24 16:07 libz.so.1 -> libz.so.1.2.11
-rw-r--r-- 1 root root 113088 2020-02-24 16:07 libz.so.1.2.11
$ apt-cache policy libpng16-16:amd64
libpng16-16:
  Installed: 1.6.37-3
  Candidate: 1.6.37-3
  Version table:
 *** 1.6.37-3 500
        500 http://deb.debian.org/debian bullseye/main amd64 Packages
        100 /var/lib/dpkg/status
$ ldd /lib/x86_64-linux-gnu/libpng16.so.16
    linux-vdso.so.1 (0x00007fff01872000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fa21425d000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa214119000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa213f54000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fa2142c2000)
$ realpath /usr/bin/x-www-browser
/export/opt/google/chrome/google-chrome
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux bullseye/sid
This isn’t an issue with the zlib1g or libpng16-16 packages in Debian, it’s a bug in the binaries provided by mitmweb. They include a number of libraries which are unpacked in a temporary directory at runtime; LD_LIBRARY_PATH is set to the temporary directory so that the dynamic linker will use the libraries there. This works fine for the binaries shipped by mitmweb, but LD_LIBRARY_PATH is passed down to the browser which mitmweb attempts to start.
The bundle of libraries includes libz version 1.2.8, which is too old to satisfy the requirements of libpng16-16. As a result, the browser, which needs libpng16-16, fails to start. (The binaries are built on an old distribution so that they won’t end up requiring new libraries.)
There’s no simple fix for mitmweb itself, short of rebuilding it from source, but you can easily work around the error: wait for mitmweb to start, and open http://localhost:8080 in your browser (or whatever URL is appropriate, if you specified another host or port using --web-host or --web-port).
(Interested readers can see the structure of mitmweb without running it by analysing it with binwalk.)