Re: no license on some test modules

[Eric Blake]

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