libpng not properly linked to libz in manylinux wheels?

[JayH5]

What did you do?

With the following Dockerfile:

FROM python:3.6-slim
RUN pip install --no-cache Pillow==4.0.0
RUN find /usr/local/lib/python3.6/site-packages -name '*.so*' | xargs ldd

Run docker build -t pillow-ldd .. Observe output of last RUN command.

What did you expect to happen?

Expected all libraries to be linked successfully.

What actually happened?

All libraries are linked except for libpng:

/usr/local/lib/python3.6/site-packages/PIL/.libs/libpng16-4b619e46.so.16.25.0:
	linux-vdso.so.1 (0x00007ffc46363000)
	**libz-a147dcb0.so.1.2.3 => not found**
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f78e2e06000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f78e2a5a000)
	/lib64/ld-linux-x86-64.so.2 (0x00005652f53d8000)

Other libraries link to libz-a147dcb0.so.1.2.3 successfully, just not libpng for some reason.

I don't know if this manifests in any actual issues. It's just concerning that the library doesn't link.

What versions of Pillow and Python are you using?

As you can see, this is Python 3.6 with Pillow 4.0.0. I've seen the same with Python 2.7 + Pillow 4.0.0.

[wiredfool]

We don't directly use libpng for anything, but it appears that it's supposed to be linked into freetype.

[webknjaz]

This seems to be a known issue: pypa/manylinux#60

[radarhere]

Just to bring the information here - the linked manylinux issue was resolved with auditwheel 1.10, but this problem still occurs with auditwheel 2.0.

[webknjaz]

FTR I've solved a similar issue when packaging pygit2 by downloading and statically compiling all non-manylinux1 dependencies.

[radarhere]

Note that Pillow master has dropped support for Python 3.6.

[radarhere]

#254 fixes the link from libpng to libz.

But there are other libraries that aren't found - png, webp, lzma, jpeg, libXau and freetype.

[radarhere]

Asking about this in pypa/auditwheel#371, I received this response.

This seems perfectly normal. Here, ldd is ran directly on a grafted library. This never happens when using a python C extension, they're always loaded through the extension which has the correct RPATH allowing for the dynamic loader to find libraries correctly. e.g. with Pillow 9.0.1 installed, if doing ldd directly on liftiff, we get some not found output:

ldd cp39/lib/python3.9/site-packages/Pillow.libs/libtiff-8e99fb9e.so.5.7.0 
	linux-vdso.so.1 (0x00007ffeea33b000)
	liblzma-d540a118.so.5.2.5 => not found
	libjpeg-62ed1500.so.62.3.0 => not found
	libz-dd453c56.so.1.2.11 => not found
	libm.so.6 => /lib64/libm.so.6 (0x00007ff47b690000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff47b470000)
	libc.so.6 => /lib64/libc.so.6 (0x00007ff47b0ab000)
	/lib64/ld-linux-x86-64.so.2 (0x00007ff47ba12000)

Calling ldd on the python extension, those not found disappear:

ldd cp39/lib/python3.9/site-packages/PIL/_imaging.cpython-39-x86_64-linux-gnu.so
	linux-vdso.so.1 (0x00007ffdfbbc7000)
	libjpeg-62ed1500.so.62.3.0 => /root/cp39/lib/python3.9/site-packages/PIL/../Pillow.libs/libjpeg-62ed1500.so.62.3.0 (0x00007fa824d3c000)
	libopenjp2-430a98fc.so.2.4.0 => /root/cp39/lib/python3.9/site-packages/PIL/../Pillow.libs/libopenjp2-430a98fc.so.2.4.0 (0x00007fa824cb8000)
	libz-dd453c56.so.1.2.11 => /root/cp39/lib/python3.9/site-packages/PIL/../Pillow.libs/libz-dd453c56.so.1.2.11 (0x00007fa824c97000)
	libtiff-8e99fb9e.so.5.7.0 => /root/cp39/lib/python3.9/site-packages/PIL/../Pillow.libs/libtiff-8e99fb9e.so.5.7.0 (0x00007fa824bbc000)
	libxcb-1122e22b.so.1.1.0 => /root/cp39/lib/python3.9/site-packages/PIL/../Pillow.libs/libxcb-1122e22b.so.1.1.0 (0x00007fa824b7f000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa82495d000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fa824598000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fa824216000)
	liblzma-d540a118.so.5.2.5 => /root/cp39/lib/python3.9/site-packages/PIL/../Pillow.libs/liblzma-d540a118.so.5.2.5 (0x00007fa8241df000)
	libXau-00ec42fe.so.6.0.0 => /root/cp39/lib/python3.9/site-packages/PIL/../Pillow.libs/libXau-00ec42fe.so.6.0.0 (0x00007fa823fda000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fa824c66000)

So it would seem this is not a problem.