Jim Meyering <jim <at> meyering.net> writes: > > And indeed, there can be circular dependencies. I tested the same m4 setup on > > mingw. If libtests.a is listed first, progname.o is not included. But if it > > is listed second only, then gl_array_list.o generates a missing link to xmalloc > > and friends. The only solution is repeating the LDADD. I'm committing the > > following: > > > > Good catch. > Thanks for dealing with it.
This may not be the end of the story. For M4 head, it is now triggering a libtool bug - libtool mistakenly canonicalizes its link line, and discards one of the two instances of $(local_ldadd), which means we are right back to the link failures. make[5]: `test-alloca-opt.exe' is up to date. /bin/sh ../../libtool --tag=CC --mode=link gcc -std=gnu99 -gdwarf-2 -Wall - Werror -o test-array_list.exe test-array_list.o libtests.a ../../gnu/libgnu.la libtests.a /usr/local/lib/libintl.dll.a - liconv -L/usr/local/lib libtool: link: gcc -std=gnu99 -gdwarf-2 -Wall -Werror -o .libs/test- array_list.exe test-array_list.o ../../gnu/.libs/libgnu.a libtests.a /usr/local/lib/libintl.dll.a /usr/lib/libiconv.dll.a -L/usr/local/lib libtests.a(gl_array_list.o): In function `gl_array_create_empty': ../../../tests/gnu/gl_array_list.c:61: undefined reference to `_xmalloc' Maybe we need to make libtests.a shared if the gnulib library is shared? -- Eric Blake
