[moving to bug-m4; replies can drop bug-autoconf] According to Gene Spafford on 2/25/2010 11:10 PM: > Thanks for the reply, Ralf. > > I am enclosing the output of the "make check" on the m4 build so you can see > the failures.
M4 failures should be reported to the m4 list; so I've redirected accordingly. All of the failures in your log look like: Checking ./006.command_li @ ../doc/m4.texinfo:979: Origin of test ./006.command_li: stderr mismatch --- m4-tmp.13684/m4-xerr Fri Feb 26 01:01:42 2010 +++ m4-tmp.13684/m4-err Fri Feb 26 01:01:42 2010 @@ -1,2 +1,4 @@ +Must be attached to terminal for 'am I' option +Must be attached to terminal for 'am I' option hi bye Each of those tests invoke a subsidiary instance of m4 via the equivalent to a system() call (that is, an instance of /bin/sh is spawned to find the subsidiary m4). My guess is that you have a weird environment setup, such that /bin/sh attempts to call who(1) during startup and ends up being quite noisy. In other words, the bug is not in m4, but in your /etc/profile, ~/.bashrc, or some other sort of script startup file. It is bad practice to have noisy startup environment files. I know of no way to make m4 robust against such a bad environment, where the mere act of starting /bin/sh outputs junk to stderr before the intended command passed to system() is even started. -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net
signature.asc
Description: OpenPGP digital signature
