Bug#837034: libdrm: FTBFS on kfreebsd-*: drm.h: bad #include choices
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-...@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 with > > (which is more broadly available, and pulls in > > on both kFreeBSD/GNU and pure *BSD), and supplementing > > with . ( 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 > 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 > > > It replaces the include of 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-de...@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 signature.asc Description: Digital signature
Bug#837034: libdrm: FTBFS on kfreebsd-*: drm.h: bad #include choices
Andreas Boll 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/?a...@monk.mit.edu
Processed (with 2 errors): Re: Bug#837034: libdrm: FTBFS on kfreebsd-*: drm.h: bad #include choices
Processing control commands: > retitle -1 libdrm: FTBFS on kfreebsd-*: drm.h: bad #include choices Bug #837034 [src:libdrm] libdrm: FTBFS on non-Linux: drm.h: bad #include choices Changed Bug title to 'libdrm: FTBFS on kfreebsd-*: drm.h: bad #include choices' from 'libdrm: FTBFS on non-Linux: drm.h: bad #include choices'. > tags -1 help upstream Bug #837034 [src:libdrm] libdrm: FTBFS on kfreebsd-*: drm.h: bad #include choices Added tag(s) upstream and help. > user debian-...@lists.debian.org Unknown command or malformed arguments to command. > usertags -1 kfreebsd Unknown command or malformed arguments to command. -- 837034: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837034 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#837034: libdrm: FTBFS on kfreebsd-*: drm.h: bad #include choices
Control: retitle -1 libdrm: FTBFS on kfreebsd-*: drm.h: bad #include choices Control: tags -1 help upstream Control: user debian-...@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 with > (which is more broadly available, and pulls in > on both kFreeBSD/GNU and pure *BSD), and supplementing > with . ( 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 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 It replaces the include of 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-de...@lists.freedesktop.org [3] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/drm signature.asc Description: Digital signature
