Closed Bug 56464 Opened 25 years ago Closed 25 years ago

RealPlayer 7 plugin does not work on Linux

Categories

(Plugins Graveyard :: RealPlayer (Real), defect, P3)

Product:
Plugins Graveyard
Component:
RealPlayer (Real)
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: waterson, Assigned: serhunt)

References

Details

(Whiteboard: [rtm-])

Attachments

(1 file)

screenshot of realplayer plugin working
160.29 KB, image/png
Details
The RealAudio 8 plugin works fine with 4.x on Linux, but will not load in Seamonkey. To reproduce: 1. Download "RealAudio 8 Player", Linux 2.2 RPM from http://www.realaudio.com/ 2. Install it (rpm --install <whatever-you-saved-the-file-as>) 3. Verify that "rpnp.so" has been installed in your $(DIST)/bin/plugins directory; if not, copy it from the 4.x plugins directory. 4. Start seamonkey 5. Type "about:plugins" Expected: Real Audio player shows up in the list Actual: no plugin appears, cannot play RA streams I debugged this, and it turns out that it's failing to resolve the symbol "__pure_virtual" when it's dlopen()-ing rpnp.so. I've tried twiddling with the linker flags that we pass to PR_LoadLibrary() in nsPluginsDirUnix.cpp http://lxr.mozilla.org/mozilla/source/modules/plugins/nglsrc/nsPluginsDirUnix.cpp#157 but to no avail. Any ideas?
Keywords: 4xp, rtm
Have you tried adding it as a helper app instead, on a fresh install? :)
4.x plugins on linux won't work in seamonkey due to the GUI changeover from 4.x to 6.0. Pls read: http://www.mozilla.org/docs/plugin.html#linux
Not true. 4.x plugins do work due to some Xt magik.
INVALID. 4.x plug-ins don't work on Moz/N6 Linux (except for Flash) due to Motif-to-GTK GUI switchover. See http://www.mozilla.org/docs/plugin.html#linux
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
(Sorry, hadn't seen shrir's or blizzard's comments when I responded earlier.) blizzard, according to the plug-in vendor contacts I've been in touch with, it is not generally true that Nav4.x plug-in binaries work on Moz/N6 Linux. It's true in the specific case of Flash, but only because the Flash plug-in writes directly to X without relying on the GUI. Verifying INVALID.
Status: RESOLVED → VERIFIED
Depending on what GUI? We support Xt plugins ( read - Motif ) and Gtk plugins. They should work. If they don't, it's a bug.
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
ekrock: have you actually seen such plugins fail? blizzard has seen them work, and has worked on the things that make them work, so I'd be very surprised if he was wrong here (modulo bugs).
i'm pretty sure that all plugins should work. There is no reason why any motif plugins should work so long as *they* are statically linked against motif (or you have motif installed) since they can't depend on us being linked against motif anymore.
note: I have run the real player 7 plugin in mozilla without any problems.
I don't see a real audio 8 plugin anywhere. only 7. any pointers?
> i'm pretty sure that all plugins should work. There is no reason why any > motif plugins should work Pav, did you mean to say "there is no reason any motif plug-in should work," or "there is no reason any motif plug-in should NOT work"? (BTW, avoiding unnecessary negatives by using positive constructions such as "all plug-ins should work" can save confusion all around; Elements of Style by Strunk & White is a great reference on this. ;-> ) > I have run the real player 7 plugin in mozilla without any problems. On Linux under GTK? Chris, you're using the "community supported" RealPlayer for Linux? And is that RealPlayer 8 or an earlier version? cc:ing johng who's tracking this. All: 1) the claim that all legacy Nav4.x plug-ins (written to a Motif GUI) should work on N6 for Linux (with its GTK GUI) is wonderful news if true but it contradicts everything I've been told previously. In particular, ramiro argued at length in the past that this was flat-out impossible to achieve. cc:ing ramiro for any input. 2) When you state "legacy Linux Motif plug-ins work," please specify which GUI you're talking about (Mozilla/N6 running under GTK or Mozilla running under XT/Motif) so I understand what you're saying--thanks! ;-> 3) If Chris's additional work has indeed enabled the usage of legacy Linux/Motif plug-ins under N6/Moz Linux with its new GTK UI, then we need to update the Mozilla Plug-in API doc to reflect this: http://www.mozilla.org/docs/plugin.html#linux
Pavlov pointed out that I am a dumbass: 1. There is no RealPlayer 8 yet, so I really meant RealPlayer 7 2. I probably downloaded the wrong version of the plugin (libc6) I'm going to see what else I can find, and will report back soon. This may be pilot error.
*gurgle* Pavlov says it works, I can't find a reasonable version to install for my RH6.2. Screw it.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → INVALID
AFAIK libc6 is glibc? (whereas libc5 is the older, original ELF libc.) So the libc6 community supported player is the one that should work with RH6.2. If it's any comfort, i can't make it work either. Nor can i edit mimetypes to use it as an application instead, since the pref table is empty and adding helper apps only spawn js errors and create mimeTYpes.rdf with invalid syntax :) I now have rpnp.so and raclass.zip from Realplayer7 all over the disk here, in various plugin dir's (both my users moz-dir and mozilla's installation dir /usr/local/mozilla/plugins. Mozilla doesn't see that plugin if i stand on my head. Do i have to have java installed in order for this to work?
For what it's worth I've tried to use the real player 7 plugin for a long time and it's never worked. I've never tried to track it down. And for Erik's sake I'll say it: Legacy Motif Linux plugins should work with the GTK gui. I didn't know the faq existed or I would have updated it myself.
i'm running debian with glibc 2.1.3 and it works fine
Well that's one for Debian. RG6.2 with glibc 2.1.3 here, and it worketh not. Would you mind attaching your mimeTypes.rdf and/or other relevant settings that might make this work? Also: where in the world do you place the plugins as such? Do you link to them? Or did sweet mozilla see the plugin as a plugin as soon as you had copied it to /usr/local/mozilla/plugins, and thereafter it recognized all realplayer file-extentions and you never knew what happened?
all i did was copy rpnp.so in to dist/bin/plugins and add the real player directory to my path.
Hmph. I'll be damned if I can get it to work on my RH 6.2 glibc 2.1.3 machine. I downloaded and installed rp7_linux20_libc6_i386_cs1.bin and added the dir to my path. I copied rpnp.so to my plugins directory. I do not see the RealPlayer plugin when I do about:plugins, nor will Mozilla load the plugin fo RealAudio content. I am not sure why it does not work. realplay by itself works fine, and rpnp.so looks to be 100% statically linked.
Summary: RealAudio 8 plugin does not work on Linux → RealPlayer 7 plugin does not work on Linux
The missing __pure_virtual just screams compiler issue. I'm still waiting to hear from one of my partners in crime.
In the meanwhile i filed bug 56650, since this one was marked invalid. NC4.75 plays Real plugins like a dream. Moz bluntly refuse to cooperate. There are real problems.. path's aren't seen.. files may be missing.
So, this is interesting. If I run the version that I have compiled on RH 6.2, it has the problem. If I run the version that I've compiled on RH 7, the plugin works. Still looking.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Please be aware of bug 56779: Right now, moz barely see files on disk at all, which probably cause some mishaps. Bug 52441 also interesting: mozilla doesn't know mailcap and mime.types from a hole in the ground - nothing it would admit to anyways.
This is a symbol resolution issue, not a problem affected by the filesystem data source.
Oh well. I couldn't even start realplayer ("manually") as a helper app, since filepicker had no idea the directory existed. But even if that is unrelated, the mimetype issues are still interesting?
[rtm-]. Future. We never expected legacy Linux plug-ins to work in the first place for RTM because of the GUI switchover issue. It's a pleasant surprise that in some Linux environments, some legacy Linux plug-ins work after all thanks to the last several months of fixes. However, it's clearly the case from the above analysis that this will work on some Linux versions and not others, and this is not an RTM stop-ship issue. The real solution is for RealNetworks to release an upgraded Linux plug-in binary that supports the Mozilla plug-in API natively (including LiveConnect) and has been tested against Mozilla/N6 from the get-go; when that happens, this bug should change to WONTFIX and we'll support only the officially upgraded version.
Whiteboard: [rtm-]
Target Milestone: --- → Future
And just when do you expect Real to support NS6 on Linux? Look at how long it took them to support NN4. I am a little disappointed that Linux users are still considered second class around here, and that we will not even get what little support we had with NN4.
Eric: I think your WONTFIX plan is gravely mistaken. Mozilla _does_ expect Linux legacy plugins to work, which is why people have spent so much time and effort making it that way. I think that the plugin doc _should_ be updated to reflect current reality, though, which is that all 4.x Xt/Motif plugins that do not expect to find Motif symbols in the browser[*] should work in Mozilla. [*] This stopped working in later 4.x versions too, I think, when we/Netscape changed the way we linked with Motif, such that we weren't providing a linkable version of Motif with every copy of Navigator! I also don't understand this: It's true in the specific case of Flash, but only because the Flash plug-in writes directly to X without relying on the GUI. Could you elaborate? Is it using DRI or something to talk to the framebuffer directly? I can't imagine that it's opening up its own connection to the X server -- and that it would work! How would it scroll? -- so I'm fresh out of ideas.
> Eric: I think your WONTFIX plan is gravely mistaken. Hi Mike, thanks for your concern, but criticism helps little at this point. Do you care enough about this problem to fix it yourself? Or can you identify another engineering resource who can analyze and fix this in time for RTM? Netscape is out of staff time and resources at this point and there are no easy decisions. It's not a mistake to not allocate staff time I don't have. Bugs that happen in some configurations and not others and only block usage of the plug-in at the worst are a lower priority than reproducible crashers (of which we have more than one on Linux). It's put up or shut up time for us all. We'd gratefully appreciate any offers of help! > I think that the plugin doc _should_ be updated to reflect current reality Yes, I agree it should be updated but lack the time to do this right now myself--it's a far lower priority than my ongoing realtime triaging for RTM. Would you email a proposed text edit to oeschger@netscape.com? > It's true in the specific case of Flash, but only because the > Flash plug-in writes directly to X without relying on the GUI. Even before all of Pav's check-ins that miraculously got legacy Nav4 Motif plug-ins such as RealPlayer working at least in some versions of Linux, Flash was working. I was told at the time that this was because Flash, unlike other plug-ins, had no Motif GUI dependency and instead wrote directly to X. Have no proof that this is correct or even possibly correct; it's simply what I was told. Perhaps the real reason was that Flash statically linked in the needed Motif binaries and it simply started working sooner than the other plug-ins? No idea. All info would be appreciated!
OK, I think I figured out why the plugin was not working on my Mozilla on Linux. In ~/.mailcap, I had a line that said that Mozilla should prompt the user for a player for audio/x-pn-realaudio-plugin files... taking that line out seems to have made the plugin work again. Apparently the fact that it uses Motif has nothing to do with it.. Here's what the relevant lines in my ~/.mailcap look like: audio/vnd.rn-realaudio,audio/x-realaudio;/usr/bin/X11/realplay %u audio/vnd.rn-realaudio,audio/x-realaudio,audio/x-pn-realaudio-plugin;/usr/bin/X11/realplay %u audio/x-pn-realaudio;realplay %s audio/x-pn-realaudio,audio/x-pn-realaudio-plugin;realplay %s Now after looking at those lines, some of them seem redundant.. But it works, so I'm not gonna play around with it too much.
An nm --dynamic on the rpnp.so doesn't have any references to Xt* or Xm*. It looks like rpnp.so dispatches a request to the rpnphelper binary, which appears to have Motif statically linked. So, ideally, this plugin should work if the Java plugin works, since it has a similar client/server model. Still, the plugin doesn't work for me. I don't have any references to a 'audio/xpn-realaudio-plugin' in my ~/.mailcap.
This is really weird. It seems that when I build Mozilla from CVS, the plugin works fine. but the nightlies don't show RealPlayer in the plugin list.
It is likely a GCC/Libc thing. Very likely related to all that brouhaha about whether shared objects should have a copy of libgcc.a. If the nightlies are built, say on Red Hat 7.0, and run on Red Hat 6.x, you may see the problems. The reason things work OK with a local build is that your enviroment is internally consistent, but not compatible with whatever is used to build the nightlies.
Hmph. Also, it seems that when I turn on --enable-debug in my CVS build, the realplayer plugin doesn't work again.
Just for the record. This still doesn't work for me in either the nightly or (pretty much the same thing) mozilla .6 RedHat 6.2, Pentium
Yeah, I still don't know how to fix it. It's a compiler issue. Some versions of the compiler include the library that include __pure_virtual, some don't.
FYI: Was running 2001011608/Mtrunk on Mandrake 7.1 w/t gcc-2.95.2-7mdk. I downloaded real player from http://www.real.com and moved the pertinent files from /usr/local/netscape/plugins to [Moz_home_dir]/plugins and it didn't work. HOWEVER, after reading the comments from this bug I decided to try upgrading to the build from ftp://ftp.mozilla.org/pub/mozilla/nightly/2001-01-18-00-Mtrunk-gcc295/ (note: same compiler I have installed) and tried again. This time the plugin was registered and worked just fine (I was able to view a music video at http://www.rollingstone.com/sections/vtheater/text/default.asp?from=). I don't know how much help this is or if it even says anything new to anyone but at least people running Mandrake (7.1, at least) should now be able to get the realplayer plugin working.
This appears to be a problem with compiler versions and whether or not libgcc.a ( which includes __pure_virtual ) was included in .so files. This apparently changed around the 2.95 version or so. So, if you compile mozilla with gcc 2.95 or later it should work. For example, it works on my RH 7 box which has a compiler later than 2.95 on it.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WONTFIX
Just some ideas. Because of the instability of libstdc++ in the past, we(Real) historically couldn't link against that library. Instead, we let the top level app bring in and expose the c++ symbols. We do this by linking with the following link options: --whole-archive `g++ -print-file-name=libgcc.a` --no-whole-archive These options will bring in the symbols from libgcc.a into the global namespace of the app so that the plugins can resolve against them. This may be why you are seeing the unresolved __pure_virtual. Many of our SDK users have this problem under linux until they start to link this way. I don't know why the plugin would be working on some mozilla builds while it doesn't work on others though. All of our plugins and apps are compiled on Debian systems using gcc 2.95.2.
The RealPlayer8 plugin doesn't work on my system either. Platform: Red Hat 6.0/x86 libc version: 2.1.3 (upgraded from 2.1.1 so that JDK 1.3 would work) c++ library version: 2.9.0-12. mozilla build: 2001012208 (downloaded from ftp site) I don't know what gcc version the nightly builds are created with, but it seems reasonable that the libraries on my system also have something to do with it not working. Any suggestions on what I might try upgrading?
Nice! Just if someone wants to know: Realplayer 7 plugin works for me with new gcc2952-nightlies (2001-01-24-00), and I think this is really great! This is a SuSE Linux 7.0 box, btw, for anyoneone on that systems who wants real7 to work :)
I'm running RedHat 6.2 with all the updates. I've also upgraded to gcc 2.96 that shipped with RedHat 7.0. The nightly builds don't work with RealAudio, but I checked out the source from CVS and built Mozilla myself, and it works now.
It might be worth it to try and use the hack that is described to try and get the plugin library linking with libgcc.a to work around this problem. We need to add an autoconf test of some kind to test for the compiler version and the hack for gcc only systems.
*** Bug 70956 has been marked as a duplicate of this bug. ***
This is still broken in 0.8.1 binary. But as others have reported here, all it takes to fix it is to compile mozilla using gcc 2.95.2 (and I have confirmed that). So I don't understand why the binaries are (apparently) being compiled with an older gcc. 2.95.2 is an official gcc release version.
*** Bug 81405 has been marked as a duplicate of this bug. ***
*** Bug 87627 has been marked as a duplicate of this bug. ***
v
Status: RESOLVED → VERIFIED
Component: Plug-ins → RealPlayer (Real)
Product: Core → Plugins
QA Contact: shrir → real-player
Target Milestone: Future → ---
Version: Trunk → unspecified
Product: Plugins → Plugins Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: