Note: ldd can't handle dlopen'ed dependent libraries and these unresolved symbols might be resolved by those. But this needs to be checked. Reproducer: rpm -ql <packagename>| grep lib.*so | xargs ldd -r This might not be a problem as X uses loadable modules for lots of stuff, but please check if this is the case here xorg-x11-drv-i810-devel-1.6.0-6.modeset20060707 undefined symbol: drmCommandWriteRead (/usr/lib/libI810XvMC.so) undefined symbol: drmCommandWrite (/usr/lib/libI810XvMC.so) undefined symbol: drmUnlock (/usr/lib/libI810XvMC.so) undefined symbol: _xvmc_create_context (/usr/lib/libI810XvMC.so) undefined symbol: XQueryTree (/usr/lib/libI810XvMC.so) undefined symbol: drmOpen (/usr/lib/libI810XvMC.so) undefined symbol: drmGetMagic (/usr/lib/libI810XvMC.so) undefined symbol: drmAvailable (/usr/lib/libI810XvMC.so) undefined symbol: drmUnmapBufs (/usr/lib/libI810XvMC.so) undefined symbol: XFree (/usr/lib/libI810XvMC.so) ...
These files are the XvMC drivers, which are dlopen()'d by libXvMC* client libraries. Nothing should be dynamically linking to these files. (But I'm not surprised at all if some 3rd party apps do so). Really, IMHO at least, the .so files should not even be supplied by the OS at all. Applications should not have hard coded hardware specific libs linked into them... but that's another ball of wax... On a side note, I notice you've filed this against x86_64, but your file paths have /usr/lib instead of /usr/lib64 in them. I've reviewed the spec file and we're using _libdir appropriately. Are you testing 32bit bits under 64bit kernel? Just curious...
Sorry, x86_64 was a mistake. I've run those tests on i386, although I'd expect similar results on 64bit
*** Bug 237503 has been marked as a duplicate of this bug. ***
*** Bug 237504 has been marked as a duplicate of this bug. ***
NOTABUG. The XvMC drivers aren't real DSOs, they only exist to be dlopen()d by livXvMC.