Created attachment 33703 [details] [review] Add include dir to libkms Makefile libkms includes files which include xf86drm.h, but doesn't include the in-tree xf86drm.h in the library include path. This means it will build against the installed header in /usr/include which is probably not the expected behaviour, or if built in a clean chroot will simply fail to build. Trivial patch attached to fix.
The question is, if libkms depends on kernel ? and yes I thinks so . Therefore, if libkms , depends on kernel should use xf86drm.h of /usr/include. In this point of view, libkms should know deal with different kernels or even warn if kernel version is not good. "built in a clean chroot will simply fail to build" , I think that solves install kernel-sources first . Note: this is my opinion, may not be write.
(In reply to comment #1) > The question is, if libkms depends on kernel ? and yes I thinks so . > Therefore, if libkms , depends on kernel should use xf86drm.h of /usr/include. > In this point of view, libkms should know deal with different kernels or even > warn if kernel version is not good. It needs to deal with that at runtime, not build time.
So, until there's an actual kernel incompatibility introduced for which runtime detection in libkms is necessary, is there any reason not to apply this patch? Building against the headers shipped in the source alongside it makes much more sense to me.
the headers part was fixed in ae57dcf6e063860200b7949d5e2365e80ac4aea7, but libdrm is still missing from libkms_la_LIBADD.
What I'm try to say is, I think the ./configure of libdrm, should check what kernel version we have on system and require a version of kernel bigger than a number which libdrm, we are compiling, works. Is not logic, build libdrm-2.4.21 with a kernel <= 2.6.26 , I think. So libdrm should avoid those situations.
*** Bug 30782 has been marked as a duplicate of this bug. ***
Ping? As described in the initial report, there's no reason to prefer system headers over those in the same source… I don't understand Sérgio's objection (I fail to see what's illogical).
(In reply to comment #7) > Ping? As described in the initial report, there's no reason to prefer system > headers over those in the same source… I don't understand Sérgio's objection (I > fail to see what's illogical). The illogical is, without that depending on kernel, you may try compile very new libdrm with a older kernel. libdrm-2.4.21 needs kms on kernel but kernel <= 2.6.26 don't have it. my 2 cents
(In reply to comment #8) > (In reply to comment #7) > > Ping? As described in the initial report, there's no reason to prefer system > > headers over those in the same source… I don't understand Sérgio's objection (I > > fail to see what's illogical). > > The illogical is, without that depending on kernel, you may try compile very > new libdrm with a older kernel. > libdrm-2.4.21 needs kms on kernel but kernel <= 2.6.26 don't have it. > > my 2 cents I think you're failing to understand the issue. xf86drm.h is provided by libdrm. libkms (which is part of libdrm) uses xf86drm.h, but the Makefile searches in /usr/include instead of the $(top_src) directory, where libdrm's xf86drm.h is. This is like if you have a library that consists of lib.c and lib.h, where lib.c includes lib.h. The Makefile would be incorrect in using lib.h found in /usr/include over the lib.h in the same folder as lib.c.
This was fixed in ae57dcf6 anyway :)
> --- Comment #10 from Christopher James Halse Rogers <chalserogers@gmail.com> 2011-03-06 20:57:41 PST --- > This was fixed in ae57dcf6 anyway :) > only partly, see comment#4.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.