----- Original Message ----- From: "Eric Blake" <[EMAIL PROTECTED]> To: "Brian K. White" <[EMAIL PROTECTED]> Cc: <bug-gnulib@gnu.org>; <[EMAIL PROTECTED]> Sent: Tuesday, April 08, 2008 8:39 AM Subject: Re: fpurge.c, freadahead.c, freading.c make wrong assumption
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > According to Brian K. White on 4/7/2008 10:36 PM: > | well *shrug*. If I would reply using html myself it would be ok, but I > | refuse to send html, especially to a mail list. > > Good - because the lists intentionally filter html out of multipart MIME > messages anyway. > > |> Line 942 of m4 1.4.11's configure is not the ac_subst_files='' line, so > |> I'm not quite sure what you were seeing. But the fact that you had to > |> use > | > | ./configure is a dynamically generated file by autoconf and there is no > | specific line number where that line will appear, nor any garantee it > | even will always appear at all. > > Yes, ./configure is dynamically generated, if you rerun autoconf; but for > a given tarball, ./configure is pre-generated, and there should generally > be no need to rebuild it. So maybe I know the problem: > > | Except, As I said, after installing the new m4, I can't cause the error > | anywhere any more, regardless of shell. > > Did you perchance previously have m4 1.4.10 installed, and run autoconf > yourself rather than relying on the ./configure script that came shipped > with the package? 1.4.10 had a known bug that affected only platforms > where fopen(name,"a+") starts life at the end of the file instead of the > beginning, which manifested itself by generating corrupt configures when > used by autoconf. In which case, yes, installing m4 1.4.11 then rerunning > autoconf would correct those broken configure scripts. But you never > mentioned rerunning autoconf yourself (and in general, it should not be > necessary to rerun autoconf if the package already includes a working > configure script). > > But something in me is guessing that we still haven't pinpointed the > problem - if you were using 1.4.10 and rerunning autoconf, that still > doesn't explain why /bin/sh barfed but bash ran just fine. So it would > still be helpful to see the '/bin/sh -vx ./configure --help' output of a > failed run. Sorry I haven't responded to this in so long. Of course I tried ./configure as-shipped first. Tried diagnosing and getting around the problem at the shell level many tmes & many ways before trying to regenerate ./configure There was a patch posted to the list that I haven't yet tried just to verify it works as expected on that OS yet but I will. It looked pretty cut & dried though. I presume that by now if I just get the current cvs version I'll end up getting the same patch already applied? Sorry it's taking so long to get back around to clean this loose end up. > | *sigh* Now why'd you have to go and do that.... I know better than > | to waste time on that kind of remark but.... > > I did not mean for it to sound negative, merely cautionary. I guess my > tone came across harsher than intended. Yeah mine too. Sorry. :) Brian K. White [EMAIL PROTECTED] http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!
