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
but to no avail. Any ideas?
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:
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
(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.
Depending on what GUI? We support Xt plugins ( read - Motif ) and Gtk plugins.
They should work. If they don't, it's a bug.
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
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.
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:
Created attachment 17063 [details]
screenshot of realplayer plugin working
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
*gurgle* Pavlov says it works, I can't find a reasonable version to install for
my RH6.2. Screw it.
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
I am not sure why it does not work. realplay by itself works fine, and rpnp.so
looks to be 100% statically linked.
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.
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
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.
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 firstname.lastname@example.org?
> 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:
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.
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
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
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.
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
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?
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. ***