develooper Front page | perl.perl5.porters | Postings from September 2000

Re: [ID 20000901.090] not OK DEVEL 7002 on Tru64 5.0

Thread Previous
From:
Spider Boardman
Date:
September 7, 2000 14:59
Subject:
Re: [ID 20000901.090] not OK DEVEL 7002 on Tru64 5.0
Message ID:
200009072159.RAA17175@leggy.zk3.dec.com
On Thu, 7 Sep 2000 14:26:46 -0700 (PDT), Peter Prymmer wrote (in part):

pvhp> On Thu, 7 Sep 2000, Spider Boardman wrote:

>> The typedefs are (indirectly) present in the V5.0 and V5.0A
>> kits.  It looks like someone replaced <sys/bitypes.h> or
>> something similar.  I would have sent in V5.0 reports, but
>> that's my slowest machine.

pvhp> Is there a way to #define around the problem, or perhaps a
pvhp> system ECO?

pvhp> I am also quite curious about why Configure's i_* tests
pvhp> didn't pick up "the" correct value, although it could be
pvhp> indirectly #included via some devious route that only
pvhp> config.h exposes.

I've not checked what Configure gets, but I suspect that the
additional -I/usr/local/include got a non-OS version of
<sys/bitypes.h> which didn't get the right typedefs.  Depending
on when Configure does its tests for the i_* values versus which
-I flags it uses at that point in its processing, it's entirely
possible that Configure found valid data there.  Also, at least
historically (with metaconfig), some of the processing for the
i_* checks only validates the existence of the header file and/or
whether a grep of it shows an interesting value.  A test compile
is not always done.  A quick look at the current Configure shows
that if it can find a .h file in a 'standard' place, it doesn't
do the test compilation.

It's still a local system configuration problem, although with
<sys/bitypes.h> I suspect your situation won't be unique for
long (assuming it even is now).

	--s.

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About