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> + +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
Why don't they just use the static libraries?
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.
In answer to notting 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 2001-02-19 03:00:15 Thank you.
It's in 4.0.3 now.
Thanks very much. I'll let the folks know Andy M
xfree86 4.1.0 in Redhat 7.2 seems to be suffering this problem again. please check
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, 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.
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
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.