Bug#837034: libdrm: FTBFS on kfreebsd-*: drm.h: bad #include choices
Andreas Boll <andreas.boll.dev@gmail.com> writes:
> Please ignore Hurd in this bug report since it hasn't successfully
> built in the past and won't be useful at all without adding the
> equivalent of the Linux Direct Rendering Manager (DRM) subsystem to
> the Hurd. I'm going to remove Hurd from the architecture list of
> libdrm in the next upload.
That's fair; I rather suspected deeper issues there. ;-)
> For the kFreeBSD FTBFS I've done a quick investigation and found out
> that those includes in drm.h haven't changed since 2009.
All the same, it's best practice for headers to #include anything they
need, to keep things simple for their reverse dependencies. FWIW, I
noticed this problem when looking into a libcmrt FTBFS on kFreeBSD:
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../src -D_DEBUG -DPTHREADS -I/usr/include/libdrm -I/src/cmrt -DSYSCONFDIR=\"/etc\" -Wdate-time -D_FORTIFY_SOURCE=2 -fpermissive -g -O2 -Wall -Wno-missing-braces -fvisibility=default -DLINUX -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -msse4 -fPIC -g -O2 -fdebug-prefix-map=/«BUILDDIR»/libcmrt-1.0.5+git20160516.dfsg1=. -fstack-protector-strong -Wformat -Werror=format-security -c ../../src/cm_buffer.cpp -fPIC -DPIC -o .libs/libcmrt_la-cm_buffer.o
In file included from /usr/include/libdrm/i915_drm.h:30:0,
from ../../src/cm_device.h:32,
from ../../src/cm_device.cpp:31:
/usr/include/libdrm/drm.h:50:9: error: 'uint8_t' does not name a type
Thanks for the quick response!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?amu@monk.mit.edu
Reply to: