Re: Bug#677260: xserver-xorg-video-openchrome: FTBFS[kfreebsd]: error: unknown type name 'uint8_t'
2012/6/15 Julien Cristau <firstname.lastname@example.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 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 .
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 is right.