Re: Building CVS HEAD libtool outside of source directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bob Friesenhahn on 10/19/2007 11:23 AM: It does not really matter what POSIX says. Do you not agree that the text of the FreeBSD/OS-X manual page says that the fseeko in your patch will be ignored? For WRITES. But the bug was for READS. Not knowing what m4 is really trying to do, is there a reason that 'w+' is not being used? Yes. The file is intentionally opened in append mode, so that new diversion text will go to the end, but dumping the diversion starts from the beginning (after the seek, of course). - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHGOqr84KuGfSFAYARAp6wAJ9V/sVPOGUXUPDzNLl7Iq2r4jHKtwCeMmZd 7yR05GbWcIHL6Dtq8IzL52E= =7WKq -END PGP SIGNATURE-
Re: Building CVS HEAD libtool outside of source directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Gary V. Vaughan on 10/19/2007 10:50 AM: % ls -l configure -rwxr-xr-x 1 bfriesen home 28205 Oct 19 10:57 configure* Hmm. Can you tar up that configure, and the output from: sh -vx ./bootstrap 21 | tee bootstrap.log And attach it to your followup so I can try to figure out what is going wrong, please? The symptoms are the same as what drove the thread where I fixed the bug in M4 - on platforms where fopen(a+) starts at eof, and where autoconf generates more that 512k in diversions, the diversions spill to a temporary file, then it is reopened and read, but reading at eof means the entire diversion is lost, rather than output correctly. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHGOhM84KuGfSFAYARAjNzAJ97eqsYEnlzgL4CQJ19nlQe3wm67gCfUUDm YEcimVbxs8AffRkqmZJ3LGY= =7gTv -END PGP SIGNATURE-
Re: Building CVS HEAD libtool outside of source directory
I patched m4 1.4.10 with the small patch you recommended and things are looking much better now. On OS-X, the test suite passes with only expected failures. On FreeBSD there are still some remaining unexpected failures: ## - ## ## Test results. ## ## - ## ERROR: 53 tests were run, 8 failed (3 expected failures). 2 tests were skipped. ## -- ## ## testsuite.log was created. ## ## -- ## The problems seem to be mostly related to libltdl symbols. A gzipped testsuite.log from FreeBSD 5.4 is attached. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ testsuite.log.gz Description: Binary data
Re: Building CVS HEAD libtool outside of source directory
On Fri, 19 Oct 2007, Eric Blake wrote: Facinating. I would expect opening for append to open at the tail (end) of the file although I find your use of 'head' and 'tail' to be confusing since a file is not a queue. POSIX says the state of the first ftell() on a file after fopen(a+) is implementation-defined - it can be either offset 0 (as glibc) or the end of the file (as on BSD). It isn't until you do either an explicit seek (which is what my m4 patch adds) or a write that the position is then well-defined. It does not really matter what POSIX says. Do you not agree that the text of the FreeBSD/OS-X manual page says that the fseeko in your patch will be ignored? ``a+'' Open for reading and writing. The file is created if it does not exist. The stream is positioned at the end of the file. Subse- quent writes to the file will always end up at the then current end of file, irrespective of any intervening fseek(3) or similar. Not knowing what m4 is really trying to do, is there a reason that 'w+' is not being used? Append obviously intends to write to the end of the file but it seems that you want to write to the front, which is what 'w+' intends to do. Otherwise the semantics seem the same. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Building CVS HEAD libtool outside of source directory
On Fri, 19 Oct 2007, Eric Blake wrote: According to Bob Friesenhahn on 10/19/2007 10:15 AM: % ls -l configure -rwxr-xr-x 1 bfriesen home 28205 Oct 19 10:57 configure* There is a known bug in m4 1.4.10 on platforms where fopen(..., a+) opens at the tail of a file, rather than the head. It looks like this is what is biting you. Facinating. I would expect opening for append to open at the tail (end) of the file although I find your use of 'head' and 'tail' to be confusing since a file is not a queue. From the Solaris manual page: a+ or ab+ or a+bAppend; open or create file for update, writing at end-of-file. and from the FreeBSD manual page: ``a+'' Open for reading and writing. The file is created if it does not exist. The stream is positioned at the end of the file. Subse- quent writes to the file will always end up at the then current end of file, irrespective of any intervening fseek(3) or similar. OS-X's man page says the same since it borrows from FreeBSD. It sounds like your code is fighting against the intentions of a+ and that the seek in your referenced patch will be ignored by FreeBSD and OS X and should probably be ignored by Solaris as well. Maybe freopen() can help? Bob Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Building CVS HEAD libtool outside of source directory
On Fri, 19 Oct 2007, Gary V. Vaughan wrote: and nothing gets done. Bah. What is the relative path back to your source directory? I'll try to reproduce next time I am hacking on libtool... ../../../../home/bfriesen/src/gnu/libtool-head Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Building CVS HEAD libtool outside of source directory
Hi Bob, On 19 Oct 2007, at 17:15, Bob Friesenhahn wrote: There is clearly something seriously wrong with bootstrap of CVS HEAD on my FreeBSD system. In order to try to investigate why the VPATH build is now seriously failing tests on my FreeBSD and OS X systems, I checked out the libtool sources from CVS to a clean directory on the FreeBSD system. I then did a 'bootstrap'. The resulting configure script is totally borked as illustrated by this: shaggy:~/build/libtool-head-cvs% ./configure --help libtool configure 2.1a generated by GNU Autoconf 2.61 Copyright (C) 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc. This configure script is free software; the Free Software Foundation gives unlimited permission to copy, distribute and modify it. shaggy:~/build/libtool-head-cvs% % ls -l configure -rwxr-xr-x 1 bfriesen home 28205 Oct 19 10:57 configure* Hmm. Can you tar up that configure, and the output from: sh -vx ./bootstrap 21 | tee bootstrap.log And attach it to your followup so I can try to figure out what is going wrong, please? Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912 PGP.sig Description: This is a digitally signed message part
Re: Building CVS HEAD libtool outside of source directory
According to Bob Friesenhahn on 10/19/2007 10:15 AM: % ls -l configure -rwxr-xr-x 1 bfriesen home 28205 Oct 19 10:57 configure* There is a known bug in m4 1.4.10 on platforms where fopen(..., a+) opens at the tail of a file, rather than the head. It looks like this is what is biting you. http://lists.gnu.org/archive/html/bug-m4/2007-07/msg00016.html -- Eric Blake
Re: Building CVS HEAD libtool outside of source directory
On Fri, 19 Oct 2007, Gary V. Vaughan wrote: All of my builds are done with VPATH, and I use the commit script with them just fine! When bootstrap completes it says this: WARNING: You might want to regenerate `commit' and `libltdl/config/mailnotify' WARNING: after you have run `configure' to discover the real whereabouts WARNING: of `sed', `grep' etc. like this: WARNING: WARNING: rm -f commit libltdl/config/mailnotify WARNING: make -f Makefile.maint ./commit ./libltdl/config/mailnotify Please explain how this is addressed in the context of a VPATH build where only bootstrap is executed in the source tree. I expect that the commit script will work by default on your system since you are the one who wrote it. :-) % gmake -n -f Makefile.maint ./commit ./libltdl/config/mailnotify Makefile.maint:27: Makefile: No such file or directory *** Run maintainer rules from the build tree, with *** `make -f../Makefile.maint' for example, where *** `../' is the relative path back to the directory *** that contains the `Makefile.maint'. Alternatively, *** run `./configure' in the source tree for an in *** tree build. gmake: *** [Makefile] Error 1 However, then I follow these instructions I see the warning ../../../../home/bfriesen/src/gnu/libtool-head/Makefile.maint:29: warning: overriding commands for target `Makefile' Makefile:692: warning: ignoring old commands for target `Makefile' and nothing gets done. I know that the answer would be intuitively obvious if I drank some Guinness beer (works like spinach does for Popeye) but it is morning here, and in the US we don't start as early as you folks do. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Building CVS HEAD libtool outside of source directory
On Fri, 19 Oct 2007, Gary V. Vaughan wrote: Hi Bob, On 17 Oct 2007, at 23:21, Bob Friesenhahn wrote: I suspect that not many libtool developers use the VPATH build. Gary's commit script does not seem to support it. All of my builds are done with VPATH, and I use the commit script with them just fine! Yes, but is this a VPATH build on a completely different type of OS, or is it just a VPATH build on the same OS? The VPATH build on the same OS works for me just fine. A VPATH build on a completely different sort of OS (i.e. considerably more difference than between Brand A and Brand B of Linux) does not. This is why I am suspecting that 'bootstrap' is somehow introducing some configuration/dependency for/on the OS where bootstrap was executed. I recall that this also happened several years ago, but you fixed that ... The libtool code was checked out from CVS and then bootstrap was executed. There has been no configuring/building done from within the source tree. It is possible that there is some other problem since things were working much better before I installed the latest m4, autoconf, and automake, on the two problem hosts. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Building CVS HEAD libtool outside of source directory
Hi Bob, On 17 Oct 2007, at 23:21, Bob Friesenhahn wrote: I suspect that not many libtool developers use the VPATH build. Gary's commit script does not seem to support it. All of my builds are done with VPATH, and I use the commit script with them just fine! Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912 PGP.sig Description: This is a digitally signed message part
Re: optimize lt_combine
Hi Eric, On 17 Oct 2007, at 19:25, Eric Blake wrote: I liked the concept of lt_combine so much that I added m4_combine to m4sugar. In the process, Thanks :-) A while ago I considered shipping the useful stuff from m4sugar and ltsugar with m4 2.0... it might also give us some scope for speeding up some of the stickier implementations by moving them into a module in C. I made some optimizations and some slight semantic changes: - the separator is now used literally, rather than losing whitespace after comma - the infix argument is now used literally, rather than undergoing expansion (consider m4_define([_],[oops])...) - the quoting in m4_foreach is fixed (consider m4_define ([_Lt_suffix])...) - useless use of m4_car is avoided, and the m4_shiftn(3, $@) is now inlined and done once up front, rather than once per _Lt_prefix - the separator is no longer defaulted, so you can use an empty separator - the suffix list can now include an empty suffix, so the caller must be taught not to pass an empty suffix to preserve previous usage pattern + _lt_decl_varnames_tagged was the only caller for now, so I optimized it as well + right now, lt_decl_varnames_tagged is never called with more than one argument. It looks like it may have been intended to be called with multiple VARNAME arguments, rather than a single argument consisting of multiple VARNAMEs, but changing that is more invasive. So for now I just added an assert which will trigger if we ever change our minds, to remind us to fix the usage patterns appropriately. All good! OK to apply? I'm writing the testcase for the last release blocker today, and would rather hold off on this until we've rolled the release personally. But it is no more intrusive than the lt_join optimisations Ralf agreed to, so if someone else wants to overrule and let you apply, I won't be heartbroken :-) Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912 PGP.sig Description: This is a digitally signed message part
