Last Comment Bug 56464 - RealPlayer 7 plugin does not work on Linux
: RealPlayer 7 plugin does not work on Linux
Status: VERIFIED WONTFIX
[rtm-]
:
Product: Plugins Graveyard
Classification: Graveyard
Component: RealPlayer (Real) (show other bugs)
: unspecified
: x86 Linux
: P3 major
: ---
Assigned To: av (gone)
:
:
Mentors:
: 70956 81405 87627 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2000-10-13 10:38 PDT by Chris Waterson
Modified: 2016-04-28 09:13 PDT (History)
17 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
screenshot of realplayer plugin working (160.29 KB, image/png)
2000-10-13 15:48 PDT, Stuart Parmenter
no flags Details

Description Chris Waterson 2000-10-13 10:38:06 PDT
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?
Comment 1 R.K.Aa. 2000-10-13 10:58:03 PDT
Have you tried adding it as a helper app instead, on a fresh install? :)
Comment 2 shrirang khanzode 2000-10-13 11:06:29 PDT
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
Comment 3 Christopher Blizzard (:blizzard) 2000-10-13 11:15:08 PDT
Not true.  4.x plugins do work due to some Xt magik.
Comment 4 ekrock's old account (dead) 2000-10-13 11:24:10 PDT
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
Comment 5 ekrock's old account (dead) 2000-10-13 11:26:40 PDT
(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.
Comment 6 Christopher Blizzard (:blizzard) 2000-10-13 11:45:50 PDT
Depending on what GUI?  We support Xt plugins ( read - Motif ) and Gtk plugins.
 They should work.  If they don't, it's a bug.
Comment 7 Mike Shaver (:shaver -- probably not reading bugmail closely) 2000-10-13 12:06:03 PDT
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).
Comment 8 Stuart Parmenter 2000-10-13 13:13:45 PDT
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.
Comment 9 Stuart Parmenter 2000-10-13 13:14:49 PDT
note: I have run the real player 7 plugin in mozilla without any problems.
Comment 10 Stuart Parmenter 2000-10-13 14:22:24 PDT
I don't see a real audio 8 plugin anywhere.  only 7.   any pointers?
Comment 11 ekrock's old account (dead) 2000-10-13 15:28:20 PDT
> 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
Comment 12 Stuart Parmenter 2000-10-13 15:48:03 PDT
Created attachment 17063 [details]
screenshot of realplayer plugin working
Comment 13 Chris Waterson 2000-10-13 16:24:47 PDT
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.
Comment 14 Chris Waterson 2000-10-13 16:38:18 PDT
*gurgle* Pavlov says it works, I can't find a reasonable version to install for
my RH6.2. Screw it.
Comment 15 R.K.Aa. 2000-10-13 18:12:49 PDT
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?
Comment 16 Christopher Blizzard (:blizzard) 2000-10-13 19:29:30 PDT
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.
Comment 17 Stuart Parmenter 2000-10-13 19:48:40 PDT
i'm running debian with glibc 2.1.3 and it works fine
Comment 18 R.K.Aa. 2000-10-13 20:09:19 PDT
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?
Comment 19 Stuart Parmenter 2000-10-13 20:17:32 PDT
all i did was copy rpnp.so in to dist/bin/plugins and add the real player
directory to my path.
Comment 20 Stephen Moehle 2000-10-13 20:53:32 PDT
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.
Comment 21 Christopher Blizzard (:blizzard) 2000-10-14 18:05:54 PDT
The missing __pure_virtual just screams compiler issue.  I'm still waiting to
hear from one of my partners in crime.
Comment 22 R.K.Aa. 2000-10-14 18:24:12 PDT
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.
Comment 23 Christopher Blizzard (:blizzard) 2000-10-16 12:48:22 PDT
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.
Comment 24 R.K.Aa. 2000-10-16 12:57:28 PDT
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.
Comment 25 Christopher Blizzard (:blizzard) 2000-10-16 13:08:26 PDT
This is a symbol resolution issue, not a problem affected by the filesystem data
source.
Comment 26 R.K.Aa. 2000-10-16 13:42:41 PDT
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?
Comment 27 ekrock's old account (dead) 2000-10-17 11:40:18 PDT
[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.
Comment 28 Stephen Moehle 2000-10-17 11:59:10 PDT
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.
Comment 29 Mike Shaver (:shaver -- probably not reading bugmail closely) 2000-10-17 12:37:40 PDT
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.
Comment 30 ekrock's old account (dead) 2000-10-17 15:32:26 PDT
> 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!
Comment 31 Ari Pollak 2000-10-22 18:41:58 PDT
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.

Comment 32 Raja Harinath 2000-10-27 14:25:37 PDT
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.
Comment 33 Ari Pollak 2000-11-09 20:46:38 PST
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.
Comment 34 Raja Harinath 2000-11-09 21:11:40 PST
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.
Comment 35 Ari Pollak 2000-11-10 08:16:39 PST
Hmph. Also, it seems that when I turn on --enable-debug in my CVS build, the
realplayer plugin doesn't work again.
Comment 36 phsu 2000-12-07 14:58:31 PST
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
Comment 37 Christopher Blizzard (:blizzard) 2000-12-07 17:15:17 PST
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.
Comment 38 Dave 2001-01-18 15:09:20 PST
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.
Comment 39 Christopher Blizzard (:blizzard) 2001-01-18 15:21:03 PST
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.
Comment 40 Greg Wright 2001-01-22 17:59:54 PST
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.
Comment 41 Chuck Musser 2001-01-23 21:30:02 PST
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?
Comment 42 Robert Kaiser 2001-01-24 09:10:41 PST
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 :)
Comment 43 mjw 2001-01-26 15:55:13 PST
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.
Comment 44 Christopher Blizzard (:blizzard) 2001-01-28 11:51:15 PST
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.
Comment 45 Vesa Halttunen 2001-03-06 01:34:57 PST
*** Bug 70956 has been marked as a duplicate of this bug. ***
Comment 46 David Shochat 2001-03-27 18:52:50 PST
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.
Comment 47 R.K.Aa. 2001-05-17 12:08:08 PDT
*** Bug 81405 has been marked as a duplicate of this bug. ***
Comment 48 Dave 2001-06-25 09:51:00 PDT
*** Bug 87627 has been marked as a duplicate of this bug. ***
Comment 49 shrirang khanzode 2002-02-27 13:18:51 PST
v

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