Hello Branden,
G. Branden Robinson wrote on Fri, Sep 25, 2026 at 12:49:01PM -0500:
[ regarding $< ]
> There are two other affected targets.
OK, so that will probably be easy to fix. :-)
Let's hope there won't be a third issue raising its head after that.
[ regarding lib/asnprintf.c ]
> Collin Funk monitors this list and works on gnulib; maybe he can rescue us.
So, i'll wait a bit, using my dirty workaround in the meantime.
> I had thought you had some trick where you basically defeated gnulib in
> the official OpenBSD port of groff, and forced linkage with OpenBSD's
> libc even gnulib's Autoconf macros would have diagnosed a POSIX
> conformance problem in it?
That's not *one* trick, but it requires almost a dozen changes to
get gnulib out of the way, and the list keeps growing, usually when
groff uses more of gnulib or when the gnulib submodule is updated.
Currently, i'm using the following for groff-1.15 - but testing
isn't done, so this list might still need a few changes.
CONFIGURE_ENV += gl_cv_func_printf_directive_a=yes \
gl_cv_func_printf_directive_b=yes \
gl_cv_func_printf_directive_n=yes \
gl_cv_func_printf_enomem=yes \
gl_cv_func_printf_sizes_c23=yes \
gl_cv_func_strerror_0_works=yes \
gl_cv_header_errno_h_complete=yes
CONFIGURE_ENV += ac_cv_func_vasnprintf=yes \
gl_cv_func_vasnprintf_works=yes
CONFIGURE_ENV += gl_cv_func_svid_putenv=yes
MAKE_FLAGS += lib_libgnu_a_OBJECTS=
But as i said, at this time, i'm not trying to update the port,
so i'm using none of that, Instead, i'm trying to build exactly
as upstream and gnulib suggest.
Testing whether the upstream build system works on the one hand and
building production binaries according to OpenBSD ports standards
on the other hand both seem useful tasks to me - but both tasks
require completely different approaches.
> Anybody might check out groff's "master" branch at any time, and do a
> build with BSD Make to help keep us honest. It doesn't need to be me.
True, and that would be easier for me than for most, i guess,
so it *is* desirable for me to do more of that. Then again,
last week, my documentation-tools-related priority list was
1. continue preparations for the mandoc-1.15.1 release
2. send out mandoc-1.15.1 release candidate
3. update OpenBSD groff port to 1.23
(it is almost ready for commit, the complete mandoc test suite
succeeds, the last thing to check is whether i can still trim
down some of the patches)
4. work on a groff-1.24 port for OpenBSD
(i have a draft of a port that builds and runs,
but testing is incomplete and quite some aspects need cleanup)
5. test the groff-1.25 release candidate
(i have an extremely hackish draft of a port that builds and runs,
but almost nothing has been tested with it yet)
Systematically testing groff-master with OpenBSD make(1) is part of
item 5, which is why i didn't come round to that yet.
Your plan for a 1.24 bugfix release made me insert an item 0,
0. test security bugfixes
for two reasons: security-related stuff normally takes precedence,
and of course the fixes also need to be included in item 3 once the
official groff release is out of the door.
This new item 0 also requires testing from master with OpenBSD make,
which is why i did that today.
Yours,
Ingo
