Red Hat Bugzilla – Bug 126219
XFree86-4.3.0-55 rpm's break XF86VidMode
Last modified: 2007-11-30 17:10:44 EST
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
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
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
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!]
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!!!!!!
No undefined symbols.
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
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
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.)