Re: [PATCH 366] Libtoolize now advises AC_CONFIG_MACRO_DIR use where appropriate.
Hi Gary, * Gary V. Vaughan wrote on Wed, Apr 23, 2008 at 12:04:02AM CEST: On 22 Apr 2008, at 15:27, Ralf Wildenhues wrote: I'm wondering a bit whether we should recommend putting ACLOCAL_AMFLAGS = -I MACRO-DIR in the toplevel Makefile.am. Agreed. I'll add that before I push. It seems that one of your patches causes this test failure: Cheers, Ralf # -*- compilation -*- 10. libtoolize.at:651: testing ... ../../libtool/tests/libtoolize.at:685: /home/ralf/libtool/write/build/libtoolize --copy ../../libtool/tests/libtoolize.at:692: $ACLOCAL stderr: stdout: ../../libtool/tests/libtoolize.at:759: /home/ralf/libtool/write/build/libtoolize --copy --- expout 2008-04-23 22:41:22.0 +0200 +++ /home/ralf/libtool/write/build/tests/testsuite.dir/at-stdout 2008-04-23 22:41:22.0 +0200 @@ -1,3 +1,6 @@ +libtoolize: You should add the contents of the following files to `aclocal.m4': +libtoolize: `/home/ralf/libtool/write/build/../libtool/libltdl/m4/libtool.m4' +libtoolize: `/home/ralf/libtool/write/build/../libtool/libltdl/m4/lt~obsolete.m4' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. 10. libtoolize.at:651: 10. verbatim aclocal.m4 w/o AC_CONFIG_MACRO_DIR (libtoolize.at:651): FAILED (libtoolize.at:759)
Re: [libtool 2.2.2] testsuite: ... 38 ... 56 ... failed
Hello Michael, * Michael Haubenwallner wrote on Sat, Apr 19, 2008 at 11:46:32AM CEST: On Fri, 2008-04-18 at 21:24 +0200, Ralf Wildenhues wrote: * Michael Haubenwallner wrote on Fri, Apr 18, 2008 at 04:22:03PM CEST: [lt-2.2.2-testsuite-usrlocal.patch] proposed patch to change any default or explicit occurrence of /usr/local/* to /tmp/nonexistent, although it actually hurts only in template.at and am-subdir.at (inherits prefix from testsuite.at) here. Why not /nonexistent? Somebody could create /tmp/nonexistent? Or is it that you would like to be able to create it (as non-root) in order to play with Libtool? Use whatever /nonexistent you want - I've just seen using prefix=/tmp/inst in some *.at's, so my mind was accidentally bound to /tmp. Ah, ok. Good thing you mention that. The choice of /tmp/inst in destdir.at (you must enable that specifically, for safe systems), is used because the test actually installs stuff there. So it would not be a good idea to use /tmp/nonexistent there. I've applied your patch like this, fixing another trivial typo. Thanks again, Ralf 2008-04-23 Michael Haubenwallner [EMAIL PROTECTED] Use /nonexistent as destination for files not to be installed. * tests/darwin.at (darwin fat compile): Fix typo. * tests/inherited_flags.at (inherited_linker_flags): Change -rpath to /nonexistent. This helps to avoid accidentally picking up libraries below /usr/local. * tests/template.at (simple template test): Likewise. Fixes test failure for additional incompatible libstdc++ in /usr/local. * tests/testsuite.at (configure_options): Add --prefix=/nonexistent. diff --git a/tests/darwin.at b/tests/darwin.at index adc0db6..7e6d07e 100644 --- a/tests/darwin.at +++ b/tests/darwin.at @@ -86,7 +86,7 @@ AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC -o libfoo.la $CPPFLAGS $CFLAGS $LDFL AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC -c -o bar.lo $CPPFLAGS $CFLAGS -arch ppc -arch i386 bar.c],[0],[ignore],[ignore]) -AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC -o libbar.la $CPPFLAGS $CFLAGS $LDFLAGS -arch ppc -arch i386 bar.lo libfoo.la -rpath /nonexistant],[0],[ignore],[ignore]) +AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC -o libbar.la $CPPFLAGS $CFLAGS $LDFLAGS -arch ppc -arch i386 bar.lo libfoo.la -rpath /nonexistent],[0],[ignore],[ignore]) AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC -c -o main.lo $CPPFLAGS $CFLAGS -arch ppc -arch i386 main.c],[0],[ignore],[ignore]) diff --git a/tests/inherited_flags.at b/tests/inherited_flags.at index 7a2fc4e..1efdf16 100644 --- a/tests/inherited_flags.at +++ b/tests/inherited_flags.at @@ -1,6 +1,6 @@ # inherited_flags.at -- test inherited_linker_flags -*- Autotest -*- # -# Copyright (C) 2005, 2006, 2007 Free Software Foundation, Inc. +# Copyright (C) 2005, 2006, 2007, 2008 Free Software Foundation, Inc. # Written by Peter O'Garman, 2005 # # This file is part of GNU Libtool. @@ -56,9 +56,9 @@ $LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c -o bar.lo bar.c $LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c -o baz.lo baz.c $LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c -o both.lo both.c $LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c -o main.lo main.c -$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libfoo.la foo.lo -rpath /usr/local/lib -no-undefined -$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libbar.la bar.lo -rpath /usr/local/lib -no-undefined -$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libboth.la both.lo -rpath /usr/local/lib -no-undefined +$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libfoo.la foo.lo -rpath /nonexistent -no-undefined +$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libbar.la bar.lo -rpath /nonexistent -no-undefined +$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libboth.la both.lo -rpath /nonexistent -no-undefined mv libfoo.la libfoo.la.bak @@ -73,7 +73,7 @@ mv libboth.la libboth.la.bak sed -e s/^inherited_linker_flags.*/inherited_linker_flags='-llt_inlikely_existing_lib -llt_unlikely_existing_lib'/g libboth.la.bak libboth.la rm libboth.la.bak -AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libbaz.la baz.lo -no-undefined -rpath /usr/local/lib ./libfoo.la ./libbar.la], +AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libbaz.la baz.lo -no-undefined -rpath /nonexistent ./libfoo.la ./libbar.la], [ignore],[stdout],[ignore]) # We used to grep for # 'llt_[[ui]]nlikely_existing_lib.*llt_[[ui]]nlikely_existing_lib' @@ -82,19 +82,19 @@ AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libbaz.la baz.lo AT_CHECK([$LIBTOOL --features | grep 'disable shared libraries' (exit 77)], [1], [ignore]) AT_CHECK([grep 'lt_[[ui]]nlikely_existing_lib.*lt_[[ui]]nlikely_existing_lib' stdout], [0],[ignore],[ignore]) -AT_CHECK([$LIBTOOL
Re: [PATCH 366] Libtoolize now advises AC_CONFIG_MACRO_DIR use where appropriate.
Hi Ralf, On 23 Apr 2008, at 17:26, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Wed, Apr 23, 2008 at 12:04:02AM CEST: On 22 Apr 2008, at 15:27, Ralf Wildenhues wrote: I'm wondering a bit whether we should recommend putting ACLOCAL_AMFLAGS = -I MACRO-DIR in the toplevel Makefile.am. Agreed. I'll add that before I push. It seems that one of your patches causes this test failure: Cheers, Ralf # -*- compilation -*- 10. libtoolize.at:651: testing ... ../../libtool/tests/libtoolize.at:685: /home/ralf/libtool/write/ build/libtoolize --copy ../../libtool/tests/libtoolize.at:692: $ACLOCAL stderr: stdout: ../../libtool/tests/libtoolize.at:759: /home/ralf/libtool/write/ build/libtoolize --copy --- expout 2008-04-23 22:41:22.0 +0200 +++ /home/ralf/libtool/write/build/tests/testsuite.dir/at-stdout 2008-04-23 22:41:22.0 +0200 @@ -1,3 +1,6 @@ +libtoolize: You should add the contents of the following files to `aclocal.m4': +libtoolize: `/home/ralf/libtool/write/build/../libtool/libltdl/m4/ libtool.m4' +libtoolize: `/home/ralf/libtool/write/build/../libtool/libltdl/m4/ lt~obsolete.m4' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. 10. libtoolize.at:651: 10. verbatim aclocal.m4 w/o AC_CONFIG_MACRO_DIR (libtoolize.at:651): FAILED (libtoolize.at:759) Can you try again with a fresh checkout? I can't reproduce here :-( ] history 1998 git clone [EMAIL PROTECTED]:/srv/git/libtool.git 1999 cd libtool 2000 ./bootstrap 2001 mkdir +build 2002 cd +build 2003 ../configure 2004 make ] make check-local ... Libtoolize operation. 1: libtoolize macro installation ok 2: libtoolize macro directory mismatch error ok 3: libtoolize macro serial update ok 4: libtoolize config files serial update ok 5: diagnose missing LT_CONFIG_LTDL_DIR ok 6: copy ltdl.m4 with shared macro directoryok 7: correctly parse LTDL_INIT from configure.ac ok 8: diagnose missing LTDL_INIT invocation ok 9: upgrading verbatim style aclocal.m4 ok 10: verbatim aclocal.m4 w/o AC_CONFIG_MACRO_DIR ok 11: nonrecursive ltdl with AC_CONFIG_MACRO_DIR ok 12: subproject ltdl with non-shared directories ok ... ## - ## ## Test results. ## ## - ## 65 tests behaved as expected. 6 tests were skipped. [[no fortran or java on this host]] Maybe a difference in our installed automake and/or libtool versions? I have 1.10.1 and 2.2.3a master HEAD respectively. Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ PGP.sig Description: This is a digitally signed message part
Re: Libtool performance status (part 1.2965)
Bob Friesenhahn wrote: libtool 1.5.26: real 4:53.877 user 3:26.912 sys 1:25.275 libtool 1.2965 2008-04-22 (bash) real 4:03.745 user 3:19.232 sys41.018 Bob, thank you for testing and giving us these numbers. This improvement is almost entirely due to Ralf, so I encourage everyone who is subscribed to this list to seek him out and buy him many beers. Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool performance status (part 1.2965)
On Wed, 23 Apr 2008, Peter O'Gorman wrote: This improvement is almost entirely due to Ralf, so I encourage everyone who is subscribed to this list to seek him out and buy him many beers. Please take care not to buy Ralf too many beers at once since then his productivity may decrease. Spread the beers out over a year or so. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: move to git
Hi Jim, * Jim Meyering wrote on Sat, Apr 19, 2008 at 11:53:23AM CEST: I'm beginning to think that our time might be better spent investigating an alternate conversion method: cvs2git. Unfortunately, I might not have time for that right away. Are there known deficiencies of git cvsimport? (I haven't tried either yet, just trying to avoid work that may be known to be in vain.) Or is that because both use cvsps? Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: move to git
Ralf Wildenhues [EMAIL PROTECTED] wrote: * Jim Meyering wrote on Sat, Apr 19, 2008 at 11:53:23AM CEST: I'm beginning to think that our time might be better spent investigating an alternate conversion method: cvs2git. Unfortunately, I might not have time for that right away. Are there known deficiencies of git cvsimport? Hi Ralf, I gave up on git-cvsimport a while ago, since it was so slow compared to parsecvs, but mainly because it would actually *reverse* revisions some time. E.g., it would sometimes put CVS version 1.2 before 1.1. (I haven't tried either yet, just trying to avoid work that may be known to be in vain.) Or is that because both use cvsps? At least that one was a cvsps problem. I'll try to find time to test cvs2git RSN. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: move to git
Jim Meyering [EMAIL PROTECTED] writes: I gave up on git-cvsimport a while ago, since it was so slow compared to parsecvs, but mainly because it would actually *reverse* revisions some time. E.g., it would sometimes put CVS version 1.2 before 1.1. That's a cvsps problem, not specific to git cvsimport. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ http://lists.gnu.org/mailman/listinfo/libtool
