FYI: 353-gary-argz-ac-check-funcs.patch
Applied to HEAD. Index: ChangeLog from Gary V. Vaughan [EMAIL PROTECTED] * libltdl/m4/argz.m4 (AC_CHECK_FUNCS): Also use our replacement argz if the system argz_add or argz_count are missing. Report by Juan Manuel Guerrero [EMAIL PROTECTED]. Index: libltdl/m4/argz.m4 === RCS file: /sources/libtool/libtool/libltdl/m4/argz.m4,v retrieving revision 1.6 diff -u -u -r1.6 argz.m4 --- libltdl/m4/argz.m4 26 Apr 2007 22:24:16 - 1.6 +++ libltdl/m4/argz.m4 29 Feb 2008 21:03:38 - @@ -25,8 +25,8 @@ #endif]) ARGZ_H= -AC_CHECK_FUNCS([argz_append argz_create_sep argz_insert argz_next \ - argz_stringify], [], [ARGZ_H=argz.h; AC_LIBOBJ([argz])]) +AC_CHECK_FUNCS([argz_add argz_append argz_count argz_create_sep argz_insert \ + argz_next argz_stringify], [], [ARGZ_H=argz.h; AC_LIBOBJ([argz])]) dnl if have system argz functions, allow forced use of dnl libltdl-supplied implementation (and default to do so -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ _ This patch notification generated by vcsapply version 1.0 http://savannah.gnu.org/projects/cvs-utils pgppMxSHNoGw1.pgp Description: PGP signature
Uh, oh, libtool does not build any more
With very latest CVS updates from Gary I am seeing this failure on my various host types: gmake all-recursive gmake[1]: Entering directory `/scratch/bfriesen/build/libtool-head' gmake[2]: Entering directory `/scratch/bfriesen/build/libtool-head' test -f doc/.dirstamp || gmake doc/.dirstamp gmake[3]: Entering directory `/scratch/bfriesen/build/libtool-head' gmake[3]: `/home/bfriesen/src/gnu/libtool-head/doc/.dirstamp' is up to date. gmake[3]: Leaving directory `/scratch/bfriesen/build/libtool-head' depbase=`echo libltdl/argz.lo | sed 's|[^/]*$|.deps/|;s|\.lo$||'`;\ /bin/bash ./libtool --tag=CC --mode=compile gcc-4.2.1 -DHAVE_CONFIG_H -I. -I/home/bfriesen/src/gnu/libtool-head -DLT_CONFIG_H='config.h' -DLTDL -I. -I/home/bfriesen/src/gnu/libtool-head -Ilibltdl -I/home/bfriesen/src/gnu/libtool-head/libltdl -I/home/bfriesen/src/gnu/libtool-head/libltdl/libltdl -O2 -MT libltdl/argz.lo -MD -MP -MF $depbase.Tpo -c -o libltdl/argz.lo /home/bfriesen/src/gnu/libtool-head/libltdl/argz.c \ mv -f $depbase.Tpo $depbase.Plo libtool: compile: gcc-4.2.1 -DHAVE_CONFIG_H -I. -I/home/bfriesen/src/gnu/libtool-head -DLT_CONFIG_H=config.h -DLTDL -I. -I/home/bfriesen/src/gnu/libtool-head -Ilibltdl -I/home/bfriesen/src/gnu/libtool-head/libltdl -I/home/bfriesen/src/gnu/libtool-head/libltdl/libltdl -O2 -MT libltdl/argz.lo -MD -MP -MF libltdl/.deps/argz.Tpo -c /home/bfriesen/src/gnu/libtool-head/libltdl/argz.c -fPIC -DPIC -o libltdl/.libs/argz.o libtool: compile: gcc-4.2.1 -DHAVE_CONFIG_H -I. -I/home/bfriesen/src/gnu/libtool-head -DLT_CONFIG_H=config.h -DLTDL -I. -I/home/bfriesen/src/gnu/libtool-head -Ilibltdl -I/home/bfriesen/src/gnu/libtool-head/libltdl -I/home/bfriesen/src/gnu/libtool-head/libltdl/libltdl -O2 -MT libltdl/argz.lo -MD -MP -MF libltdl/.deps/argz.Tpo -c /home/bfriesen/src/gnu/libtool-head/libltdl/argz.c -o libltdl/argz.o /dev/null 21 /bin/bash ./libtool --tag=CC --mode=link gcc-4.2.1 -O2 -no-undefined -version-info 8:0:1 -dlpreopen libltdl/dlopen.la -L/usr/local/lib -R/usr/local/lib -o libltdl/libltdl.la -rpath /usr/local/lib libltdl/loaders/libltdl_libltdl_la-preopen.lo libltdl/libltdl_libltdl_la-lt__alloc.lo libltdl/libltdl_libltdl_la-lt_dlloader.lo libltdl/libltdl_libltdl_la-lt_error.lo libltdl/libltdl_libltdl_la-ltdl.lo libltdl/libltdl_libltdl_la-slist.lo libltdl/argz.lo libtool: link: `libltdl/loaders/libltdl_libltdl_la-preopen.lo' is not a valid libtool object gmake[2]: *** [libltdl/libltdl.la] Error 1 gmake[2]: Leaving directory `/scratch/bfriesen/build/libtool-head' == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Uh, oh, libtool does not build any more
On Fri, 29 Feb 2008, Gary V. Vaughan wrote: Thanks for the report. I'll hold the release until we figure out what's broken, however I can't reproduce that error on my Mac (where I have no fortran or java compilers): These are the tools I am using on the machine that did the bootstrap: autoconf (GNU Autoconf) 2.61 automake (GNU automake) 1.10.1 m4 (GNU M4) 1.4.10 GNU sed version 3.02 (old, I know, but somehow better) expr (GNU coreutils) 6.9 GNU Awk 3.1.5 gcc (GCC) 4.2.1 Builds are done outside of the source tree. Building under OS-X fails the same. All targets fail the same. What happens with a fresh checkout on your machine? Not sure. I will find out later. I am happy to provide you with an account on my machines if it will help you with this issue, or in the future. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Uh, oh, libtool does not build any more
Hi Bob, On 29 Feb 2008, at 19:44, Bob Friesenhahn wrote: On Fri, 29 Feb 2008, Gary V. Vaughan wrote: Thanks for the report. I'll hold the release until we figure out what's broken, however I can't reproduce that error on my Mac (where I have no fortran or java compilers): These are the tools I am using on the machine that did the bootstrap: autoconf (GNU Autoconf) 2.61 automake (GNU automake) 1.10.1 Same as me. m4 (GNU M4) 1.4.10 I'm using a recent self-built 1.9a snapshot, not that that should be fatal for you... GNU sed version 3.02 (old, I know, but somehow better) expr (GNU coreutils) 6.9 GNU Awk 3.1.5 gcc (GCC) 4.2.1 I'm using the OS X Leopard supplied tools here (BSD flavoured for the most part, excepting Apple's hacked gcc 4.0.1), although that should be causing trouble for me rather than you if these are the critical differences. Builds are done outside of the source tree. Building under OS-X fails the same. All targets fail the same. What happens with a fresh checkout on your machine? Not sure. I will find out later. I am happy to provide you with an account on my machines if it will help you with this issue, or in the future. Thanks. If a fresh libtool checkout still fails for you, then I'll be delighted to take you up on that kind offer. If the fresh libtool checkout works for you, however, then likely you'll be in a better position than I to figure out what went wrong in your GraphicsMagick tree... I'm close to turning in for the night, but will look forward to your news in the morning ;-) 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: Uh, oh, libtool does not build any more
On Fri, 29 Feb 2008, Bob Friesenhahn wrote: What happens with a fresh checkout on your machine? Not sure. I will find out later. That did it! Perhaps there is something not quite right in the maintainer dependencies or a timestamp was wrong. Testing builds now ... Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Uh, oh, libtool does not build any more
In a recursive diff between the broken CVS directory and the working one, I see this difference: Common subdirectories: libtool-head-old/libltdl/CVS and libtool-head/libltdl/CVS diff -r libtool-head-old/libltdl/Makefile.in libtool-head/libltdl/Makefile.in 47,48c47,48 config/install-sh config/ltmain.sh config/mdate-sh \ config/missing config/texinfo.tex lt__dirent.c lt__strl.c --- config/install-sh config/ltmain.sh \ config/missing lt__dirent.c lt__strl.c The difference does not seem to explain the strange substitution I was seeing. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Libtool head test status
These are results of tests I ran this evening. These are all builds from outside the source tree, including MinGW and Cygwin, which used a SMB mount to a Unix filesystem. Solaris 9 SPARC/GCC === 61 tests behaved as expected. 3 tests were skipped. Solaris 10 SPARC/GCC 61 tests behaved as expected. 3 tests were skipped. Solaris 10 x86/GCC == 61 tests behaved as expected. 3 tests were skipped. FreeBSD 5.4 === 62 tests behaved as expected. 2 tests were skipped. Apple OS-X Leopard PPC == 58 tests behaved as expected. 6 tests were skipped. Cygwin (old) on Windows XP == ERROR: 60 tests were run, 6 failed (3 expected failures). 4 tests were skipped. ## -- ## ## testsuite.log was created. ## ## -- ## Please send `tests/testsuite.log' and all information you think might help: To: [EMAIL PROTECTED] Subject: [libtool 2.1c] testsuite: 21 38 64 failed MinGW (old) on Windows XP = ERROR: 62 tests were run, 14 failed (3 expected failures). 2 tests were skipped. ## -- ## ## testsuite.log was created. ## ## -- ## Please send `tests/testsuite.log' and all information you think might help: To: [EMAIL PROTECTED] Subject: [libtool 2.1c] testsuite: 21 38 39 46 50 53 60 61 62 63 64 failed == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: FYI: 353-gary-argz-ac-check-funcs.patch
Hi Gary, On Fri, Feb 29, 2008 at 04:36:17PM -0500, Gary V. Vaughan wrote: Applied to HEAD. Index: ChangeLog from Gary V. Vaughan [EMAIL PROTECTED] * libltdl/m4/argz.m4 (AC_CHECK_FUNCS): Also use our replacement argz if the system argz_add or argz_count are missing. Report by Juan Manuel Guerrero [EMAIL PROTECTED]. Why is this patch necessary? You don't use the result of the tests anywhere. Cheers, Ralf
