Hello,
in order to verify Branden's pending security patches, i'm trying to
build groff-git-head on OpenBSD-current as described in INSTALL.REPO.
The reason i'm doing this as closely as possible to the upstream
build method and not in my usual OpenBSD port framework is that the
goal is to verify upstream bug fixes, which is best done as closely
as possible to what upstream is doing, and i'm *not* planning to
use the binaries resulting from the build in production, so not
using the OpenBSD port for this particular job causes no issues.
Either way, making sure that both the upstream build method works
and the OpenBSD port works is clearly useful.
As usual, the method described in INSTALL.REPO fails spectacularly
for multiple reasons. In this mail, i'm describing the first
issue that kills the build. Here is what i am doing:
# use the versions recommended in INSTALL.REPO -
# i also have newer versions installed,
# but it's usually best to use whatever upstream recommends
export AUTOMAKE_VERSION=1.14
export AUTOCONF_VERSION=2.69
./bootstrap 2>&1 | tee Log/bootstrap.log
mkdir build
cd build
# tell configure how we call the newest GNU texinfo
env ac_cv_prog_MAKEINFO=gmakeinfo ../configure --enable-maintainer-mode \
PROG_TEXI2DVI=gtexi2dvi 2>&1 | tee ../Log/configure.log
make 2>&1 | tee ../Log/build.log
That crashes saying:
make: don't know how to make lib/libgnu_a-asnprintf.o
(prerequisite of: lib/libgnu.a)
That results from this target rule:
lib/libgnu.a:
lib_libgnu_a_OBJECTS = am_lib_libgnu_a_OBJECTS
am__objects_1 ...
lib_libgnu_a_DEPENDENCIES = gl_libgnu_LIBOBJS =
lib/libgnu_a-asnprintf.o
lib/libgnu_a-fprintf.o
lib/libgnu_a-frexpl.o
lib/libgnu_a-printf-args.o
lib/libgnu_a-printf-parse.o
lib/libgnu_a-vasnprintf.o
EXTRA_lib_libgnu_a_DEPENDENCIES
empty?
lib/$(am__dirstamp)
On the other hand, we have this target rule:
lib/lib_libgnu_a-asnprintf.o: lib/asnprintf.c
... some compilation commands ...
So my preliminary conclusion is that gl_libgnu_LIBOBJS is wrong;
it should instead contain lib/lib_libgnu_a-asnprintf.o .
Now, where does the wrong value lib/libgnu_a-asnprintf.o come from?
Apparently, from gnulib_m4/gnulib-comp.m4 lines 854 ff .
The wrong line appears to be:
gl_libgnu_libobjs="$gl_libgnu_libobjs lib/$i_dir""libgnu_a-$i_base.$ac_objext"
That would have to be corrected to read:
gl_libgnu_libobjs="$gl_libgnu_libobjs
lib/$i_dir""lib_libgnu_a-$i_base.$ac_objext"
However, the file gnulib_m4/gnulib-comp.m4 is autogenerated by gnulib-tool.
How is gnulib-tool generating the erroneous line?
Searching for the string "gl_libgnu_libobjs" results in
$ grep -RFl gl_libgnu_libobjs
configure
gnulib_m4/gnulib-comp.m4
autom4te.cache/output.0
autom4te.cache/traces.0
autom4te.cache/output.1
autom4te.cache/traces.1
But those are all generated files, containing mostly the same snippets
as gnulib_m4/gnulib-comp.m4, which doesn't explain where these snippets
are coming from.
Oh, maybe it is coming from gnulib/gnulib-tool.sh
or from gnulib/pygnulib/GLEmiter.py .
It looks like the function func_emit_initmacro_end()
prints the wrong code with hardcoded "echo" statements:
echo "
${macro_prefix_arg}_${libname}_libobjs=\"\$${macro_prefix_arg}_${libname}_libobjs
${subdir}\$i_dir\"\"${libname}_a-\$i_base.\$ac_objext\""
which probably needs to be
echo "
${macro_prefix_arg}_${libname}_libobjs=\"\$${macro_prefix_arg}_${libname}_libobjs
${subdir}\$i_dir\"\"lib_${libname}_a-\$i_base.\$ac_objext\""
instead.
Now, if i understand correctly, gnulib-tool is run by autoreconf,
which is run by bootstrap. But bootstrap also does
Updating file gnulib_m4/gnulib-tool.m4 (backup in gnulib_m4/gnulib-tool.m4~)
so editing *anything* and re-running bootstrap is somewhat dubious.
All the same, i tried the following.
I first ran bootstrap, then edited gnulib/gnulib-tool.sh
as indicated above, deleted autom4te.cache, gnulib_m4/gnulib-comp.m4,
and ./configure, and re-ran bootstrap. This caused the correct
gltests_libgnu_libobjs="$gltests_libgnu_libobjs
lib/$i_dir""lib_libgnu_a-$i_base.$ac_objext"
to show up in ./configure. Now, rerunning ../configure caused the correct
gl_libgnu_LIBOBJS = lib/lib_libgnu_a-asnprintf.o ...
to show up in build/Makefile. And finally, "make" did
CC lib/lib_libgnu_a-asnprintf.o
as expected and progressed a bit further, until it died again saying
GEN font/devps/symbolsl.pfa
Using $< in a non-suffix rule context is a GNUmake idiom (Makefile:19502)
which is probably due to this target rule:
$(DOC_LINE_LAYOUT_EPS): doc/line-layout.roff ...
... && $(DOC_GROFF) -p -T ps -P -b16 $< ...
but it looks like there is more, similar breakage in other targets.
Now, i have no idea whether this is a bug in groff (which seems
possible) or in gnulib (which seems likely).
For two reasons, i'm not reporting this to gnulib. First, i am
not convinced it actually is a gnulib bug, maybe groff is using
gnulib wrong? Second and more importantly, gnulib is such a
giant, hot, steaming mess that i don't feel comfortable talking
to the gnulib maintainers. I just don't have the patience for
dealing with them, and i fear i might end up insulting them
rather than saying anything productive.
On the other hand, i refrained from reporting this to the groff
bug tracker because it does seem likely that the bug is in gnulib
rather than in groff.
To be honest, i have no idea how to debug the lib_libgnu_a-asnprintf.o
fiasco further and how or where to report it, let alone how to
fix it properly.
If the above is not clear enough to understand the root cause,
does anybody want to receive a mail containing tens of thousands
of lines of logs and autogenerated m4 files and Makefiles?
I should probably not send those to a mailing list or attach
them to a bug tracker.
Once again, for the umpteenth time, i lost half an afternoon
searching for what's going on in the maze of the groff build system.
I'll now continue fixing stuff that is clearly groff's fault (like
the $< already mentioned above), for now relying on my obviously
highly fragile workaround described above, hoping that i will
eventually get groff to build, such that i can then do some actual
testing of Branden's security fixes.
Yours,
Ingo
