Debian Patches
Status for freeimage/4.2.1+ds-1~exp3
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| disable-private-tiff-api-usage.patch | Disable use of private libtiff / libjpeg-turbo headers The G3 fax loader and the EXIF-in-TIFF metadata reader use TIFF struct internals only exposed by libtiff's private <tiffiop.h>, and the JPEG lossless-transform routines need libjpeg-turbo's private transupp.h/.c. Neither private header is shipped by Debian's libtiff-dev / libjpeg-dev. . This disables G3 fax loading and the JPEGTransform* API family (same functionality gap as the historical Debian freeimage package), and replaces the tif_nfields/tif_fields walk in the EXIF reader/writer with a hard-coded list of well-known EXIF tag ids -- the same technique used by the freeimage-3.17.0_unbundle patch from Fedora, and by Debian's own Disable-vendored-dependencies.patch for the previous (non-fork) freeimage package. . Source/FreeImageToolkit/JPEGTransform.cpp itself is dropped from the orig tarball via debian/copyright's Files-Excluded, same as before; this patch only guards its now-dangling declarations in Source/FreeImage.h. |
Anton Gladky <gladk@debian.org> | not-needed | 2026-08-21 | ||
| fix-libtiff-alias-typo.patch | Fix typo'd CMake alias target name for system LibTIFF dependency.tiff.cmake defines the imported target as "libTIFF" (lowercase l) when USE_SYSTEM_LIBTIFF/USE_SYSTEM_LIBS is used, but Source/CMakeLists.txt links against "LibTIFF" (capital L). CMake target names are case-sensitive, so the system-libtiff path currently fails at link time with "cannot find -lLibTIFF" once dependents try to use it. |
Anton Gladky <gladk@debian.org> | yes | 2026-08-21 | ||
| fix-libwebpmux-linking.patch | Link the system libwebpmux pkg-config module too Source/Plugins/PluginWebP.cpp calls into the WebPMux* API (webp/mux.h), which lives in a separate pkg-config module (libwebpmux) from the base libwebp one. dependency.webp.cmake's USE_SYSTEM_LIBWEBP/USE_SYSTEM_LIBS path only pulled in "libwebp", leaving libFreeImage.so with unresolved WebPMux* symbols. These go unnoticed with lazy binding, but building anything against the library with immediate binding (Debian's default hardening=+all implies -Wl,-z,now via bindnow) fails, and any caller that actually reaches the WebP-with-metadata save path would crash at runtime otherwise. |
Anton Gladky <gladk@debian.org> | yes | 2026-08-21 | ||
| restore-default-color-order.patch | Restore endian-aware default for FREEIMAGE_COLORORDER Upstream FreeImageRe's Source/FreeImage.h unconditionally falls back to FREEIMAGE_COLORORDER_RGB when the caller doesn't define FREEIMAGE_COLORORDER explicitly, regardless of endianness. The original FreeImage 3.18 header (as shipped by every prior upload of this package) instead auto-detects: RGB on big-endian, BGR on little-endian -- i.e. BGR on every architecture we actually build for except s390x. . This is not just a cosmetic difference: FREEIMAGE_COLORORDER controls the actual in-memory byte order of every 24/32-bit FIT_BITMAP scanline (and the FI_RGBA_RED/GREEN/BLUE offset macros used to index into it), so the upstream default change silently swaps the red and blue channels of every image loaded through FreeImage_GetScanLine() & friends compared to what every existing caller was built against -- confirmed empirically with a 1x1 pure-red PNG: the current package's libfreeimage.so.3 returns raw scanline bytes [0,0,255] (B,G,R); FreeImageRe built with upstream's unpatched default returns [255,0,0] (R,G,B) for the exact same input. . This restores the original auto-detecting fallback. It must be combined with building the library itself with -DFREEIMAGE_COLORORDER=BGR (the CMakeLists.txt cache default is unconditionally "RGB" regardless of this header, so the library's own compilation needs the explicit override too -- see debian/rules) to fully match the raw byte order of the currently shipped library. With both applied, a rebuilt test program against the patched header emits byte-for-byte identical output to the current package for the same 1x1 red PNG (raw bytes [0,0,255], FI_RGBA_RED=2, FI_RGBA_GREEN=1, FI_RGBA_BLUE=0, verified 2026-08-21). |
Anton Gladky <gladk@debian.org> | yes | 2026-08-21 | ||
| build-freeimageplus.patch | Build the ported FreeImagePlus wrapper Wires Wrapper/FreeImagePlus/ (ported from FreeImage 3.18, added to the orig tarball -- see debian/copyright) into the CMake build. |
Anton Gladky <gladk@debian.org> | not-needed | 2026-08-22 | ||
| vendor-yato.patch | Use the vendored Yato copy instead of fetching from the network dependency.yato.cmake's non-system path fetches Yato from GitHub via ExternalProject_Add at build time, with no USE_SYSTEM option (Yato isn't packaged in Debian). Point it at the pinned commit vendored under 3rdParty/Yato instead (added to the orig tarball -- see debian/copyright). |
Anton Gladky <gladk@debian.org> | not-needed | 2026-08-22 | ||
| use-system-libopenjpeg.patch | Add a USE_SYSTEM_LIBOPENJPEG option, and fix OPJ_STATIC for it dependency.openjpeg.cmake has no USE_SYSTEM switch, unlike every sibling dependency -- it always fetches and builds OpenJPEG from the network. Adds one, mirroring dependency.png.cmake's pattern. . Doing that alone isn't enough: Source/CMakeLists.txt unconditionally defines -DOPJ_STATIC for the whole build. openjpeg.h makes OPJ_API __attribute__((visibility("hidden"))) under that define, which is fine for the vendored static build but breaks linking against the system's dynamic libopenjp2.so ("hidden symbol ... isn't defined" at link time). Move the define to only apply to the vendored, statically-built copy. |
Anton Gladky <gladk@debian.org> | not-needed | 2026-08-22 | ||
| set-soname.patch | Give libfreeimage a real SONAME, bumped to 4 add_library(FreeImage SHARED) sets no OUTPUT_NAME/VERSION/SOVERSION, so it installs as plain libFreeImage.so with no .so.N at all. The abidiff against the current package's libfreeimage.so.3 (3.18.0+ds2-11) found a removed function and a changed signature, so this bumps to a new SONAME (4) rather than reusing 3, per Debian's shared library policy. |
Anton Gladky <gladk@debian.org> | not-needed | 2026-08-22 | ||
| use-system-libjxr.patch | Build against the system jxrlib FreeImageRe builds its own copy of jxrlib from 3rdParty/LibJXR. That copy is removed from the Debian orig tarball, so find libjxr through pkg-config and include its JXRGlue.h, as the FreeImage 3.18 package did. |
Anton Gladky <gladk@debian.org> | not-needed | 2026-10-17 | ||
| dlopen-libheif-soname.patch | Load libheif by its SONAME The HEIF plugin opens libheif with dlopen("libheif.so"). That name is the development symlink, which is only installed together with libheif-dev, so on a normal system HEIF and AVIF support silently disappears. Try the runtime name libheif.so.1 first. |
Anton Gladky <gladk@debian.org> | no | 2026-10-17 | ||
| drop-private-jversion-include.patch | Do not include the private jversion.h header jversion.h is not installed by libjpeg-turbo. It only provides JVERSION, which is used in the plain IJG libjpeg branch; with libjpeg-turbo, LIBJPEG_TURBO_VERSION comes from jconfig.h via jpeglib.h. |
Anton Gladky <gladk@debian.org> | no | 2026-10-17 | ||
| disable-testing-of-jpeg-transform.patch | Disable testing of JPEG lossless transform FreeImage_JPEGTransform and friends are disabled by disable-private-tiff-api-usage.patch (they need libjpeg-turbo's private transupp.h, not shipped by libjpeg-dev), so TestAPI can't call them either. Same fix as the historical Debian freeimage package's Disable-testing-of-JPEG-transform.patch. |
Anton Gladky <gladk@debian.org> | not-needed | 2026-08-22 | ||
| yato-portable-arch-detection.patch | Detect architecture by pointer size on non-x86/ARM64 targets prerequisites.h only whitelists x86, x86_64 and arm64, and raises #error "Unknown architecture!" everywhere else, which breaks the build on armhf, ppc64el, s390x, loong64, riscv64 and the ports architectures. YATO_X64/YATO_X86 are only used as a 64/32-bit marker, so fall back to __SIZEOF_POINTER__ for other GCC/Clang targets. |
Anton Gladky <gladk@debian.org> | no | 2026-10-18 | ||
| fix-big-endian-build.patch | Fix FTBFS on big-endian architectures Code under #ifdef FREEIMAGE_BIGENDIAN was not updated when upstream renamed identifiers, so it does not compile on big-endian targets (powerpc, ppc64, s390x, ...): - PluginBMP.cpp: Save() uses 'bpp', renamed to 'dst_bpp'. - PluginDDS.cpp: SwapHeader() uses 'ddpfPixelFormat', renamed to 'ddspf'. |
Anton Gladky <gladk@debian.org> | no | 2026-10-19 |
All known versions for source package 'freeimage'
- 4.2.1+ds-1~exp3 (experimental)
- 3.18.0+ds2-11 (sid, trixie)
- 3.18.0+ds2-9+deb12u1 (bookworm-security, bookworm)