---- Description of problem: Updated XFree86 packages break the system by failing to export proper XF86VidMode symbols... as can be demonstrated with: % ldd -r abinarythatwontrun . . . undefined symbol: XF86VidModeQueryVersion undefined symbol: XF86VidModeSetViewPort undefined symbol: XF86VidModeQueryExtension undefined symbol: XF86VidModeLockModeSwitch undefined symbol: XF86VidModeSwitchToMode undefined symbol: XF86VidModeGetAllModeLines undefined symbol: XF86VidModeGetModeLine % -------- Version-Release number of selected component (if applicable): I first noticed the problem after I updated with yum to the XFree86-4.3.0-55 packages. --------- How reproducible: What's particularly pernicious about this error, is that you don't notice when you compile a program. You just get a "relocation error" when you try to run it. --------- Steps to Reproduce: I first noticed it with mplayer 1. Download mplayer from http://www1.mplayerhq.hu/MPlayer/releases/MPlayer-1.0pre4.tar.bz2 2. tar jxvf Mplayer-1.0pre4.tar.bz2 3. cd Mplayer-1.0pre4.tar.bz2 4. ./configure Mplayer-1.0pre4.tar.bz2 --prefix=/usr/local 5. make 6. ./mplayer somefile.avi #Plays just fine. 7. ###Now, upgrade the XFree86 rpm's, and come back 8. ./mplayer somefile.avi #DOSEN'T WORK of course, given a relocation error, I assumed I just needed to recompile [although even an upgrade that broke the system this much would be a bit annoying!] So, 9. rm -fr Mplayer-1.0pre4.tar.bz2 10. wash, rinse, repeat steps 2-5 above. #seems to compile fine. 11. ./mplayer somefile.avi #STILL DOSEN'T WORK!!!!!! --------- Actual results: --------- Expected results: No undefined symbols. Additional info: back-grading to the original XFree86-4.3.0-42 rpm's fixed the problem. But I can thusly no longer use yum update to automatically fetch updates, because the posted (NON-TESTING!) updates are poisonous.
I recommend recompiling mplayer once the new X is installed. If the problem goes away, it was an mplayer bug. Another possibility is a prelinking issue. No other users have reported this problem, and all Xvidmode applications work for me on my test system, including mplayer. It's possible the specific version of mplayer you are using is buggy.
I left this open to have a further look today, and I discovered what the problem is. The problem is that your mplayer application is probably dynamically linked to libXxf86vm.so, which simply doesn't exist. In order for it to have gotten linked to a non-existant shared library, it would have had to been compiled on a non-Red Hat system which ships non-standard shared libraries. All XFree86 releases up to and including XFree86 4.3.0, do not ship all libraries in shared form. The reason for this, is that XFree86.org did not declare the library API or ABI for these libraries to be "stable" yet, and as such, shipping shared versions of these libraries would break all applications every time the library was updated or modified. By defaulting the build to build these libraries static-only, it allowed XFree86.org to make changes to the design of these interfaces without breaking runtime compatibility. Some individuals who compile XFree86 from source themselves, as well as a few Linux distributions out there however, do not follow this XFree86 defined standard, and have incorrectly built and shipped shared versions of these libraries. Red Hat mistakenly shipped 2 libraries in this manner (libXxf86dga and libXv) a long time ago in Red Hat Linux 7.1. After we discovered the problems this caused, we quickly removed these libraries from the distribution again, after we learned why these libraries were intentionally not shared by default by XFree86.org. This leads to the problem you're experiencing, which is that if an application is compiled on a non-compliant system and gets linked to the shared library, it then has a hard requirement that that library must exist on the system it is used on, however since it is a non-standard library, it doesn't exist on Red Hat OSs, so applications compiled on a non-conformant system that link to these nonstandard libraries will not ever run on a Red Hat system. The proper thing to do is to recompile these applications on a Red Hat or other compliant system, and the application will run on all Linux systems out there (including the non-conformant ones). Another problem that can happen with dynamic linking of these libraries, is when the interfaces do change in an incompatible way. In that case, your app still runs, but it wont work properly, since XFree86.org never defined the interface to be guaranteed to never change (the reason they never provide shared versions of these libraries by default). Short story: Recompile mplayer from source code, or rebuild the src.rpm package, and hopefully it should just work. You'll find the symbols you're looking for in: readelf -s /usr/X11R6/lib/libXxf86vm.a Closing as NOTABUG. (Additional side note: Since some distributions ship these libraries shared without regard for XFree86 standardization, and it has caused many users problems like you're experiencing, XFree86.org decided for the 4.4.0 release to ship all of the libraries shared by default, and instead to bump the .so version as needed when incompatible library changes are required. The result is that XFree86 4.4.0 and X.Org X11 now ship all shared libraries, and if both organizations keep up their end of the bargain, no incompatibilities will occur between releases, without shipping multiple versions of the libraries for compatibility. As such, future OS releases from various distributions, that ship X.Org X11 6.7.0 or XFree86 4.4.0 will no longer have such incompatibilities between apps compiled on one distribution and ran on another.)