Description of problem: Real Player 8 will not run on Red Hat 9 stock kernel, but if I compile a custom kernel it works. I don't know what I enable to make it work, but it does. Version-Release number of selected component (if applicable): How reproducible: Just install Real Player 8, and try to start it. Steps to Reproduce: 1. 2. 3. Actual results: Won't start Expected results: Play audio Additional info:
Duplicate of bug #86440.
Since I get a fatal error upon trying to add a comment to bug #86440 (I have submitted a bug report about this as bug #88008), I add my comment here: Realplayer works for me with either of env LD_ASSUME_KERNEL=2.2.5 realplay env LD_ASSUME_KERNEL=2.4.1 realplay Though, the Realplayer plug-in for Mozilla is likely to cause trouble.
*** Bug 86440 has been marked as a duplicate of this bug. ***
*** Bug 89108 has been marked as a duplicate of this bug. ***
While there is a bug occuring here, it is a bug in real player, not in glibc, not in XFree86, not in the kernel. It is understandable that when people experience problems in software that didn't occur in past releases that they will assume that it is some new regression in some software component in new operating system releases. The real problem, is that various applications are written with certain broken assumptions in them, such as relying on library routines to exist which aren't standard, or relying on certain routines to work a certain way when the way they are expecting things to work is officially "undefined". Any application is by definition "broken", if it is written to expect a certain specific defined behaviour from any library or interface, which is officially "undefined". When something is undefined it means that any behaviour may occur and that you can't rely on any specific behavior, or if you could, then it would by definition be "defined standard behavior" and wouldn't be undefined to begin with. Why then does something work in one release, and not in another? Simple, "undefined behaviour", may result in something working just fine with a piece of code, even though that code is broken, the undefined behaviour just so happens to provide behaviour at that time that the broken application expects, and so "it just works". Later, in future releases, when that behaviour changes but still remains undefined, the applications which relied on a *specific* behaviour out of an undefined interface end up no longer working, and what you end up with, is things like realplayer no longer working due to relying on undefined behaviour which has changed. The real bug in these cases is in the applications themselves, and the real fix, is for the supplier of the broken applications to fix them and release updates. Hopefully in doing so, they remove all reliance on undefined behaviour so that their applications don't break again in the future as other undefined things change. Once users upgrade to the fixed application, they no longer will experience the problem from the broken application version which just randomly happened to work previously. Red Hat additionally provides some levels of backward compatibility which may or may not allow broken applications to work, by providing both the new interfaces, as well as some of the older ones. By default, the new system is used, and when users experience broken applications such as realplayer, some Java implementations, Adobe acroread, and some other similarly broken software, users can use LD_ASSUME_KERNEL as Michael Schwendt mentions above to work around the bugs in the broken software. There are some comments about this in the RELEASE-NOTES of the distribution as well. Hopefully the various broken applications out there will get fixed soon to not rely on broken undefined behaviour, and users will be able to upgrade the software they use to newer bug fixed versions. In the meantime, use the workarounds which Red Hat graciously provides to users to use the various broken software out there, while at the same time progressing forward with technology enhancements that continue to make Linux a strong technology, without having to crud up the kernel, glibc and other interfaces with long term compatibility hacks and kludges to make up for the flaws in various broken software out in the wild.