This week, gnulib moved to the scenario where it will create circular library dependencies. For example, on branch-1_4 of m4, when compiling the test program tests/test-gl_array, lib/libm4.a depends on program_name provided by progname.o in tests/libtests.a, but tests/libtests.a depends on xmalloc provided by xalloc.o in lib/libm4.a. So the solution was to make gnulib output the same library twice on the link line.
But now with m4 head, this is tripping up libtool, which doesn't respect circular library dependencies: /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' Even though libtests.a was properly specified both before and after gnu/libgnu.la in the original tool, libtool discarded the first instance of libtests.a when generating the link command, leading to link failure. How do we go about solving this? -- Eric Blake _______________________________________________ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool