bug-gnulib
[Top][All Lists]
Advanced

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

Re: fpurge.c, freadahead.c, freading.c make wrong assumption


From: Brian K. White
Subject: Re: fpurge.c, freadahead.c, freading.c make wrong assumption
Date: Mon, 28 Apr 2008 12:53:01 -0400

----- Original Message ----- 
From: "Eric Blake" <address@hidden>
To: "Brian K. White" <address@hidden>
Cc: <address@hidden>; <address@hidden>
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    address@hidden    http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!





reply via email to

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