DCMTK

According to the article referenced in the original issue description, it is not possible (or at least not desirable due to side-effects) to compile completely static binaries on Linux when using glibc. The problem is that glibc needs to load certain shared objects for example for the DNS related gethostinfo() function which resolves hostnames to IP addresses. In a static binary, this will fail if the version numbers of the shared libraries loaded glibc do not match exactly, i.e. if the host system uses a different glibc version. That means that fully static binaries actually decrease portability of the binary when glibc is in use.

1. Either compile fully static binaries using a different libc implementation such as the MUSL libc used in Alpine Linux. Whether or not these binaries work without problems on Linux distributions internally using glibc (such as Debian, Ubuntu, Redhat, SuSE) needs to be determined
2. Alternatively, we could compile dynamic libraries where only glibc is loaded dynamically and all other libraries are linked statically. This will provide maximum compatibility for glibc based distributions as this only requires a glibc that is "recent enough". Details on that are discussed here: https://insanecoding.blogspot.com/2012/07/creating-portable-linux-binaries.html

• linux-vdso.so.1
• libc.so.6
• libdl.so.2
• libnsl.so.1
• libpthread.so.0
• libm.so.6
• /lib64/ld-linux-x86-64.so.2

Maybe also using something like Flatpak, Snap or AppImage could work, if not every binary has to be put into its own "container".

Meanwhile a new build mode DCMTK_PORTABLE_LINUX_BINARIES has been introduced. This will cause binaries to be created where all third-party libraries are linked statically, whereas glibc is linked dynamically. These binaries should be fairly portable and are about the best we can create while using glibc. Truly static binaries can be generated on a Linux distribution using the MUSL libc, such as Alpine Linux, using the DCMTK_LINK_STATIC build mode.