bug-m4
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: m4-1.4.10 breaking autoconf?


From: Eric Blake
Subject: Re: m4-1.4.10 breaking autoconf?
Date: Sat, 21 Jul 2007 22:06:38 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5) Gecko/20070716 Thunderbird/2.0.0.5 Mnenhy/0.7.5.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Thomas Klausner on 7/21/2007 3:47 PM:
> On Sat, Jul 21, 2007 at 10:23:44AM -0600, Eric Blake wrote:
>> Thanks.  I need at least one more piece of information - could you send
>> the config.log created when you built m4-1.4.10 from the tarball?
> 
> Sure, attached.
> 
> Hope it helps,

Yes, it is helpful - for example, it shows that gnulib determined that
your system's fflush is not POSIX compliant, so the gnulib replacement is
in use - people reported problems with the gnulib fflush replacement in
the beta m4 1.4.9b, so maybe there is still an issue in it.

Next thing to try - please add this line to m4/configure.ac, just before
the AC_CONFIG_FILES:

m4_wrap([m4_syscmd([echo sleeping >/dev/tty;
 sleep 30; echo done >/dev/tty])])

then run:

TMPDIR=. autoconf

That should give you a 30 second window to do 'ls -l m4-??????' to see the
currently saved diversions and their size, after all output has been
generated to the diversions, but just before the time when m4 outputs all
diversions in numerical order.  For example, when I did it with the latest
m4 CVS head, I see:

$ ls -l m4-XOuqn7/
total 640
- -rw-r--r-- 1 eblake None 620225 Jul 21 21:54 m4-1000
- -rw-r--r-- 1 eblake None  18044 Jul 21 21:54 m4-20
- -rw-r--r-- 1 eblake None   9545 Jul 21 21:54 m4-300

Showing that there is indeed 620k of material in diversion 1000 that needs
to be flushed as part of exiting m4 during the autoconf run.

I'm hoping that you can see the temporary files, and that the file sizes
look reasonable (since I tested this on CVS head instead of 1.4.10, the
numbers will be slightly different).  At which point we will know that it
is something to do with how m4 reopens the temp files on your system
during the final dump of all pending diversions.  Or, if the files exist
but are size 0, that would prove that we are somehow truncating data the
first time m4 closes the temporary files during a change of the current
diversion.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----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

iD8DBQFGotef84KuGfSFAYARAlzxAJ40R0x4eANn1U3ltYKTHoCBQvlvxQCfUmNt
OB+0U28c/yxdCY2wrNPmGIs=
=sWo9
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]