libdrm-2.4.15

[Trent Shea]

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

[Nathan Coulson]

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.

[Trent Shea]

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?

[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.

[Trent Shea]

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...

[DJ Lucas]

2.4.14 works correctly AFAICT. Gonna leave this set for a bit until 2.4.16.

[Wayne Blaszczyk]

FYI, libdrm-2.4.14 has a missing required dependency, libpthread-stubs-0.1.

[Randy McMurchy]

Updated milestone to 6.7

[ken@…]

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.

[bdubbs@…]

Not at libdrm-2.4.27

[bdubbs@…]

Milestone 6.7 deleted