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

[Brian K. White]

----- Original Message ----- 
From: "Eric Blake" <address@hidden>
To: "Brian K. White" <address@hidden>
Cc: <address@hidden>; <address@hidden>
Sent: Monday, April 07, 2008 11:01 PM
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 1:16 AM:
>
> Hello Brian, and adding bug-autoconf,
>
> | Roger Cornelius wrote:
> |> to answer question 1, there are no #defines to relate the __ struct
>
> Your quoting style left a bit to be desired - it took me a while to
> realize you were quoting Bruno...

Thats what happens when outlook express receives an html email if you have 
it configured not to ever send html. It doesn't properly convert the html to 
> 's
If i's a few lines I'll manually put them in, but more than that , oh well 
*shrug*. If I would reply using html myself it would be ok, but I refuse to 
send html, especially to a mail list.
Since you didn't send in html, and neither am I, you'll notice it handled 
the quoting correctly this time.

> |
> | I am hitting the same thing.
>
> up through this point.
>
> |
> | I was only able to build gnu m4 1.4.11 by doing this:
> |
> | CONFIG_SHELL=/usr/bin/bash /usr/bin/bash ./configure --disable-largefile
> CONFIG_SHELL=/usr/bin/bash CFLAGS="-D_ptr=__ptr -D_base=__base
> - -D_cnt=__cnt -D_flag=__flag"
>
> The -D_flag=__flag and friends are useful to bug-gnulib; hopefully Bruno
> can make more sense of how to fix our stdio replacement functions to
> correctly look inside the struct for your system.
>
> |
> | The bash weirdness came out of /usr/local/src/m4-1.4.11/INSTALL, and was
> the only way to get ./configure to run at all. Otherwise even just
> "./configure --help" failed with configure: 942: : is not an identifier"
> Line number is just an example. Several (but not most) apps ./configure
> had the same problem, but it no longer fails on any app after installing
> the new m4. But in each case, though the line number differed the line was
> always this one: ac_subst_files='' which looks harmless but always comes
> right after a very large list being set in another variable.
>
> 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.
In this casse, before I had run autoconf to see if that fixed the problem, 
It was definitely 3 digits starting with 9, 9##, but who cares? What else 
could I have possibly been referring to by "line number is just an example" 
? I do know what the content of the line was though because as I said, I'd 
just seen the same exact problem on a few different apps. So I'd seen the 
line enough times to know it. I'd also tried to debug the problem by cutting 
sections out of the configure script and trying to source the snippets into 
the various shells directly, to see if there is some syntax that fails or 
maybe one of the variable assignments was too large or something. So I'd 
been looking at the same lines in several different ./configure's , each of 
which was somewhat different from the other yet had things in common as 
well. And the problem surely isn't that line but something before that 
point. Except, As I said, after installing the new m4, I can't cause the 
error anywhere any more, regardless of shell. So, It probably was never a 
shell problem, even though ./configure is a shell script, and it may not 
technically be a problem that needs fixing so much as a supporting tool 
version requirement. I wouldn't like any program to be that delicate myself 
but as long as there is a known way (two actually, since the special bash 
work-around also worked) to make it work then that's at least good enough in 
so far as it's functional vs non-functional.

> CONFIG_SHELL means that your system's /bin/sh is rather limited, and it
> took an explicit bash override to work around it.  What version/flavor is
> your system's /bin/sh?  Could you post the output of '/bin/sh -vx
> ./configure --help' to bug-autoconf so we can identify why we weren't
> automatically recognizing your /bin/sh as inadequate to begin with?
>
> But the statement that ./configure scripts no longer fail when invoked by
> /bin/sh after installing the new m4 is confusing - how does the
> installation of m4 impact the operation of your shell?
>
> |
> | Also, for reference, My gcc defines are somewhat different on a nominaly
> similar system. Open Server 5.0.7 with the most recent (old as it is)
> vendor-built gcc, 2.95 from gnutools5.0.7Kj.
>
> At this point, your platform is a museum piece.  While it is admirable
> that you are trying to get it working, and even succeeding to some degree,
> you will find that much of your work will be unsupported, as we tend to
> prefer more up-to-date systems.  The maintenance-to-usage ratio is pretty
> small to justify some of the hacks necessary to work on various old
> machines.  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 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.

There are newer products from the same vendor, even called open server, but 
open server 6 is a completely different product and there are reasons to use 
open server 5 _specifically_ and it really doesn't matter how old it gets. 
Even when one is no longer buying or installing a single new osr5 
installation, there will still be reasons to build new software on it for 10 
more years easy.

This isn't game consoles or fashions from Paris or popular music. Remarking 
that the os is old is about like saying I should use metric wrenches because 
they're newer & better. I should use whatever wrenches fit the bolts in 
front of me. These machines already exist and each one represents a 
significant investment in time and effort by several parties to get them 
purchased, installed, designed to some extent, and woven into buisiness 
operations. When a bolt needs tightening or something needs adjusting, the 
correct procedure is not to replace the machine because the new ones have 
cool metallic blue paint jobs. If I was a whore and didn't care what I did 
all day or how I made money, maybe then that would be the response. Hey, 
whatever causes the most billable hours right? The customers don't know any 
better, they'll do whatever we say so why not go to town eh?

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.

And I'm also sure that people who develop software ostensibly for a wide 
range of platforms would prefer to be able to claim that their product "just 
works" in as many cases as reasonably possible. (I know I do.) Perhaps the 
current owners of SCO are dirt bags, but that doesn't change the fact that 
there are an awful lot of these boxes out there running and being serviced 
by guys like me who enjoy both the new and old worlds for what each offers. 
And we will be trying and/or wishing to put new software on them for years 
to come. And it's in no ones interest for any "unix" software to get a 
reputation for being narrowly written such that it can't build on one of the 
most common unix of all time.
Luckily thats usually not the case and just for the record this isn't the 
case here either. It built with a tweak so minor that it didn't involve 
editing a single file, merely the right incantation of ./configure.
Thats actually quite good.

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

--
Brian K. White    address@hidden    http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!