While diagnosing a problem with xf86-video-intel I noticed we had two copies of drm headers in the sysroot; one from here and one from the libdrm package. The xf86-video-intel turned out to be another thing, but that doesn't mean we want two copies in the sysroot with different content and luck of include path indicating which one we get.
This one landed in usr/include/drm and the libdrm one put its files at usr/include/libdrm, so there was no obvious over-write conflict. The obvious risk here would be unearthing implicit dependencies on the libdrm; things trying to build before it has populated the sysroot but two full highly parallel builds containing a full desktop graphics suite did not show any issues. Cc: Bruce Ashfield <[email protected]> Cc: Richard Purdie <[email protected]> Signed-off-by: Paul Gortmaker <[email protected]> --- meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc index 566bc1e6154b..bda9d3f765ed 100644 --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc @@ -61,6 +61,10 @@ do_install() { # Kernel should not be exporting this header rm -f ${D}${exec_prefix}/include/scsi/scsi.h + # if we take drm from the kernel, and a different set from libdrm + # at different paths in the sysroot, then mayhem can result. + rm -rf ${D}${exec_prefix}/include/drm + # The ..install.cmd conflicts between various configure runs find ${D}${includedir} -name ..install.cmd | xargs rm -f } -- 1.8.2.3 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
