Bug#677260: xserver-xorg-video-openchrome: FTBFS[kfreebsd]: error: unknown type name 'uint8_t'

[Steven Chamberlain <steven@pyro.eu.org>]

2012/6/15 Julien Cristau <jcristau@debian.org>:
> drm.h is a kernel header.  It includes other kernel headers;
> <linux/types.h> on linux, <sys/types.h> on bsd.

libdrm's via_drm.h #includes "via_drmclient.h", which has to be provided
by the openchrome driver;  doesn't that imply this is for userland?  In
that file is a #include "stdint.h" which would get the uintXX_t
definitions, except the #include "drm.h" happens too soon.

That #include "drm.h" is a recent(ish) change that upstream FreeBSD
doesn't have.  That also didn't exist in the (working?) via_drm.h
bundled with xserver-xorg-video-openchrome 0.2.904+svn1050-1

Also, upstream's *_drm.h headers[1] don't include sys/types.h or
stdint.h either, yet some of them make use of the uintXX_t types, making
those definitions seem like a prerequisite.  I think that was hinted at
during the response to [2].

So my current thinking is that the openchrome driver is forgetting to
include stdint.h, but this has gone unnoticed because FreeBSD's
sys/types.h would have included it as a side-effect.

xserver-xorg-video-intel includes stdint.h (from intel.h) before any of
the libdrm headers.  The mga driver does likewise, indirectly getting
stdint.h from inttypes.h.

I still think my most recent patch for this[3] is right.

[1] http://svnweb.freebsd.org/base/head/sys/dev/drm/
[2]
http://us.generation-nt.com/answer/patch-linux-headers-include-linux-types-h-where-appropriate-help-206535612.html
[3]
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=35;filename=20-BSD-stdint-prerequisite.diff;att=1;bug=677260

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org