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

[Eric Blake]

-----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.

|> That's not to say that we plan on ignoring you, just that you
|> should not hold your expectations too high.
|
| *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.  Yes, we would love to support as
many platforms as possible - particularly if the patches to support such
platforms (even if they are old) are easy to maintain.

| I am no stranger to this OS or "new" OS's nor to building gnu-ish
| software on it.
| Whether or not to use the OS, or in what context, or why, is really not
| part of the discussion.
| I'm merely reporting. I wasn't even asking for help. I built my app. I
| was instead reporting what it took. But just for the record, the museum
| piece version of the OS I'm citing is still sold today, still receiving
| active maintenance and updates by the vendor today, and is the latest of
| the Open Server kernel line, which has certain significance.

That is also a deciding factor.  For example, Solaris 4 is no longer
supported by Sun, and thus no longer supported by gnulib.  But since your
platform is still actively sold, then we will take very seriously any
patch to make porting GNU software to your platform an easier task.  I
guess I stand corrected - your platform may ship with an old compiler, but
since it is still actively shipped and supported, it is not a museum platform.

|
| Besides all that, some people just like to work on the old stuff and
| improve it and get the most out of it just for the heck of it. Just to
| see what can be accomplished. It always ends up being real-world useful
| and valuable, but sometimes that's actually just gravy.

That's true too.  Again, my comment wasn't meant to imply that you should
quit using your platform, just a heads up that since your platform is not
as popular, it will tend to be more of an uphill battle to port software
to your platform, compared to the experience of ports to other platforms.

| Now can we resume being interested in the workings of the software
| instead of how cool or uncool the OS is?

Yes.  The fact that you have reported what made things work on your
platform is useful in and of itself.  And I certainly have no intention of
rejecting useful patches just because of the platform that they were for;
rather, the only argument against a patch would be how hard it is to
maintain compared to the value that it adds.  Please continue reporting
issues and/or solutions for your platform, and again, accept my apologies
if my comment came across too harshly.

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

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkf7Z54ACgkQ84KuGfSFAYAc2QCgjtBKujQoUplAsnEJLCi4Efn+
ru8AniX9KQIv3cnUfPsIUSRrQQOW9xuo
=vBs4
-----END PGP SIGNATURE-----