| Summary: | Build libkms against in-tree xf86drm.h | ||||||
|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Christopher James Halse Rogers <chalserogers> | ||||
| Component: | libdrm | Assignee: | Default DRI bug account <dri-devel> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | medium | CC: | fdziarmagowski, kibi, mattst88, sergio | ||||
| Version: | XOrg git | ||||||
| Hardware: | Other | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| i915 platform: | i915 features: | ||||||
| Attachments: |
|
||||||
|
Description
Christopher James Halse Rogers
2010-03-02 18:07:15 UTC
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.