On Thu, Sep 08, 2016 at 03:20:17PM +0200, Andreas Boll wrote: > Control: retitle -1 libdrm: FTBFS on kfreebsd-*: drm.h: bad #include choices > Control: tags -1 help upstream > Control: user debian-bsd@lists.debian.org > Control: usertags -1 kfreebsd > > On Wed, Sep 07, 2016 at 09:08:30PM -0400, Aaron M. Ucko wrote: > > Source: libdrm > > Version: 2.4.70-1 > > Severity: important > > Justification: fails to build from source (but built successfully in the past) > > > > Builds of libdrm on kFreeBSD and the Hurd have been failing because > > the headers drm.h pulls in on those platforms don't work out. > > Specifically, kFreeBSD builds have been failing with > > > > In file included from ../../../include/drm/drm_fourcc.h:27:0, > > from ../../../tests/kms/libkms-test-framebuffer.c:33: > > ../../../include/drm/drm.h:50:9: error: unknown type name 'uint8_t' > > typedef uint8_t __u8; > > ^ > > ../../../include/drm/drm.h:52:9: error: unknown type name 'uint16_t' > > typedef uint16_t __u16; > > ^ > > ../../../include/drm/drm.h:54:9: error: unknown type name 'uint32_t' > > typedef uint32_t __u32; > > ^ > > ../../../include/drm/drm.h:56:9: error: unknown type name 'uint64_t' > > typedef uint64_t __u64; > > ^ > > > > and Hurd builds have been failing with > > > > In file included from ../xf86drm.h:40:0, > > from ../xf86drm.c:70: > > ../include/drm/drm.h:47:24: fatal error: sys/ioccom.h: No such file or directory > > > > To remedy these errors, I would recommend replacing <sys/ioccom.h> with > > <sys/ioctl.h> (which is more broadly available, and pulls in > > <sys/ioccom.h> on both kFreeBSD/GNU and pure *BSD), and supplementing > > <sys/types.h> with <stdint.h>. (<sys/types.h> should stay for size_t.) > > > > Could you please take a look? > > > > Thanks! > > 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. > > For the kFreeBSD FTBFS I've done a quick investigation and found out > that those includes in drm.h haven't changed since 2009. > It seems more likely that the following change has introduced this > regression: > > commit 268ae7cae5afd76462c3ef14ed9021a2d40c2e57 > Author: Daniel Vetter <daniel.vetter@ffwll.ch> > Date: Wed Mar 30 15:39:12 2016 +0200 > > headers: Update drm_fourcc.h > > Only real difference is switching to kernel types for fixed-width > integers, like we should. > > Generated fromd drm-misc commit 249c4f538b1aae55d41699f8bafc6cb762a7f48f > > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> > > > It replaces the include of <inttypes.h> with "drm.h". See also [1]. > > So for the kFreeBSD FTBFS a patch needs to be written, tested and > forwarded to upstream [2]. Also note that the headers drm.h and > drm_fourcc.h are actually imported from the Linux kernel and thus > needs to be fixed there [3]. > > Thanks, > Andreas > > [1] https://cgit.freedesktop.org/mesa/drm/commit/?id=268ae7cae5afd76462c3ef14ed9021a2d40c2e57 > [2] dri-devel@lists.freedesktop.org > [3] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/drm Mesa 13 depends on libdrm >= 2.4.69 and is currently available in experimental. It will be uploaded to unstable soon. So this bug needs to be resolved to build newer versions of Mesa on kFreeBSD. Any volunteers? Thanks, Andreas
Attachment:
signature.asc
Description: Digital signature