Bug 28196 - No libXv.so or libXxf86dga.so
No libXv.so or libXxf86dga.so
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
7.1
All Linux
low Severity medium
: ---
: ---
Assigned To: Mike A. Harris
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-17 17:56 EST by Andrew Meredith
Modified: 2007-03-26 23:41 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-03-28 09:46:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andrew Meredith 2001-02-17 17:56:02 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.4.1 i686)


These shared libraries are needed by a number of video players, including
OMS.

I have attached a patch for the .spec file which will add them in at the
install stage. It has been tested to work on an upgraded i386 RH 7.0
system.

Reproducible: Always
Steps to Reproduce:
Not really relevant. The library is missing :)

The patch adds the libraries to XFree86-devel

Here's the patch:

--- XFree86.spec.orig   Sat Feb 17 21:45:59 2001
+++ XFree86.spec        Sat Feb 17 21:49:45 2001
@@ -657,6 +657,14 @@
 rm -f $RPM_BUILD_ROOT/usr/X11R6/lib/X11/app-defaults
 mv $RPM_BUILD_ROOT/etc/X11/app-defaults $RPM_BUILD_ROOT/usr/X11R6/lib/X11
 
+# Add in shared libraries for libXv and libXxf86dga for
+# use in video apps. I'm sure this could be done in the code,
+# but I know it can be done here :) <andrew@anvil.org>
+
+cd $RPM_BUILD_ROOT/usr/X11R6/lib/
+ld --whole-archive -shared -o libXv.so libXv.a
+ld --whole-archive -shared -o libXxf86dga.so libXxf86dga.a
+
 # All other moved directories are wholly contained by the XFree86
 # packages
Comment 1 Bill Nottingham 2001-02-17 22:23:16 EST
Why don't they just use the static libraries?
Comment 2 Mike A. Harris 2001-02-19 03:00:15 EST
This sort of change is IMHO to late to go into the next release at this
stage.  I've changed it to an RFE, and am deferring it for a future
release.  I won't guarantee it will go in, but I will examine it as a
possibility at some point in the future.
Comment 3 Andrew Meredith 2001-02-19 06:20:13 EST
In answer to notting@redhat.com 2001-02-17 22:23:16

Because these complex apps are one massive pile of shared libraries .. oms
certainly is. libXv and libXxf86dga are just two of dozens of shared libraries
involved in the overall app. To rearrange things in order to use these two libs
static and the rest shared would just be one massive kludge and would almost
certainly introduce complexity that would cause the project to slow down for no
apparent gain.

In answer to mharris@redhat.com 2001-02-19 03:00:15

Thank you.
Comment 4 Mike A. Harris 2001-03-28 09:46:54 EST
It's in 4.0.3 now.
Comment 5 Andrew Meredith 2001-03-28 11:15:56 EST
Thanks very much. I'll let the folks know

Andy M
Comment 6 Need Real Name 2001-11-03 00:40:59 EST
xfree86 4.1.0 in Redhat 7.2 seems to be suffering this problem again. please
check
Comment 7 Mike A. Harris 2001-11-03 05:07:48 EST
Sorry, but this is not an issue.  When I initially received this bug
report, I didn't think much of it, other than a general enhancement
request.  As such, it sounded reasonable at first, so I went ahead and
added it.

"At first" is the key word here.  This was a HORRIBLE error on my part,
and I learned a valuable lesson about it.

XFree86 as shipped in source form, predefines what libraries are shared,
and what libraries are NOT shared.  The ones that are not shared, are
not shared for a _very_ good reason.  Their API/ABI is not considered
stable by the XFree86 core team, who reserve the right to change this
at any time, even without bumping the .so version numbers.  This is the
reason that the libs are not shared in XFree86 by default.

Unfortunately... I did not understand that at the time, and so I enabled
these 2 libraries, as it seemed like a reasonable request at the time.

BAD MOVE on my part.  That bad move, made Red Hat Linux incompatible
with ALL other shipping XFree86 releases out there from a binary application
perspective.

When this was discovered, the problem was fixed, by reverting these
changes, and ONLY shipping the core shared libraries that XFree86
defines.  A discussion about this ensued on devel@xfree86.org, and
myself, David Dawes (XFree86 founder), Branden Robinson (Debian
X maintainer) and others, agreed that we need to have a common
core standard which EVERYONE else follows.

I reverted the change as said above, and regret strongly having made
the change in the first place.  It was a change that was just plain
wrong.  If Xine or any other application is linked against these
shared libraries then:

1) Xine is broken
2) The system Xine was built on was also broken.

Again, NO application should link to any of the XFree86 libraries
in a shared form, that are not shared by default in the XFree86
core sources default config.

In the interest of maintaining backward compatibility with applications
that were linked accidentally against these 2 libraries, Red Hat Linux
7.2 has included a backward compatibility package to provide these
shared libraries for runtime usage only.  The .so symlinks for linking
with are not included.   This is only for backward compatibility.

That was the long story, just to explain the whole situation for
everyone watching this bug report, or who query for the same problem
in the future.  The short story, is that initially when this was filed
as an enhancement request, I should have said "no".

So... any apps depending on these or any other shared libs that
are no longer included - are broken.  Recompile them, and the problem
should disappear.
In final note, I also need to point out that at least one other Linux
distribution vendor (Mandrake) have copied this bug from us.  Unfortunately,
they did not copy the bugfix, which is to remove these shared libs from
their distro to maintain inter-distribution compatibility.  As such,
any applications built on a Mandrake Linux system that contains these
extra shared libraries, will _only_ run on Mandrake Linux.  I do not
know if other vendors have made this mistake or not, but hopefully any
that have will also bite the bullet and correct the problem ASAP to
ensure future binary compatibility between each other.

I hope that clarifies everything.   If you need the runtime compatibility
shared libraries, they are in "XFree86-compat-libs" package that ships
as part of Red Hat Linux.
Comment 8 Jeff Thurston 2004-09-07 08:55:28 EDT
Trying to run Wine 20040716 on RedHat Enterprise Linux.

uname -srv
Linux 2.4.21-15.0.4.EL

Wine is squaking about needing this library. I fully understand Mike's
response above. My quick question is if this has changed or is Wine
going down the wrong path?

Jeff Thurston
thurston@apci.net
Comment 9 Mike A. Harris 2004-09-07 19:00:27 EDT
All releases of XFree86 up to and including XFree86 4.3.0 do not
ship with shared versions of the above libraries.  XFree86 4.4.0,
and X.Org X11 6.7.0 and later releases started shipping all of the
libraries in shared form.

In order to run software which has been linked to the shared
versions of these libraries, the libraries must be present on the
operating system in shared form.

The wine that you've got is probably compiled on a Fedora Core 2
or later system (which uses X.Org X11 6.7.0 with shared versions
of these libraries), or on Mandrake or some other OS that provides
the shared versions of these libraries.  You'll need to recompile
the src.rpm (or raw wine source code) in order for it to run
on Red Hat Enterprise Linux 3 or 2.1.

Hope this helps.

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