Missing libraries for gd/zip extensions

[ederuiter]

Today I was experimenting with the phpmyadmin docker containers and came across a couple of error message from the container startup:

PHP Startup: Unable to load dynamic library 'zip.so' (tried: /usr/local/lib/php/extensions/no-debug-non-zts-20210902/zip.so (libzip.so.4: cannot open shared object file: No such file or directory), /usr/local/lib/php/extensions/no-debug-non-zts-20210902/zip.so.so (/usr/local/lib/php/extensions/no-debug-non-zts-20210902/zip.so.so: cannot open shared object file: No such file or directory))
PHP Startup: Unable to load dynamic library 'gd.so' (tried: /usr/local/lib/php/extensions/no-debug-non-zts-20210902/gd.so (libpng16.so.16: cannot open shared object file: No such file or directory), /usr/local/lib/php/extensions/no-debug-non-zts-20210902/gd.so.so (/usr/local/lib/php/extensions/no-debug-non-zts-20210902/gd.so.so: cannot open shared object file: No such file or directory))

It seems the container is missing the libraries for the zip/gd extensions (libzip.so.4, libpng16.so.16, libwebp.so.7, libjpeg.so.62, libXpm.so.4 libfreetype.so.6):

root@fa581549c630:/usr/local/lib/php/extensions/no-debug-non-zts-20210902# ldd *
bz2.so:
	linux-vdso.so.1 (0x00007ffc6bd23000)
	libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007fb4ca632000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb4ca451000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fb4ca652000)
gd.so:
	linux-vdso.so.1 (0x00007fffcfe46000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f715484a000)
	libpng16.so.16 => not found
	libwebp.so.7 => not found
	libjpeg.so.62 => not found
	libXpm.so.4 => not found
	libfreetype.so.6 => not found
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7154667000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f71548d9000)
mysqli.so:
	linux-vdso.so.1 (0x00007fffacbc3000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f491e4f8000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f491e708000)
opcache.so:
	linux-vdso.so.1 (0x00007fff16fc8000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f7dad447000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7dad266000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f7dad573000)
sodium.so:
	linux-vdso.so.1 (0x00007ffeff572000)
	libsodium.so.23 => /lib/x86_64-linux-gnu/libsodium.so.23 (0x00007f8ade417000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8ade236000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8ade231000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f8ade490000)
zip.so:
	linux-vdso.so.1 (0x00007ffdf869c000)
	libzip.so.4 => not found
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f94b8914000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f94b8b0e000)

Where it gets weirder is when I double checked which version I was running. Turns out the latest image pulled from docker.io/library/phpmyadmin:latest has a different digest that the one reference in the docker hub interface 🤔

Nevermind .. see docker/hub-feedback#1925 😞

So according to the Dockerfile these libraries should have been installed

docker/apache/Dockerfile

Lines 9 to 16 in 9a7991c

	apt-get install -y --no-install-recommends \
	libbz2-dev \
	libfreetype6-dev \
	libjpeg-dev \
	libpng-dev \
	libwebp-dev \
	libxpm-dev \
	libzip-dev \

eric@eric-desktop:~$ docker run --rm -it phpmyadmin:latest /bin/bash
root@7a57b6b6f283:/var/www/html# dpkg -l | grep libzip
root@7a57b6b6f283:/var/www/html# dpkg -l | grep zip   
ii  bzip2                         1.0.8-5+b1                     amd64        high-quality block-sorting file compressor - utilities
ii  gzip                          1.12-1                         amd64        GNU compression utilities
root@7a57b6b6f283:/var/www/html# 

^ But they are not installed inside the container 🤔

[williamdes]

That's weird, let's wait for an upstream fix then ?

I had it today too

docker-phpmyadmin-1  | <b>Warning</b>:  PHP Startup: Unable to load dynamic library 'gd.so' (tried: /usr/local/lib/php/extensions/no-debug-non-zts-20210902/gd.so (libpng16.so.16: cannot open shared object file: No such file or directory), /usr/local/lib/php/extensions/no-debug-non-zts-20210902/gd.so.so (/usr/local/lib/php/extensions/no-debug-non-zts-20210902/gd.so.so: cannot open shared object file: No such file or directory)) in <b>Unknown</b> on line <b>0</b><br />

[ederuiter]

tldr;

In short: debian 12 usr merge caused the issue and debian knew about this problem for at least since 2017 .. and did not fix it yet.

Adding this line

    | awk '{print $1} {system("realpath " $1)}' \

after

docker/apache/Dockerfile

Line 31 in 9a7991c

| awk '/=>/ { print $3 }' \

Solves the problem

Explanation

I just tried building the phpmyadmin image locally and I saw this in the build output:

+ awk /=>/ { print $3 }
+ + php -r echo ini_get("extension_dir");
sort -u
+ xargs -r dpkg-query -S
+ cut -d: -f1
+ sort -u
+ xargs -rt apt-mark manual
+ ldd /usr/local/lib/php/extensions/no-debug-non-zts-20220829/bz2.so /usr/local/lib/php/extensions/no-debug-non-zts-20220829/gd.so /usr/local/lib/php/extensions/no-debug-non-zts-20220829/mysqli.so /usr/local/lib/php/extensions/no-debug-non-zts-20220829/opcache.so /usr/local/lib/php/extensions/no-debug-non-zts-20220829/sodium.so /usr/local/lib/php/extensions/no-debug-non-zts-20220829/zip.so
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libX11.so.6
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libXau.so.6
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libXdmcp.so.6
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libXpm.so.4
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libbrotlicommon.so.1
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libbrotlidec.so.1
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libbsd.so.0
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libcrypto.so.3
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libfreetype.so.6
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libjpeg.so.62
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libmd.so.0
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libpng16.so.16
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libsodium.so.23
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libwebp.so.7
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libxcb.so.1
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libzip.so.4
apt-mark manual libbz2-1.0 libc6 libgcc-s1 zlib1g
libc6 was already set to manually installed.
libgcc-s1 was already set to manually installed.
zlib1g was already set to manually installed.
libbz2-1.0 set to manually installed.
+ apt-get purge -y --auto-remove -o APT::AutoRemove::RecommendsImportant=false
Reading package lists...
Building dependency tree...
Reading state information...
The following packages will be REMOVED:
  libbrotli-dev* libbsd0* libbz2-dev* libfreetype-dev* libfreetype6*
  libfreetype6-dev* libjpeg-dev* libjpeg62-turbo* libjpeg62-turbo-dev*
  libpng-dev* libpng16-16* libpthread-stubs0-dev* libwebp-dev* libwebp7*
  libwebpdemux2* libwebpmux3* libx11-6* libx11-data* libx11-dev* libxau-dev*
  libxau6* libxcb1* libxcb1-dev* libxdmcp-dev* libxdmcp6* libxpm-dev* libxpm4*
  libzip-dev* libzip4* x11proto-dev* xorg-sgml-doctools* xtrans-dev*
  zlib1g-dev*
0 upgraded, 0 newly installed, 33 to remove and 0 not upgraded.

So problem is not that the packages don't get installed .. instead they get removed again.
Digging into the problem; this seems to be the cause:

dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libzip.so.4

dpkg-query does not find the packages belonging to the libraries that the extensions depend on .. so these package are removed again 😞

The underlying problem seems to be that in debian 12 the /lib dir is now a symlink to /usr/lib. And in /etc/ld.so.conf.d/x86_64-linux-gnu.conf looks like this:

# Multiarch support
/usr/local/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

So it prefers /lib/x86_64-linux-gnu over /usr/lib/x86_64-linux-gnu (which are both the same thing in reality)

But even if we would fix this issue (either by removing the line /lib/x86_64-linux-gnu from /etc/ld.so.conf.d/x86_64-linux-gnu.conf or by using realpath or readlink) we have some remaining issues, because after doing that we still end up with

dpkg-query: no path found matching pattern /usr/lib/x86_64-linux-gnu/libbz2.so.1.0
dpkg-query: no path found matching pattern /usr/lib/x86_64-linux-gnu/libc.so.6
dpkg-query: no path found matching pattern /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
dpkg-query: no path found matching pattern /usr/lib/x86_64-linux-gnu/libm.so.6
dpkg-query: no path found matching pattern /usr/lib/x86_64-linux-gnu/libpthread.so.0
dpkg-query: no path found matching pattern /usr/lib/x86_64-linux-gnu/libz.so.1

For these the issue is that the package uses /lib/x86_64-linux-gnu as its library install path:

root@a6628e6a9679:/# dpkg -L libbz2-1.0
/.
/lib
/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu/libbz2.so.1.0.4
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libbz2-1.0
/usr/share/doc/libbz2-1.0/changelog.Debian.amd64.gz
/usr/share/doc/libbz2-1.0/changelog.Debian.gz
/usr/share/doc/libbz2-1.0/changelog.gz
/usr/share/doc/libbz2-1.0/copyright
/lib/x86_64-linux-gnu/libbz2.so.1
/lib/x86_64-linux-gnu/libbz2.so.1.0

It seems debian knew about this issue for a very long time, but it is not fixed 😞
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858331

So I think the only viable option is to check both the path reported by ldd and the realpath of that.
Adding a line like this

| awk '{print $1} {system("realpath " $1)}' \

After this one:

docker/apache/Dockerfile

Line 31 in 9a7991c

| awk '/=>/ { print $3 }' \

This seems to fix the problem:

libbrotli1 was already set to manually installed.
libc6 was already set to manually installed.
libgcc-s1 was already set to manually installed.
libsodium23 was already set to manually installed.
libssl3 was already set to manually installed.
zlib1g was already set to manually installed.
libbsd0 set to manually installed.
libbz2-1.0 set to manually installed.
libfreetype6 set to manually installed.
libjpeg62-turbo set to manually installed.
libmd0 set to manually installed.
libpng16-16 set to manually installed.
libwebp7 set to manually installed.
libx11-6 set to manually installed.
libxau6 set to manually installed.
libxcb1 set to manually installed.
libxdmcp6 set to manually installed.
libxpm4 set to manually installed.
libzip4 set to manually installed.
+ apt-get purge -y --auto-remove -o APT::AutoRemove::RecommendsImportant=false
Reading package lists...
Building dependency tree...
Reading state information...
The following packages will be REMOVED:
  libbrotli-dev* libbz2-dev* libfreetype-dev* libfreetype6-dev* libjpeg-dev*
  libjpeg62-turbo-dev* libpng-dev* libpthread-stubs0-dev* libwebp-dev*
  libwebpdemux2* libwebpmux3* libx11-dev* libxau-dev* libxcb1-dev*
  libxdmcp-dev* libxpm-dev* libzip-dev* x11proto-dev* xorg-sgml-doctools*
  xtrans-dev* zlib1g-dev*
0 upgraded, 0 newly installed, 21 to remove and 0 not upgraded.

[williamdes]

I can commit this myself, but if you want to open a pull-request that could be cool
We should also add something for the Dockerfile to fail if this happens again, like a file existence check

[ederuiter]

✅ I will create a PR for this and I also reported it upstream

[williamdes]

Thank you for all the work, it is now deployed to the hub: https://hub.docker.com/_/phpmyadmin/tags
Ref: docker-library/official-images#14960