aurupdater

freeimage

Build times (auto-updated)

2026-10-12: pkgrel 24 -> 25, jxrlib 1.4.4-3 header-relocation fix (AUR comment, promano)

promano reported freeimage 3.18.0-24 fails against jxrlib 1.4.4-3: JXRGlue.h: No such file or directory. Confirmed jxrlib 1.4.4-3 (current extra/) relocated its headers from /usr/include/jxrlib/ to /usr/include/libjxr/{common,glue,image,image/x86,test}/, and this time does ship a real JXRVersion.h (at libjxr/glue/JXRVersion.h) – the 2026-10-07 workaround below is now obsolete, not just inert, because its guard ([[ ! -f /usr/include/jxrlib/JXRVersion.h ]]) checks a path that no longer exists at all, so it would keep firing and shadow the real shipped header with a stale 1.4.3-labeled one.

Fix: removed that synthesis block from PKGBUILD’s prepare() entirely, and in freeimage-unbundle.patch’s Makefile.gnu hunk, replaced the hardcoded -I/usr/include/jxrlib (and hardcoded -ljpegxr -ljxrglue) with pkg-config --cflags/--libs ... libjxr, since jxrlib has shipped a correct libjxr.pc all along (checked the actual package: Cflags: -I.../libjxr/common -I.../libjxr/image/x86 -I.../libjxr/image -I.../libjxr/glue -I.../libjxr/test -D__ANSI__ -DDISABLE_PERF_MEASUREMENT, Libs: -ljpegxr -ljxrglue) – matches the style already used for the other unbundled libs on that same line, and survives any future jxrlib layout change since it’s not our hardcoded guess. This diverges from the hardcoded-paths patch promano posted in their comment, but fixes the identical root cause more durably.

Gotcha: editing freeimage-unbundle.patch via the Edit tool silently stripped CRLF line endings from an unrelated hunk further down in the file (the PluginTIFF.cpp hunk intentionally carries CRLF to byte-match that source file’s own line endings, so patch can apply it). First build attempt failed with “Hunk FAILED … different line endings” on that hunk even though it wasn’t touched. Fixed by restoring the exact original CRLF bytes for that block from git HEAD and recomputing the sha512sum – if touching this patch file again, diff against HEAD afterward and check for stray line-ending changes outside the intended hunk.

Packaging-only (no pkgver change), pkgrel 24 -> 25 per [[feedback_pkgrel_vs_pkgver]]. Confirmed clean build via repo_release.sh maintained/freeimage (x86_64 only) and published without connection-failure strings in the full log. Did not reply on AUR – fix addresses the same root cause the commenter reported, matches [[feedback_obvious_fixes_no_aur_reply]].

2026-10-14: RyougaLolakie re-reports the same jxrlib error against 3.18.0-25 – no action

RyougaLolakie (2026-10-13 12:36) commented that 3.18.0-25 still fails with the identical JXRGlue.h: No such file or directory the pkg-config fix above was supposed to resolve, questioning whether it actually worked. duffydack replied three minutes later (12:39) that it builds fine for them in a chroot. Re-verified independently rather than just trusting either comment: this host’s jxrlib is 1.4.4-3 and ships a real libjxr.pc (pkg-config --cflags libjxr resolves to exactly /usr/include/libjxr/{common,image,image/x86,glue,test} – checked live, not just read from the .pc file) – so the current PKGBUILD is objectively correct against the jxrlib actually in extra/ right now, consistent with duffydack’s result and the 2026-10-12 confirmed-clean build above. RyougaLolakie’s failure is most likely environment-specific on their end (stale jxrlib, not actually rebuilt against 3.18.0-25 yet, or a pkg-config/ PKG_CONFIG_PATH problem) rather than a real PKGBUILD bug. User’s call: leave the AUR thread as-is, no reply – duffydack already answered in-thread, and there’s no new information here to add.

Build times (auto-updated)

2026-10-07: pkgrel 23 -> 24, jxrlib-missing-header build fix (AUR comment, jose1711)

jose1711 reported a clean-chroot build failure: /usr/include/jxrlib/JXRGlue.h:35:10: fatal error: JXRVersion.h: No such file or directory. Confirmed jxrlib is an official extra/ package (1.4.3-1), not one we maintain, and it genuinely never installs JXRVersion.h even though its own JXRGlue.h #includes it via angle brackets – an upstream/packaging gap we can’t patch at the source, since it’s not our package.

Applied the workaround jose1711 supplied in their comment: prepare() now synthesizes a minimal JXRVersion.h (just the version-macro defines) in the FreeImage source root (cwd after cd FreeImage) when it’s not already present system-wide, guarded by [[ ! -f /usr/include/jxrlib/JXRVersion.h ]] so a future jxrlib release that does install the real header is a no-op. This works because the build’s -I. picks up the local copy for the angle-bracket include – no system paths touched, nothing installed outside the build. Packaging-only fix (no pkgver change), so pkgrel 23 -> 24 per [[feedback_pkgrel_vs_pkgver]].

Confirmed clean build via repo_release.sh maintained/freeimage (x86_64 only, 50s) and published without issue (no connection-failure strings in the full log). Did not reply on AUR – the fix is exactly what the commenter proposed, matches [[feedback_obvious_fixes_no_aur_reply]].

2026-09-27: AUR comment noting freeimagere-git alternative – no action taken

oriba commented suggesting freeimagere (github.com/agruzdev/FreeImageRe, AUR: freeimagere-git) as an alternative, since upstream FreeImage looks semi-abandoned. Checked: freeimagere-git does exist on AUR already (maintained separately by bill997, 0.5-2, 0 votes) – not something we’d need to create ourselves. It’s not a drop-in replacement though: Conflicts=(freeimage) and provides a different soname (libFreeImageRE.so vs our libfreeimage.so), so switching would need an explicit rebuild of anything depending on freeimage.

User’s call: leave the AUR thread as-is, no reply, no package change – this is an informational suggestion, not a bug report. If asked about this package’s status again, this is already known/considered, not a fresh gap to investigate.