Bug 126219 - XFree86-4.3.0-55 rpm's break XF86VidMode
Summary: XFree86-4.3.0-55 rpm's break XF86VidMode
Alias: None
Product: Fedora
Classification: Fedora
Component: XFree86   
(Show other bugs)
Version: 1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2004-06-17 18:01 UTC by D Brooks
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-07-07 06:20:20 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description D Brooks 2004-06-17 18:01:12 UTC
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
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!]

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.

Comment 1 Mike A. Harris 2004-07-06 00:50:10 UTC
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.

Comment 2 Mike A. Harris 2004-07-07 06:20:20 UTC
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

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

Note You need to log in before you can comment on or make changes to this bug.