On Tue, Jan 13, 2026 at 12:44:21AM +0100, Bruno Haible wrote: > Eric Blake wrote: > > When updating m4 branch-1.6 to the latest gnulib (last done in May > > 2025, so before this patch), I'm now hitting: > > > > /usr/bin/ld: builtin.o: in function `m4_maketemp': > > /home/eblake/m4-1.6/src/builtin.c:1625:(.text+0x4128): undefined reference > > to `rpl_obstack_printf' > > /usr/bin/ld: /home/eblake/m4-1.6/src/builtin.c:1636:(.text+0x4415): > > undefined reference to `rpl_obstack_printf' > > /usr/bin/ld: debug.o: in function `trace_header': > > /home/eblake/m4-1.6/src/debug.c:327:(.text+0x1042): undefined reference to > > `rpl_obstack_printf' > > /usr/bin/ld: /home/eblake/m4-1.6/src/debug.c:329:(.text+0x1069): undefined > > reference to `rpl_obstack_printf' > > /usr/bin/ld: /home/eblake/m4-1.6/src/debug.c:330:(.text+0x1085): undefined > > reference to `rpl_obstack_printf' > > /usr/bin/ld: debug.o:/home/eblake/m4-1.6/src/debug.c:332: more undefined > > references to `rpl_obstack_printf' follow > > I reproduce it. > > The explanation is: > config.status has this: > > S["M4_LIBOBJS"]=" asnprintf.o fopen.o printf-args.o printf-parse.o > vasnprintf.o" > S["M4_libm4_LIBOBJS"]=" libm4_a-asnprintf.o libm4_a-fopen.o > libm4_a-printf-args.o libm4_a-printf-parse.o libm4_a-vasnprintf.o" > > S["M4tests_LIBOBJS"]=" obstack_printf.o strerror_r.o" > S["M4tests_libm4_LIBOBJS"]=" libm4_a-obstack_printf.o libm4_a-strerror_r.o" > > So, there are two uses of gnulib: once for M4, once for M4tests. > The module 'obstack-printf' exists only in the second one.
So maybe the short-term fix is to figure out why the module is not explicitly being used in the main M4 executable (since it is more than just the tests using it), and figuring out why I had mistakenly assumed it was already explicit. > > The comment in gnulib/modules/obstack-printf-posix explains part of the mess. > > The other part of the mess is that > * There is only one m4/gnulib-comp.m4 file, > * It contains > AC_DEFUN([M4_INIT], > [ > AC_CONFIG_LIBOBJ_DIR([tests]) > > So, there is really a mess going on between the lib/ and the tests/ > directories. > > IMO the cause of the mess is that there is no explicit 'gnulib-tool' > invocation. This branch uses the pre-2006 (more than 20 years old) way of > using Gnulib with gnulib-cache.m4 as a "memory" of the last gnulib-tool > invocation. > > I would recommend to fix this like in so many GNU packages that use > an explicit gnulib-tool invocation, like in GNU sed for example. I am inclined to place at least some of the blame for this on m4's use of Gary's alternative bootstrap script, rather than sticking with the one that many other gnulib projects use. However, since Gary used m4 as one of his test-beds for developing his variation, it makes things a bit more awkward on deciding whether his bootstrap should remain a separate project, whether it is getting enough active development, and whether m4 should continue to use it or whether I should revert m4 back to using gnulib's version. At any rate, gnulib-tool is much faster now than when Gary first forked bootstrap, so the reasoning behind staying on the bootstrap fork is worth revisiting. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
