On s390x, the type float_t has historically been defined as double for no good reason, yet with unexpected and unnecessary impact on performance in some scenarios. glibc 2.33 will be a first step towards cleaning that up, which will change float_t to become float on s390x when compiling with compiler flags as used in the ImageMagick binary. That would break the ABI of ImageMagick for HDRI=1 on s390x for existing binaries.
To avoid that breakage, ImageMagick upstream has fixed the relevant internal type to always be double on s390x since version 7.0.10-39, so that the API/ABI for HDRI=1 remains as it is today, independent of a change in float_t. The merged patch can trivially be backported to ImageMagick version 6.9.x in Ubuntu today (will apply a patch; original PR https://github.com/ImageMagick/ImageMagick/pull/2832).
Background: Today's combination of gcc's default behavior and float_t being double on s390x contradicts the C standard. ImageMagick captures the sizeof(float_t) at compile-time of the library in magick-baseconfig.h. Headers then define MagickFloatType to match. For 8-bit and 16-bit depths and HDRI=1, that MagickFloatType is used as the type for pixels's color channels (i.e., Quantum).
Changes to float_t thus would result in a different ABI. Once ImageMagick is rebuilt with HDRI=1 and an updated gcc/glibc, Quantum would then become 32-bit float. Existing binaries and libraries would expect 64-bit double and thus cease to work with newly built version of the library.
Upstream commit with fixed path (MagickCore/magick-type.h -> magick/magick-type.h)
This minor patch avoids interoperability issues with the adoption of glibc 2.33. that glibc release contains one component for cleaning up float_t on s390x, which will eventually reduce performance overhead.
Default Comment by Bridge