tiff: add ptest support

Run the libtiff test suite as a ptest: the C unit tests (the automake check_PROGRAMS) and the shell tests that drive the tiff command-line tools.

do_compile_ptest builds the test programs. do_install_ptest installs the binaries, the shell scripts, the common.sh helper, and the images/ and refs/ data, and points common.sh at the installed tools in ${bindir} instead of the build tree. The recipe lists the C programs once, in TIFF_PTEST_PROGS, and fills that list into run-ptest at install time.

One test, test_ifd_loop_detection, opened its images through a build-time path instead of relative to the current directory, so it failed once installed. A small upstream patch makes it read the images from ".", like the other tests, so it now passes on every architecture.

run-ptest prints automake-style PASS/FAIL/SKIP lines. Two tests skip in the default configuration:

- the JBIG test, because jbig is not in the default PACKAGECONFIG
- the thumbnail test, because the thumbnail tool is not built

Registered under PTESTS_SLOW in ptest-packagelists.inc; the suite runs in about 30s on qemux86-64.

Validated on qemux86-64:

- 17 C unit tests pass
- 85 shell tests pass
- 2 skip (jbig, thumbnail)
- 0 fail

---

v3:
- Fix test_ifd_loop_detection on non-x86 architectures. It opened its images through the build-time SOURCE_DIR path, which does not exist in the installed ptest; a small upstream patch makes it read them relative to ".", like the other tests. This replaces the run-ptest symlink that v2 used to fake that path.
- Reword the commit message per review.

v2:
- Drop the INSANE_SKIP buildpaths; the test binaries package cleanly.
- Drop make and bash from RDEPENDS (run-ptest calls neither).
- Define the C test program list once (TIFF_PTEST_PROGS) instead of duplicating it in run-ptest.

 .../distro/include/ptest-packagelists.inc     |  1 +
 .../recipes-multimedia/libtiff/tiff/run-ptest | 23 ++++++++++
 ...t_ifd_loop_detection-relative-images.patch | 38 +++++++++++++++++
 meta/recipes-multimedia/libtiff/tiff_4.7.2.bb | 42 ++++++++++++++++++-
 4 files changed, 103 insertions(+), 1 deletion(-)
 create mode 100755 meta/recipes-multimedia/libtiff/tiff/run-ptest
 create mode 100644 meta/recipes-multimedia/libtiff/tiff/test_ifd_loop_detection-relative-images.patch

index 2b5d665..837e1c1 100644
@@ -151,6 +151,7 @@ PTESTS_SLOW = "\
     tar \
     tcl \
     tcl8 \
+    tiff \
     util-linux \
     zstd \
 "

new file mode 100755
index 0000000..ebf11c9
@@ -0,0 +1,23 @@
+#!/bin/sh
+# Run the libtiff test suite and emit ptest-style PASS/FAIL/SKIP lines.
+cd "$(dirname "$0")/test" || exit 1
+
+
+# @PROGS@ is filled in from TIFF_PTEST_PROGS at install time.
+CPROGS="@PROGS@"
+
+for t in $CPROGS; do
+    if [ -x "./$t" ]; then
+        if ./"$t" >/dev/null 2>&1; then echo "PASS: $t"; else echo "FAIL: $t"; fi
+    fi
+done
+
+for t in *.sh; do
+    [ "$t" = "common.sh" ] && continue
+    case "$t" in
+        *jbig*) echo "SKIP: $t (JBIG support not enabled)"; continue ;;
+        tiffcp-thumbnail.sh)
+            command -v thumbnail >/dev/null 2>&1 || { echo "SKIP: $t (thumbnail tool not built)"; continue; } ;;
+    esac
+    if sh "./$t" >/dev/null 2>&1; then echo "PASS: $t"; else echo "FAIL: $t"; fi
+done

new file mode 100644
index 0000000..789be95
@@ -0,0 +1,38 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Himani Ramesh Barde <[email protected]>
+Date: Tue, 22 Sep 2026 00:00:00 +0000
+Subject: [PATCH] test_ifd_loop_detection: find images relative to CWD
+
+test_ifd_loop_detection is the only C test in the suite that references
+its input images through the compile-time SOURCE_DIR macro
+(-DSOURCE_DIR="@srcdir@") instead of opening them relative to the current
+working directory the way every other test does. When the test is run
+from an installed location (for example an OpenEmbedded ptest package)
+the build-time @srcdir@ path no longer exists, so the images are not
+found and the test fails.
+
+Override SOURCE_DIR to "." so the images are resolved relative to the
+directory the test is executed from, matching the behaviour of the other
+tests. In-tree "make check" still works because it runs the test from the
+build test/ directory whose srcdir is already ".".
+
+Upstream-Status: Submitted [libtiff]
+
+Signed-off-by: Himani Ramesh Barde <[email protected]>
+---
+ test/test_ifd_loop_detection.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/test/test_ifd_loop_detection.c b/test/test_ifd_loop_detection.c
+--- a/test/test_ifd_loop_detection.c
++++ b/test/test_ifd_loop_detection.c
+@@ -34,6 +34,9 @@
+ #include <string.h>
+ 
+ #include "tiffio.h"
++
++#undef SOURCE_DIR
++#define SOURCE_DIR "."
+ 
+ /* Compare 'requested_dir_number' with number written in PageName tag
+  * into the IFD to identify that IFD.  */

2.54.0

Hi Himani Ramesh,

Thanks for the new version. It looks like the embedded patch fails to apply here:

ERROR: tiff-4.7.2-r0 do_patch: QA Issue: Fuzz detected:

Applying patch test_ifd_loop_detection-relative-images.patch patching file test/test_ifd_loop_detection.c
Hunk #1 succeeded at 45 with fuzz 2 (offset 11 lines).

https://autobuilder.yoctoproject.org/valkyrie/#/builders/4/builds/4740

Can you have a look at the issue?

Thanks,
Mathieu

Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Run the libtiff test suite as a ptest: the C unit tests (the automake check_PROGRAMS) and the shell tests that drive the tiff command-line tools.

do_compile_ptest builds the test programs. do_install_ptest installs the binaries, the shell scripts, the common.sh helper, and the images/ and refs/ data, and points common.sh at the installed tools in ${bindir} instead of the build tree. The recipe lists the C programs once, in TIFF_PTEST_PROGS, and fills that list into run-ptest at install time.

One test, test_ifd_loop_detection, opened its images through a build-time path instead of relative to the current directory, so it failed once installed. A small upstream patch makes it read the images from ".", like the other tests, so it now passes on every architecture.

run-ptest prints automake-style PASS/FAIL/SKIP lines. Two tests skip in the default configuration:

- the JBIG test, because jbig is not in the default PACKAGECONFIG
- the thumbnail test, because the thumbnail tool is not built

Registered under PTESTS_SLOW in ptest-packagelists.inc; the suite runs in about 30s on qemux86-64.

Validated on qemux86-64:

- 17 C unit tests pass
- 85 shell tests pass
- 2 skip (jbig, thumbnail)
- 0 fail

---

v4:
- Regenerate the embedded test_ifd_loop_detection patch against tiff 4.7.2 so it applies without fuzz (reported by the autobuilder).

v3:
- Fix test_ifd_loop_detection on non-x86 architectures. It opened its images through the build-time SOURCE_DIR path, which does not exist in the installed ptest; a small upstream patch makes it read them relative to ".", like the other tests. This replaces the run-ptest symlink that v2 used to fake that path.
- Reword the commit message per review.

v2:
- Drop the INSANE_SKIP buildpaths; the test binaries package cleanly.
- Drop make and bash from RDEPENDS (run-ptest calls neither).
- Define the C test program list once (TIFF_PTEST_PROGS) instead of duplicating it in run-ptest.

 .../distro/include/ptest-packagelists.inc     |  1 +
 .../recipes-multimedia/libtiff/tiff/run-ptest | 23 ++++++++++
 ...t_ifd_loop_detection-relative-images.patch | 34 +++++++++++++++
 meta/recipes-multimedia/libtiff/tiff_4.7.2.bb | 42 ++++++++++++++++++-
 4 files changed, 99 insertions(+), 1 deletion(-)
 create mode 100755 meta/recipes-multimedia/libtiff/tiff/run-ptest
 create mode 100644 meta/recipes-multimedia/libtiff/tiff/test_ifd_loop_detection-relative-images.patch

index 2b5d665..837e1c1 100644
@@ -151,6 +151,7 @@ PTESTS_SLOW = "\
     tar \
     tcl \
     tcl8 \
+    tiff \
     util-linux \
     zstd \
 "

new file mode 100755
index 0000000..ebf11c9
@@ -0,0 +1,23 @@
+#!/bin/sh
+# Run the libtiff test suite and emit ptest-style PASS/FAIL/SKIP lines.
+cd "$(dirname "$0")/test" || exit 1
+
+
+# @PROGS@ is filled in from TIFF_PTEST_PROGS at install time.
+CPROGS="@PROGS@"
+
+for t in $CPROGS; do
+    if [ -x "./$t" ]; then
+        if ./"$t" >/dev/null 2>&1; then echo "PASS: $t"; else echo "FAIL: $t"; fi
+    fi
+done
+
+for t in *.sh; do
+    [ "$t" = "common.sh" ] && continue
+    case "$t" in
+        *jbig*) echo "SKIP: $t (JBIG support not enabled)"; continue ;;
+        tiffcp-thumbnail.sh)
+            command -v thumbnail >/dev/null 2>&1 || { echo "SKIP: $t (thumbnail tool not built)"; continue; } ;;
+    esac
+    if sh "./$t" >/dev/null 2>&1; then echo "PASS: $t"; else echo "FAIL: $t"; fi
+done

new file mode 100644
index 0000000..c46e74d
@@ -0,0 +1,34 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Himani Ramesh Barde <[email protected]>
+Date: Tue, 22 Sep 2026 00:00:00 +0000
+Subject: [PATCH] test_ifd_loop_detection: find images relative to CWD
+
+test_ifd_loop_detection is the only C test in the suite that references
+its input images through the compile-time SOURCE_DIR macro
+(-DSOURCE_DIR="@srcdir@") instead of opening them relative to the current
+working directory the way every other test does. When the test is run
+from an installed location (for example an OpenEmbedded ptest package)
+the build-time @srcdir@ path no longer exists, so the images are not
+found and the test fails.
+
+Override SOURCE_DIR to "." so the images are resolved relative to the
+directory the test is executed from, matching the behaviour of the other
+tests. In-tree "make check" still works because it runs the test from the
+build test/ directory whose srcdir is already ".".
+
+Upstream-Status: Submitted [libtiff]
+
+Signed-off-by: Himani Ramesh Barde <[email protected]>
+---
+--- a/test/test_ifd_loop_detection.c
++++ b/test/test_ifd_loop_detection.c
+@@ -46,6 +46,9 @@
+ 
+ #include "tiffio.h"
+ 
++#undef SOURCE_DIR
++#define SOURCE_DIR "."
++
+ // #define DEBUG_TESTING
+ #ifdef DEBUG_TESTING
+ #define GOTOFAILURE                                                            \

2.54.0

Any progress Himani?
Any questions ?

v5  soon?

# Randy MacLeod
# Wind River Linux