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