Bruno Haible wrote:
Eric Blake wrote:
According to Matthew Woehlke on 3/1/2007 9:44 AM:
...it also seems to break tempname.c:
source='tempname.c' object='tempname.o' libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../depcomp \
cc -I. -O -c tempname.c
int64_t st_reserved[3];
^
"///usr/include/sys/stat.h", line 70: error(114): identifier "int64_t"
is undefined
That makes it sound like we might be able to get away with a fix stdint_.h
to include sys/stat.h prior to redefining all the 64-bit type names, along
with any other system header that uses int64_t on your platform.
If you *really* wanted to do that, those would be sys/stat.h and
sys/socket.h. So far I like Bruno's idea better.
Then there is netinet/in6.h which references both uint64_t and
u_int64_t, neither of which appear outside that header. I guess it's
safe to say that isn't used. :-)
Another option would be to leave int64_t defined as it is, but set HAVE_INT64_T
to 0, to indicate that gnulib shouldn't use it.
Hmm... this looks like it would fix sys/stat.h (see below). I'm still
not sure I trust it. Will clock_t and fpos_t be defined correctly so as
to not break system API's using these? Will gnulib behave correctly
w.r.t. these?
But first, Matthew Woehlke should show enough info for analysis of possible
workarounds:
- the relevant parts of sys/stat.h including all surrounding #ifs,
struct stat {
...
int64_t st_reserved[3];
}; /* struct stat */
...no #if's. In this case,
- what is the original definition of int64_t on this OS if gnulib is not
involved? (a macro, a typedef?)
sys/types.h has:
/*
* In the OSS File System some of the definitions are 64-bit wide.
* In Guardian C there is support of 64-bit wide variables declared
* using long long. To allow the same width on the workstation we will
* use double. The definition can be sourced in using the ifdef switch.
*/
#ifdef __TANDEM
#define int64_t long long
#else
typedef double int64_t;
#endif
(__TANDEM is normally defined; the alternative is clearly a hack of sorts.)
Oh, and clock_t, dev_t and fpos_t are also 'long long', and 'long long'
shows up in several places in socket code (not sure if that's an issue
or not, since so far we aren't talking about any networking apps).
--
Matthew
"Have you tried that new mixed drink, 'GDR'"?
"What is it?"
"Gin, Duck and Rum. It tastes fowl."
_______________________________________________
M4-discuss mailing list
M4-discuss@gnu.org
http://lists.gnu.org/mailman/listinfo/m4-discuss
