Re: Mac OS X 10.2.8 HEAD test failures.

2007-12-11 Thread Ralf Wildenhues
Hi Peter,

* Peter O'Gorman wrote on Tue, Dec 11, 2007 at 05:11:47PM CET:
> Ralf Wildenhues wrote:
> 
> > That's a bug, thanks for catching.  Does it work if _LT_CHECK_BUILDDIR
> > is only m4_require'd?
> > 
> > I assume if that's fixed, there will still be more issues.
> > 
> 
> It works a bit better, now tests fail saying "Autoconf version 2.58 or
> higher is required for this script" which is far more reasonable.
> 
> I am not sure what to do in these cases, sure the tools are old, but
> people will download libtool-2.x and run ./configure; make; make check,
> and it will fail simply because they have older automake & autoconf.
> 
> Should we print a warning at make check time warning users that their
> versions of automake and autoconf are too old to run the testsuite?

For the tests for which it is ok that older autotools are insufficient,
we should just skip the individual test.  I haven't had a chance to look
at the tests to see which ones should work and which ones shouldn't.
In any case the old-iface ones should.

Cheers,
Ralf



___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: circular library dependencies

2007-12-11 Thread Ralf Wildenhues
Hi Eric,

* Eric Blake wrote on Tue, Dec 11, 2007 at 08:16:21PM CET:
> 
> But now with m4 head, this is tripping up libtool, which doesn't respect 
> circular library dependencies:

And rightly and documentedly so.

> How do we go about solving this?

Put --preserve-dup-deps in AM_LIBTOOLFLAGS.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


circular library dependencies

2007-12-11 Thread Eric Blake
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


Re: Mac OS X 10.2.8 HEAD test failures.

2007-12-11 Thread Peter O'Gorman
Ralf Wildenhues wrote:

> That's a bug, thanks for catching.  Does it work if _LT_CHECK_BUILDDIR
> is only m4_require'd?
> 
> I assume if that's fixed, there will still be more issues.
> 

It works a bit better, now tests fail saying "Autoconf version 2.58 or
higher is required for this script" which is far more reasonable.

I am not sure what to do in these cases, sure the tools are old, but
people will download libtool-2.x and run ./configure; make; make check,
and it will fail simply because they have older automake & autoconf.

Should we print a warning at make check time warning users that their
versions of automake and autoconf are too old to run the testsuite?

Peter
-- 
Peter O'Gorman
http://pogma.com


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool