Reported against r13001 on Ubuntu 26.04, once the libcurl failure was out of the
way: lib/libpdf/haru.c does not compile against the libharu in /usr/local.
libharu 2.4 changed two things this file relies on:
- HPDF_Page_SetDash() takes its pattern as const HPDF_REAL * and its phase as
HPDF_REAL. Up to 2.3 those were const HPDF_UINT16 * and HPDF_UINT, and the
dash_mode arrays here are declared HPDF_UINT16 - a hard error under GCC 14+,
which is what the reporter hit at haru.c:3940 and :4012.
- HPDF_PROJECTING_SCUARE_END was corrected to HPDF_PROJECTING_SQUARE_END, so
haru.c:4069 no longer names anything that exists.
Rather than move to the new spelling and break older installations, pick both
from the version macros in hpdf_version.h (which hpdf.h includes): the dash
arrays use A4GL_HPDF_DASH, HPDF_REAL from 2.4 onwards and HPDF_UINT16 before
that, and the code now uses the corrected SQUARE spelling with a #define
mapping it back to SCUARE on older headers. A build with neither macro defined
gets the old API, which is what it would have had anyway.
Note that on 2.4 the dash lengths stop being truncated to whole points, since
the pattern is now float either side of the call.
Verified both ways: compiles clean against the 2.3.0 headers on this box (the
old branch, including the SCUARE remap), and the preprocessor picks HPDF_REAL
plus the corrected spelling when the version macros say 2.4. I have no 2.4
install here to compile the new branch end to end, so that half is verified at
the preprocessor rather than by building it.
The comment at the old line 4059 ("SCUARE is not a spelling mistake!") now
points at the shim instead - it was true of 2.3 and wrong from 2.4 on.
