On Thu, Apr 03, 2003 at 01:36:01PM +1000, Tim Robbins wrote:
> On Wed, Apr 02, 2003 at 01:36:41PM -0500, Greg Troxel wrote:
> > Does -current coda really not build on 4-stable?  I haven't rebuilt in
> > a while on my FreeBSD box, which is tracking 4-stable.
> 
> 5.3.20 doesn't build:
> gcc -fno-exceptions -MD -DHAVE_CONFIG_H -D__BSD44__ -I. -I/home/tim/coda/coda-5.3.20/include -I/home/tim/coda/coda-5.3.20 -I/usr/local/include  -g -O2 -I/usr/local/include -c pioctl.c
> In file included from pioctl.h:37,
>                  from pioctl.c:33:
> /home/tim/coda/coda-5.3.20/include/coda.h:130: redefinition of `int8_t'
> /usr/include/sys/inttypes.h:11: `int8_t' previously declared here

That is caused by some confusion between userspace and kernel space.
Although it is not unexpected. As far as I know, the current
kernel-venus interface (coda.h) was created around '96 or '97. At that
time there was no ISO C or POSIX standard for fixed width integer types.
So coda.h uses what was 'the existing convention' based on both the
linux kernel and glibc, they define __BIT_TYPES_DEFINED__ whenever fixed
width integers are available.

However, ISO C '99 seems to have introduced <stdint.h> which defines
__int8_t_defined whenever fixed width integers are present. Now glibc
(userspace) has a right stdint.h, but the Linux kernel headers do not
have stdint, nor define __int8_t_defined.

But the right fix which doesn't involved checks for specific OS
releases would be something like,

- #ifndef __BIT_TYPES_DEFINED__
+ #if !defined(__int8_t_defined) && !defined(__BIT_TYPES_DEFINED__)
  typedef signed char 	int8_t;
  typedef unsigned char uint8_t;
  ...

Jan