#2972 closed task (fixed)
libdrm-2.4.15
Reported by: | Trent Shea | Owned by: | DJ Lucas |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | BOOK | Version: | SVN |
Severity: | normal | Keywords: | |
Cc: |
Description
Just a heads up. It looks like libdrm may have a future recommended/suggested dependency: atomic_ops.
The package can be coerced into building with the following: (taken from configure --help) --disable-intel Enable support for intel's KMS API (default:
enabled)
Useful atomic_ops links:
Where to get the package: http://www.hpl.hp.com/research/linux/atomic_ops/
Latest packaged version 1.2 (20061010): http://www.hpl.hp.com/research/linux/atomic_ops/download/
Sourceforge: http://bdwgc.sourceforge.net/ http://sourceforge.net/projects/bdwgc/develop
Change History (11)
follow-up: 2 comment:1 by , 15 years ago
follow-up: 3 comment:2 by , 14 years ago
Replying to conathan:
I compiled that on my linux system, and when compiling for 32bit, it failed due to
In file included from intel_bufmgr_gem.c:56: intel_atomic.h:58:2: error: #error libdrm-intel requires atomic operations, please define them for your CPU/compiler.
That's the same error message - thanks for including it.
I found http://bugs.freedesktop.org/show_bug.cgi?id=24381 that suggested -march=i686, and it compiled.
Thanks, I just purged libatomic-ops and tried: CFLAGS=march=native ./configure && make and drm built for me, too. Actually, a git pull from today didn't require libatomic-ops or march=*.
Note: I am currently using a multilib system. This may affect the my results
I did not use the atomic_ops package, nor did I see any warning/information that I may want it when compiling libdrm.
There's notes about atomic_ops in the git master branch, along with a few other suggestions:
Quote from the drm configure file: AC_MSG_ERROR([libdrm_intel depends upon atomic operations, which were not found for your compiler/cpu. Try compiling with -march=native, or install the libatomics-op-dev package, or, failing both of those, disable support for Intel GPUs by passing --disable-intel to ./configure])
Another note with drm - this time pulled from git 20091023, I also observed this behaviour with 2.1.15, though. I just built Xorg-7.5 with MesaLib-7.6 and MesaGLUT-7.6 and had to comment out the DRI line in /etc/udev/rules.d/55-lfs.rules or I wouldn't get /dev/dri/card0. Can anyone confirm this?
follow-up: 4 comment:3 by , 14 years ago
Thanks, I just purged libatomic-ops and tried: CFLAGS=march=native ./configure && make and drm built for me, too. Actually, a git pull from today didn't require libatomic-ops or march=*.
Well, it looks configure just disables the intel specific things, and Mesa-7.6 goes on to fail. It looks like either libatomic-ops or the CFLAGS are required for intel graphics.
comment:4 by , 14 years ago
Replying to trent.shea:
Thanks, I just purged libatomic-ops and tried: CFLAGS=march=native ./configure && make and drm built for me, too. Actually, a git pull from today didn't require libatomic-ops or march=*.
Well, it looks configure just disables the intel specific things, and Mesa-7.6 goes on to fail. It looks like either libatomic-ops or the CFLAGS are required for intel graphics.
Err on the git pull...
comment:5 by , 14 years ago
Summary: | libdrm-2.1.15 → libdrm-2.4.15 |
---|
2.4.14 works correctly AFAICT. Gonna leave this set for a bit until 2.4.16.
comment:6 by , 14 years ago
Milestone: | 6.5 → future |
---|---|
Owner: | changed from | to
comment:7 by , 14 years ago
FYI, libdrm-2.4.14 has a missing required dependency, libpthread-stubs-0.1.
comment:9 by , 13 years ago
Further information re libatomic_ops : on my (amd) x86_64 I don't have libatomic_ops. The configury doesn't get as far as looking for it because I already pass the 'Intel' test:
checking for native atomic primitives... Intel
I don't understand the details, but it seems that sync_fetch_and_add and sync_val_compare_and_swap are supported by code elsewhere, perhaps in glibc (they both have a double underscore at the front of their names, which seems to be treated as a formatting code in trac)
Interestingly, my ppc64 had similar results from 2.4.20. I'm thinking that either this is only an i586/i686 thing, or that perhaps (if the code is in glibc) it's a problem caused by building glibc with -march=i486 in LFS. I know the book has been updated to 2.4.21, but for me the dependency on libatomic_ops seems bogus - at a minimum it would be nice to limit it to 32-bit x86 machines.
I compiled that on my linux system, and when compiling for 32bit, it failed due to
In file included from intel_bufmgr_gem.c:56: intel_atomic.h:58:2: error: #error libdrm-intel requires atomic operations, please define them for your CPU/compiler.
I found http://bugs.freedesktop.org/show_bug.cgi?id=24381 that suggested -march=i686, and it compiled.
Note: I am currently using a multilib system. This may affect the my results
I did not use the atomic_ops package, nor did I see any warning/information that I may want it when compiling libdrm.