[Top][All Lists]

[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: Tue, 8 Apr 2008 00:36:24 -0400

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

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!

reply via email to

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