In-Reply-To: <rt-2941-13589.18.707549795317@krbdev.mit.edu>
References: <rt-2941-13589.18.707549795317@krbdev.mit.edu>
MIME-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <a17825a893efad5a65e78fd50935f396@mit.edu>
Content-Transfer-Encoding: 7bit
From: Ken Raeburn <raeburn@MIT.EDU>
Subject: Re: [krbdev.mit.edu #2941] krb5-1.4 is unbuildable on HPUX 10.20
Date: Thu, 24 Feb 2005 13:32:25 -0500
To: rt@krbdev.mit.edu
RT-Send-Cc: 
Content-Length: 1618

 From looking at the headers you've made available, it looks like 
sys/_inttypes.h is always included, but it only defines the 64-bit 
types in some circumstances, namely when it doesn't define 
__STDC_32_MODE__; it defines that if __LP64__ is not defined (i.e., not 
a 64-bit build), and __cplusplus is not defined (i.e., plain C), and 
either __STDC__ is not defined (non-ANSI C build, which we're not going 
to do) or __STDC_EXT__ is defined.

So I guess the question is how to get __STDC_EXT__ defined.  In modern 
systems there's often a header that tests some compiler-defined flags 
for indicating desired standards compliance, and sets a bunch of other 
macros controlling which declarations get exposed by other headers.  
Looks like sys/stdsyms.h is the one for hpux 10.  I don't see it doing 
anything with __STDC_EXT__ except testing it, though, so this one may 
be a compiler-defined symbol.

Ah... first hit in google is a discussion on the gcc-bugs list about 
using __STDC_EXT__ with gcc 2.95.1, the reply claiming that the change 
to gcc had been made (for some future release, maybe 3.0?) to define 
__STDC_EXT__ unless the "-ansi" option is given.  Lenny, what version 
of gcc are you using?  If it's 2.95, try

   configure CPPFLAGS=-D__STDC_EXT__ --enable-static --disable-shared ...

(You might not need to disable the thread support; threads.c always 
gets compiled first, but just shouldn't do anything interesting after 
including some header files if the thread support is turned off, and it 
was the info on shared-library support in those headers that caused the 
failure the first time.)