bit by LONG_BIT (was Re: ActivePython 2.1 (build 210))

[Grant Griffin]

s713221 at student.gu.edu.au wrote:
> 
> > > Wow Windows and Quality Assurance in the same paragraph.... what's the
> > > world coming to?
> > >
> > > BTW isn't Windows Quality Assurance an oxymoron?
> >
> > I didn't say we quality assured windows. Just that we do quality
> > assurance ON windows. Quality assurance on unstable, inconsistent
> > platforms consists of figuring out what workarounds are necessary in
> > what circumunstances! We had some doozies getting out ActivePython on
> > e.g. Windows 95...and that was after all of the work the core team put
> > into Win95 compatibility themselves!
> 
> Kinda sounds like trying to build an arched cathedral on quicksand.

Yeah, I know what you mean.  I just got involved with a new OS, and I
think it's built on quicksand too.

I installed Redhat Linux 7.0 awhile back, and I've been trying to get it
to compile stuff.  I've tried about a half-dozen Gnu packages, some big
and some small.  I did the usual "configure/make/make install" dance. 
(Kindda like goin' to a hoe-down. Yee haw!)  In all cases except
"indent", the process halted somewhere along the way.  And for those of
you who've ever tried to work through problems like this, you know that
the Gnu configure/make process is the biggest, most complicated, most
opaque pond of quicksand you'll ever find: the nested include files
alone'll probably kill you--if you don't drown in preprocessor
directives first.

I also had a problem compiling Python 2.1.  (Since it's not a Gnu
package, I thought I might have a fighting chance of compiling it on the
"Gnu/Linux" system <wink>.)  But it seems that the Python source code
does a "#error" on something about "LONG_BIT".  Go figure.  So I hit
Dejanews (or whatever they're calling it these days <wink>) and found
out that this is caused by the fact that I need a new glibc; the one
that ships with Redhat 7.0 is defective.  (It seems that Redhat comes
with gcc 2.96 which doesn't actually exist; 2.95 is the latest one.)

So I downloaded an "errata" rpm for glibc and installed it.  Or at least
I tried.  The rpm installer then complained about "glibc-common = 2", or
something silly like that.  Well, obviously.

So then I downloaded a new glibc-common and tried to install that.  But
rpm puked.  (I was beginning to see a pattern here...)

Well, thank goodness for Dejanews (or whatever they're calling it these
days <wink>).  I researched the problem, and in a matter of minutes
found posts which said that you've got to install both glibc and
glibc-common using the _same_ rpm command.  Well, obviously.  In fact,
in one post, the guy said he was distressed that Redhat didn't bother to
tell you that.  I feel his pain.

Anyway, I tried installing both using the same rpm command--what do you
know?--the darn thing actually worked!  A whole bunch of "#'s" came out
of it.  I didn't know quite what that ment, but I hadn't seen that
before, so it seemed like a good sign.  Best of all, rpm told me it had
succeeded.  Great!

Next, I tried to compile Python 2.1.  But then I had _another_
unexpected problem.  It seems that the Python source code does a #error
on something about "LONG_BIT".

Quicksand.

OK, back to the drawing board.  I realized that I hadn't been a Good Boy
and applied the "Errata" CD that came with my Redhat package.  (As best
I can tell "Errata CD" is a euphemism for that all-purpose cathedral
mortar, the "Service Pack" <wink>.)  But the Errata CD only installed a
couple of things, and they aren't related to compilation, so (not
surprisingly) the Python and Gnu stuff still won't compile.

But I kept trying to give the broken Redhat Linux cathedral another
chance.  After all, isn't that the cathedral that's most beloved by The
Holier Than Thou?

So I kept trying.  One large package that I was able to compile
successfully on the "Gnu/Linux" system is wxWindows.  Everything I tried
in the wxWindows package compiled and ran flawlessly.  (Heck, that's
nearly as good as the experiences I have compiling software that comes
bundled with Microsoft Visual C++ project files <wink>.)  I'm not sure
if the fact that it's not a Gnu package helped here, but I can't see how
it could have hurt.

BTW, a couple of years ago, I had tried out the "Cygwin" system.  (For
those who don't know, Cygwin is a compatibility layer that provides a
Unix-like environment to allow Gnu-style software to be compiled.)  I
had many bad experiences with it, and I eventually decided that it just
basically didn't work (at least at that time).  In particular, I was
baffled by the fact that even simple ANSI C text-in/text-out programs
like "indent" wouldn't compile.  (Frankly, anybody who writes an ANSI C
text-in/text-out program that doesn't compile on Windows isn't trying. 
Or maybe they're secretly throwing stones at the other guy's cathedral
<wink>.)

But then somebody told me that it really isn't natural to make Unix run
on Windows.  That seemed to make sense, so the answer seemed to be to
use a *true* Unix-style OS like Linux.  So, more recently, I have gone
to a great deal of trouble to repartition my hard disk and install
Redhat Linux 7.0

Silly me.

the-bad-thing-about-Gnu's-quicksand-is-that-it's-recursive-ly y'rs,

=g2
-- 
_____________________________________________________________________

Grant R. Griffin                                       g2 at dspguru.com
Publisher of dspGuru                           http://www.dspguru.com
Iowegian International Corporation            http://www.iowegian.com