Summary: | x11-libs/libdrm-2.4.15 - intel_atomic.h:58:2: error: #error libdrm-intel requires atomic operations, please define them for your CPU/compiler. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jeroen Roovers (RETIRED) <jer> |
Component: | [OLD] Library | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | diego.abelenda, hppa |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 295210 | ||
Bug Blocks: | 294958 | ||
Attachments: | x11-libs:libdrm-2.4.15:20091211-024148.log.gz [hppa,fail] |
Description
Jeroen Roovers (RETIRED)
2009-12-11 02:56:44 UTC
Created attachment 212669 [details]
x11-libs:libdrm-2.4.15:20091211-024148.log.gz [hppa,fail]
TBH, I'd rather HPPA built everything like all the other arches, just for the sake of simplicity. The real issue here is that HPPA doesn't have any atomic ops available (or maybe they use a different syntax?) and configure.ac does indeed find that : checking for native atomic primitives... none Yet it still goes on to try and build libdrm_intel... I'll try to fix this myself, but feel free to take a swing yourself if you want to :) Cheers *** Bug 295210 has been marked as a duplicate of this bug. *** Heh, funny, the very next 3 patches committed after 2.4.15 fix this bug :) The third one also adds support for libatomic_ops (or something...) which means libdrm_intel might even build on HPPA and ARM. :) So I've backported it without a revbump as the default on intel arches is to still use gcc's atomic ops. Please do let me know if these patches don't work out for you. Thanks Well, there is a patch that let it compile on an arch that will never have an intel... ok, but my patch was to let me choose if I wanted to compile libdrm-intel, libdrm-radeon or libdrm-nouveau separately, it is not really linked to the fact it compiles or not. My patch is about choice, wich as far as I know is gentoo's way of doing things. I won't need the libdrm for intel video cards so I don't need to compile it. The compile error was a bug on the sources my patch is an ebuild problem. (In reply to comment #5) > Well, there is a patch that let it compile on an arch that will never have an > intel... ok, but my patch was to let me choose if I wanted to compile > libdrm-intel, libdrm-radeon or libdrm-nouveau separately, it is not really > linked to the fact it compiles or not. We've collectively decided to always build the various libs as they are really small and it makes our ebuilds simpler (both for users and developers). > My patch is about choice, wich as far as I know is gentoo's way of doing > things. I won't need the libdrm for intel video cards so I don't need to > compile it. Giving the user this choice (as of today) just doesn't make sense. If libdrm sees more and more driver-specific libs, we'll reconsider of course. As for your assertion, Gentoo isn't about choice, it's about power. If you _really_ don't want to build the other libs, then feel free to locally patch our ebuild, that's what overlays are for. Thanks (In reply to comment #2) > TBH, I'd rather HPPA built everything like all the other arches, just for the > sake of simplicity. Why? It's not like the code is ever going to be used, so why push it onto users at all? HPPA systems will probably always use mesa's software rendering. If you want to stop users from tinkering with this through USE flags, then we can simply arrange a `~hppa? ( x11-libs/libdrm )' in media-libs/mesa's ebuilds, can't we?. (In reply to comment #7) > `~hppa? ( x11-libs/libdrm )' in media-libs/mesa's ebuilds, `!hppa? ( x11-libs/libdrm )' that is. (In reply to comment #7) > Why? It's not like the code is ever going to be used, so why push it onto users > at all? HPPA systems will probably always use mesa's software rendering. I know that some arches just aren't going to use libdrm and drm in general. But libdrm builds in just a minute on my 4-y-o old laptop. If it were bigger, then I'd reconsider. Up until this whole atomic stuff broke libdrm 2.4.15, no one's really complained about libdrm... > If you want to stop users from tinkering with this through USE flags, then we > can simply arrange a `~hppa? ( x11-libs/libdrm )' in media-libs/mesa's ebuilds, > can't we?. NAK, we used to have special cases like that for hppa and alpha but it made our ebuilds more complex. It also caused quite a few bugs when dri became mandatory with xorg-server 1.5. In the end, it's just easier to have the same deps on all arches, even if one or two really are useless on some arches. The maintenance cost is much lower for us. Thanks |