Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 100809 - net-www/mplayerplug-in-3.05, linking against mozilla/mozilla-firefox and the rpath patch
Summary: net-www/mplayerplug-in-3.05, linking against mozilla/mozilla-firefox and the ...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Joe Jezak (RETIRED)
URL:
Whiteboard:
Keywords:
: 101594 105795 (view as bug list)
Depends on: 100597
Blocks: 93546 101543
  Show dependency tree
 
Reported: 2005-07-30 06:05 UTC by Gergan Penkov
Modified: 2005-09-29 00:10 UTC (History)
13 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
mplayerplugin-in-rpath.patch (rpath.patch,386 bytes, patch)
2005-07-30 06:11 UTC, Gergan Penkov
Details | Diff
mplayerplug-in-3.01.ebuild (mplayerplug-in-3.01.ebuild,1.48 KB, text/plain)
2005-08-01 04:04 UTC, Gergan Penkov
Details
mplayerplug-in-rpath.patch (rpath.patch,1.00 KB, patch)
2005-08-01 04:09 UTC, Gergan Penkov
Details | Diff
mplayerplug-in-3.05.ebuild (mplayerplug-in-3.05.ebuild,2.24 KB, text/plain)
2005-08-06 07:48 UTC, Gergan Penkov
Details
mplayerplug-in-3.05.ebuild (mplayerplug-in-3.05.ebuild,2.23 KB, text/plain)
2005-08-06 10:54 UTC, Gergan Penkov
Details
ebuild for 3.05 without rpath, with gecko-sdk from mozilla (mplayerplug-in-3.05.ebuild,2.03 KB, text/plain)
2005-08-14 13:50 UTC, Joel Martin (RETIRED)
Details
mplayerplug-in-3.05.ebuild (mplayerplug-in-3.05.ebuild,1.96 KB, text/plain)
2005-08-15 16:07 UTC, Gergan Penkov
Details
ebuild for mplayerplug-in 3.05 with variable media support (mplayerplug-in-3.05.ebuild,3.43 KB, text/plain)
2005-09-12 00:39 UTC, Bartek Kostrzewa
Details
ebuild for 3.10 with variable media support and optional use of gecko-sdk (mplayerplug-in-3.10.ebuild,3.31 KB, text/plain)
2005-09-14 05:23 UTC, Bartek Kostrzewa
Details
3.11 ebuild (mplayerplug-in-3.11.ebuild,1.90 KB, text/plain)
2005-09-25 18:36 UTC, Joe Jezak (RETIRED)
Details
patch to let mplayerplug-in use the amd64 mplayer-bin package (mplayerplug-in-3.11-amd64-mplayer-bin.patch,405 bytes, patch)
2005-09-26 17:43 UTC, Harm Geerts
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Gergan Penkov 2005-07-30 06:05:08 UTC
1. There is some problem with mplayerplug-in dependancies, at least on my
computer. After installing it there was no picture only a gray box in the
browser with buttons (downloading works and the plugin thinks he is playing sth,
but even in fullscreen no picture), so I search a little bit in internet and
found that I probably need some plugger, so I installed mozplugger-1.7.1
(probably should be added as a runtime-dependancy).

2. The /opt/netscape/plugins/mplayerplug-in.so needs gecko-sdk to compile, but
after that will always link at runtime against the libraries in /usr/lib/nspr/,
because the gecko-sdk ones are not in the ldpath (is this a desired behaviour
?). So I've made a patch, which sets rpath/runpath dynamic tag to gecko-sdk
libraries path (but it needs a patch from bug 100597, which ensures that
gecko-sdk will link against oneself). You could try the current resolution with ldd.

After this mplayerplug-in works, but the buttons are not to be seen. Probably
bug in mplayerplug-in?
Comment 1 Gergan Penkov 2005-07-30 06:11:33 UTC
Created attachment 64728 [details, diff]
mplayerplugin-in-rpath.patch

This will set the rpath/runpath dynamic tag of the library, so it corectly 
resolves to gecko-sdk libraries and not to /usr/lib/nspr/ ones.
Comment 2 Gergan Penkov 2005-07-30 09:39:31 UTC
The first part of the bug is not relevant, the mozplugger dependancy is not
needed (it was only that the standard config does not set correctly the video
output). 
But the second one could probably cause crashes and should be resolved I think.
Comment 3 Gergan Penkov 2005-08-01 04:04:57 UTC
Created attachment 64861 [details]
mplayerplug-in-3.01.ebuild

Ebuild and after that a patch, which will build mplayerplug-in against mozilla
and does not need gecko-sdk anymore.
Comment 4 Gergan Penkov 2005-08-01 04:09:37 UTC
Created attachment 64862 [details, diff]
mplayerplug-in-rpath.patch

This is patch against mplayerplug-in-3.01 (but will probably work with 2.85)
and will build it with mozilla (and not gecko-sdk). 
Probably it could work with firefox also, but i didn't try it yet.
Comment 5 Jean-Francois Chevrette 2005-08-03 06:21:03 UTC
mplayerplug-in-3.01 does not show support for media of type Windows Media (wma,
wmv, asf, asx) QuickTime Media (qt, mov, mp4), RealAudio (ram, rv, rmv, ra) and
AVI files.
I've used the plugin under Fedora Core 4 and I could use these formats. 

I tried the ebuild poster here (using the patch) and compiling manually and they
do not show up under supported plugins in Firefox and Mozilla.

Any clues?
Comment 6 Gergan Penkov 2005-08-03 07:00:03 UTC
Add a line in the ebuild to 
	insinto /etc
	doins mplayerplug-in.conf
+       doins mplayerplug-in.types
And rebuild the package, after that you must change the line in
/etc/mplayerplug-in.conf to:
use-mimetypes=1 
and remove the # before it, you could also try the enable-... commands in this
file, and it should work. I will submit an ebuild later to address this.
Comment 7 Kevin DeKorte 2005-08-06 06:42:47 UTC
The ebuild is wrong. mplayerplug-in as of version 2.99 has had a library split
and you are not installing all of the libaries.

You used to be able to just install mplayerplug-in.so and mplayerplug-in.xpt in
the browser plugin directory. Now upto 5 .so and .xpt files are produced

mplayerplug-in.so - MPEG,FLI,OGG support
mplayerplug-in-wmp.so - Windows Media support (AVI, ASX etc)
mplayerplug-in-qt.so - QuickTime support
mplayerplug-in-rm.so - RealMedia support
mplayerplug-in-gmp.so - Google Media support (requires Firefox 1.5 because it's
javascript is better)

There are also the .xpt files as well. They are needed for javascript support. 

In 3.05 mplayerplug-in.type should only be used for mediatypes that are NOT
covered by the -wmp,-qt,-rm and -gmp libraries.

Pleas read in the install and configuration pages at http://mplayerplug-in.sf.net

Comment 8 Gergan Penkov 2005-08-06 06:53:52 UTC
The ebuild is for 3.01 and as I see the new librarie-split is as of 3.05 (it
worked for me for 3.01). I'll try and make an ebuild for 3.05, which links
against mozilla or firefox.
Comment 9 Gergan Penkov 2005-08-06 07:48:22 UTC
Created attachment 65238 [details]
mplayerplug-in-3.05.ebuild

This is the ebuild for 3.05, which builds against mozilla or mozilla-firefox
(uses the firefox-use flag), sets correctly the rpath/runpath (for dynamic
linking) and installs correctly all the .so and .xpt files, as well as
mplayerplug-in.types in /etc. Uses the same patch 
(mplayerplug-in-rpath.patch), as the mplayerplug-in-3.01.ebuild
Comment 10 Joe Jezak (RETIRED) gentoo-dev 2005-08-06 09:49:47 UTC
Sorry, I haven't been able to look at this until now.  The suggested changes
look okay to me, but I was going to drop gtk1 support since the mozilla and
firefox ebuilds no longer have gtk1 support.  Is there a good reason not to drop
gtk1 here too?
Comment 11 Gergan Penkov 2005-08-06 10:07:44 UTC
I don't know, if smb needs or uses gtk1, will want to build it with gtk1 support
(probably against gecko-sdk with gtk1 support).
But anyway if gtk1 will be or is already dropped from mozilla and
mozilla-firefox, it is obvious and logical to drop it from mplayerplug-in.
Comment 12 Gergan Penkov 2005-08-06 10:54:50 UTC
Created attachment 65248 [details]
mplayerplug-in-3.05.ebuild

I've noticed that the language files were not installed in the previous
versions of the ebuild , this version will resolve this and will install the
language files.
Comment 13 Joel Martin (RETIRED) gentoo-dev 2005-08-14 13:50:57 UTC
Created attachment 65967 [details]
ebuild for 3.05 without rpath, with gecko-sdk from mozilla

The rpath patch breaks the build for me. It can't find npapi.h which makes
sense because the patch doesn't have the base gecko sdk include directory
where the file lives. I'm not sure why the patch is munging configure at all 
actually.

Also, what about mozilla-bin and mozilla-firefox-bin users? My preference is to

still build against gecko-sdk on everything except x86, and on x86 pull down
the
prebuilt gecko-sdk from mozilla. Here is my proposed ebuild for this.
Comment 14 Gergan Penkov 2005-08-14 14:00:17 UTC
There is very simple answer to all this, it could break because... you have try
to install the ebuild against firefox and don't have the patched ebuilds for it
for example...
To why should one build against firefox you could look at the bug #100597...
Or try ldd on the installed libraries and you will understand that you have made
nothing else than building against the sdk (which needs min 30min) and after
that you have at run-time resolved to firefox or mozilla ::)) That could bring
only crashes and problems.
Comment 15 Joel Martin (RETIRED) gentoo-dev 2005-08-14 14:38:38 UTC
Not sure I followed that.

mozilla-firefox-bin-1.0.6-r2 (latest stable or unstable) does not have the
file npapi.h which is necessary to build mplayerplug-in. Requiring the non "bin"
version of mozilla is not the answer. Perhaps the "bin" versions should include
these headers, but otherwise I think it's still better to build mplayerplug-in
using gecko-sdk. 

On x86, the ebuild I proposed does NOT take 30 min to build gecko-sdk on x86
because it pulls the pre-built version from mozilla.org.

Also, I'm not sure what you mean by "after that you have at run-time resolved
to firefox or mozilla". From what I can tell, the plugins are linking to
/usr/lib/nspr, but I don't see any links to anything that is actually
part of a mozilla package.
Comment 16 Stefan Schweizer (RETIRED) gentoo-dev 2005-08-14 14:41:34 UTC
*** Bug 101594 has been marked as a duplicate of this bug. ***
Comment 17 Gergan Penkov 2005-08-14 14:48:21 UTC
I mean simply for example for libxpcom
 ldd /opt/netscape/plugins/mplayerplug-in*.so|grep libxpcom
        libxpcom.so => /usr/lib/mozilla-firefox/libxpcom.so (0xb7d2a000)
        libxpcom.so => /usr/lib/mozilla-firefox/libxpcom.so (0xb7d60000)
        libxpcom.so => /usr/lib/mozilla-firefox/libxpcom.so (0xb7d15000)
        libxpcom.so => /usr/lib/mozilla-firefox/libxpcom.so (0xb7d02000)
        libxpcom.so => /usr/lib/mozilla-firefox/libxpcom.so (0xb7d78000)
it is what is on my computer, it will be the same on your, if you have
mozilla-firefox installed. But on mine is with intention, because, I've compiled
it so ... 
readelf -d /opt/netscape/plugins/mplayerplug-in-rm.so

Dynamic section at offset 0x35014 contains 48 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libX11.so.6]
 0x00000001 (NEEDED)                     Shared library: [libSM.so.6]
 0x00000001 (NEEDED)                     Shared library: [libICE.so.6]
 0x00000001 (NEEDED)                     Shared library: [libXext.so.6]
 0x00000001 (NEEDED)                     Shared library: [libXpm.so.4]
 0x00000001 (NEEDED)                     Shared library: [libXt.so.6]
 0x00000001 (NEEDED)                     Shared library: [libxpcom.so]
 0x00000001 (NEEDED)                     Shared library: [libnspr4.so]
 0x00000001 (NEEDED)                     Shared library: [libplds4.so]
 0x00000001 (NEEDED)                     Shared library: [libgtk-x11-2.0.so.0]
 0x00000001 (NEEDED)                     Shared library: [libgdk-x11-2.0.so.0]
 0x00000001 (NEEDED)                     Shared library: [libatk-1.0.so.0]
 0x00000001 (NEEDED)                     Shared library: [libgdk_pixbuf-2.0.so.0]
 0x00000001 (NEEDED)                     Shared library: [libpangoxft-1.0.so.0]
 0x00000001 (NEEDED)                     Shared library: [libpangox-1.0.so.0]
 0x00000001 (NEEDED)                     Shared library: [libpangoft2-1.0.so.0]
 0x00000001 (NEEDED)                     Shared library: [libpango-1.0.so.0]
 0x00000001 (NEEDED)                     Shared library: [libgobject-2.0.so.0]
 0x00000001 (NEEDED)                     Shared library: [libgmodule-2.0.so.0]
 0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
 0x00000001 (NEEDED)                     Shared library: [libglib-2.0.so.0]
 0x00000001 (NEEDED)                     Shared library: [libgthread-2.0.so.0]
 0x00000001 (NEEDED)                     Shared library: [libstdc++.so.6]
 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
 0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000f (RPATH)                      Library rpath: [/usr/lib/mozilla-firefox]
 0x0000001d (RUNPATH)                    Library runpath: [/usr/lib/mozilla-firefox]
...
as you see the rpath tag used determines the resolution to mozilla-firefox
directory and i don't have any paths in ld.so.conf to mozilla or any
other-browsers and sdk-s
cat /etc/ld.so.conf
# ld.so.conf autogenerated by env-update; make all changes to
# contents of /etc/env.d directory
/usr/local/lib
/usr/lib/opengl/nvidia/lib
/usr/i686-pc-linux-gnu/lib
/usr/lib/gcc/i686-pc-linux-gnu/3.4.4
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5
/usr/lib
/usr/lib/lesstif-2.1
/usr/lib/openmotif-2.2
/opt/sun-jdk-1.4.2.08/jre/lib/i386/
/opt/sun-jdk-1.4.2.08/jre/lib/i386/native_threads/
/opt/sun-jdk-1.4.2.08/jre/lib/i386/classic/
/opt/sun-jdk-1.4.2.08/jre/lib/i386/server/
/usr/qt/3/lib
/usr/kde/3.4/lib
/usr/NX/lib
/usr/lib/speech-tools/lib
/usr/games/lib
/usr/lib/R/lib
/usr/lib/fltk-1.1
/usr/lib/libstdc++-v3/

So that's why it is needed the rpath-patch
Comment 18 Joel Martin (RETIRED) gentoo-dev 2005-08-14 15:00:51 UTC
Sure, I understand your point. But this 
needs to also work for the *-bin versions of mozilla-* too.

Just FYI:
# ls /opt/netscape/plugins/mplayerplug-in*.so
/opt/netscape/plugins/mplayerplug-in-gmp.so
/opt/netscape/plugins/mplayerplug-in-qt.so
/opt/netscape/plugins/mplayerplug-in-rm.so
/opt/netscape/plugins/mplayerplug-in-wmp.so
/opt/netscape/plugins/mplayerplug-in.so
# ldd /opt/netscape/plugins/mplayerplug-in*.so | grep libxpcom
#

The current rpath patch breaks for me because I only have mozilla-firefox-bin
which doesn't have headers needed to build mplayerplug-in. I don't have time
right now, but I will try and reproduce this problem later and figure out 
a patch that works for both the bin and non-bin versions.
Comment 19 Gergan Penkov 2005-08-14 15:07:49 UTC
I think that gentoo simply should supply own bin-packages for mozilla-builds,
there is no other way to assure quality and consistent linking. 
I'll try to post an upstream bug for this and the other things as Jory Pratt
commented on #100597 (where the needed ebuilds reside), but I'm not sure this
will bring sth. 
Comment 20 Nir Dremer 2005-08-15 09:57:46 UTC
works good for me... (together with mozilla-firefox (not -bin))
Comment 21 Gergan Penkov 2005-08-15 16:07:48 UTC
Created attachment 66030 [details]
mplayerplug-in-3.05.ebuild

Ok, the patch is not needed any more, it is a simple sed thing to make it build
against firefox (it will need the new mozilla or mozilla-firefox ebuilds, which
are already in portage but masked, to set the rpaths correctly and to find the
needed libraries).
Comment 22 Stefan Schweizer (RETIRED) gentoo-dev 2005-08-17 06:20:00 UTC
What about a detection if we have mozilla or firefox or gecko-sdk with
has_version? And if we don't have any of them use the binary gecko-sdk?

Anyway, can we get it into portage please?
Comment 23 Jory A. Pratt 2005-08-17 10:04:45 UTC
(In reply to comment #22)
> What about a detection if we have mozilla or firefox or gecko-sdk with
> has_version? And if we don't have any of them use the binary gecko-sdk?

Only problem here is you got binaries that do not include rpath support ... so
unless we determine weather it is binary install or source install building
against firefox or mozilla is still not appropriate ... also if binaries are
used the plugin has to build against gecko-sdk as it has always done.

Comment 24 Gergan Penkov 2005-08-17 14:49:38 UTC
Does the mozilla-bin and mozilla-firefox-bin make some difference to the
ebuilds, I mean could we recognize them somehow and if yes and they exist just
pull down the sdk.
Comment 25 Stefan Schweizer (RETIRED) gentoo-dev 2005-08-17 15:02:54 UTC
if has_version www-client/mozilla-firefox;
then 
  build against it

elif has_version www-client/mozilla;
then 
  build against it

elif has_version net-libs/gecko-sdk;
then
  build against it

elif use x86 && has_version net-libs/gecko-sdk-bin
then
  build against gecko-sdk-bin

else
  build against gecko-sdk
fi

is that possible? Here is the proposed DEPEND:

DEPEND=" !x86? ( 
   || (
  mozilla-firefox
  mozilla
  gecko-sdk
   ))
 x86? ( 
   || (
  mozilla-firefox
  mozilla
  gecko-sdk-bin
  gecko
   ))

maybe we should implement a virtual?
this way we avoid a useflag(firefox) that iss not really necessary as we can
detect the gecko-libs on compiletime.
Comment 26 Gergan Penkov 2005-08-17 15:31:04 UTC
I think it is ok. For source-built mozilla and mozilla-firefox you could use the
new configuration (if the versions are ok), else the old way of configuring it. 
I could not test it right now, I simply could not rebuild mozilla after that at
this moment (because of stupidity I've installed gnome-2.11, which pulled
cairo-0.9.2 and mozilla will not build against it):(
Comment 27 Gergan Penkov 2005-08-18 07:19:56 UTC
I thought about this last night::)) and there probably is a way out of this
situation, but it will be a big effort for the mozilla herd.
For now and I don't know if in the future it will be the same (and that is one
of the problems), all the compiled nss/nspr libraries in mozilla,
mozilla-firefox and gecko-sdk on my computer are the same (I didn't do a binary
diff but the sizes match) and the installed headers in mozilla and
mozilla-firefox are identical (I have made a diff and they match).
So the logical conclusion to this is make the binary installs to mimic the
source-ones - installing the headers (diff the include directory from our source
installs) and patching the pkg-config files or if they don't exist copying them.
I don't know if the binary installs have archive-objects in them (*.a), but I
don't think if they do it will be a good idea to link static against them,
because of different compiler versions for example (if I'm not correct pls
someone correct me). 
And the last part of are the non-existing rpath/runpath tags, which is somehow a
very hard problem (or probably impossible to solve), there are two programs,
which could help somehow - app-admin/chrpath (which could modify the
rpath/runpath tags but could not add new - does not help) and dev-util/elfsh
(which probably could do the adding and modifying of the tags), but I don't
thing that someone will be willing to install such a program on its computer,
because of mozilla, so probably a binary-diff could be some sort of soultion,
but is in its essence a hackish undertaking :( 
If there is only mozilla-bin or mozilla-firefox-bin alone, no nss/nspr or
gecko-sdk - the missing rpaths will not be a real problem (probably using
blockers for bin, source, nss, nspr and gecko-sdk versions could be a solution,
because the gtkembed and other libraries are different). 
To why mozilla have created such a mess with all its products - not using the
soname-tags and probably rpaths, which would have made these problems
non-existent, there is no logical answer - probably a simple obstinance.
So as I said it will be a big effort and as such probably not acceptable, but it
could bring some sort of resolution to all this problems.
Comment 28 Hanno Zysik (geki) 2005-08-27 09:11:43 UTC
to comment #26

patch for mozilla/firefox to build against >=cairo-0.5.0
https://bugs.gentoo.org/attachment.cgi?id=66137

the according bugreport
https://bugs.gentoo.org/show_bug.cgi?id=98828
Comment 29 Kevin DeKorte 2005-08-27 10:42:29 UTC
mplayerplug-in CVS as of 8/27/05 will check for the following pkg-config packages...

mozilla-plugin
firefox-plugin
seamonkey-plugin

And will use any of them as well as gecko-sdk to build against. Are there any
other packages that should be looked for?

Comment 30 Gergan Penkov 2005-08-27 10:54:06 UTC
This will make this bug partly obsolete ::)) Thanks. 
Could you add some sort of --enable-rpath in the configure-script to enable this
tag if used with gecko-sdk, because it does-not supply pkg-config files?
Comment 31 Kevin DeKorte 2005-08-27 16:22:51 UTC
If you can explain to me how it should work 

./configure --enable-rpath

Should --enable-rpath override --with-gecko-sdk or should they work together?

./configure --with-gecko-sdk=/path/to/gecko_sdk --enable-rpath

From what the patch looks like without --enable-rpath should give

MOZPLUG_CFLAGS="-I${GECKO_SDK_PREFIX} -I${GECKO_SDK_PREFIX}/include"
MOZPLUG_LIBS="-L ${GECKO_SDK_PREFIX}/lib -lxpcomglue -L ${GECKO_SDK_PREFIX}/bin
-lnspr4 -lplds4"

And with --enable-rpath should give:

MOZPLUG_CFLAGS="-I${GECKO_SDK_PREFIX}/include/nspr
-I${GECKO_SDK_PREFIX}/include/plugin -I${GECKO_SDK_PREFIX}/include/java
-I${GECKO_SDK_PREFIX}/include/xpcom"
MOZPLUG_LIBS="-L ${GECKO_SDK_PREFIX} -lxpcom -L ${GECKO_SDK_PREFIX} -lnspr4 -lplds4"

Am I correct?

If so I can do this, without much diffculty.
Comment 32 Gergan Penkov 2005-08-27 22:33:18 UTC
(In reply to comment #31)
> If you can explain to me how it should work 
> 
> ./configure --enable-rpath
> 
> Should --enable-rpath override --with-gecko-sdk or should they work together?
> 
> ./configure --with-gecko-sdk=/path/to/gecko_sdk --enable-rpath
> 
> From what the patch looks like without --enable-rpath should give
> 
> MOZPLUG_CFLAGS="-I${GECKO_SDK_PREFIX} -I${GECKO_SDK_PREFIX}/include"
> MOZPLUG_LIBS="-L ${GECKO_SDK_PREFIX}/lib -lxpcomglue -L ${GECKO_SDK_PREFIX}/bin
> -lnspr4 -lplds4"
> 
> And with --enable-rpath should give:
> 
> MOZPLUG_CFLAGS="-I${GECKO_SDK_PREFIX}/include/nspr
> -I${GECKO_SDK_PREFIX}/include/plugin -I${GECKO_SDK_PREFIX}/include/java
> -I${GECKO_SDK_PREFIX}/include/xpcom"
> MOZPLUG_LIBS="-L ${GECKO_SDK_PREFIX} -lxpcom -L ${GECKO_SDK_PREFIX} -lnspr4
-lplds4"
> 
> Am I correct?
> 
> If so I can do this, without much diffculty.
> 
I mean sth like 
+LDFLAGS += \
+	-Wl,-R${GECKO_SDK_PREFIX}/bin:${GECKO_SDK_PREFIX}/lib
if you use gecko-sdk, because in this way you could resolve to its libraries(if
they are properly patched) and not to firefox's set of libraries. In this way
the plugin should work even if you install a new firefox or mozilla. For more
information on all about this, you could look at #100597.
Comment 33 Kevin DeKorte 2005-08-28 07:23:17 UTC
Ok, I made a change which adds the option --enable-rpath to the ./configure
command. See the results of the two commands below, one without rpath and one
with rpath.

The command
./configure --with-gecko-sdk=/home/kdekorte/gecko-sdk1.7

gives this
LDFLAGS=     -L/usr/X11R6/lib  -lX11   -lSM -lICE -lXext -lX11 -lXpm -lXt -L
/home/kdekorte/gecko-sdk1.7/lib -lxpcomglue -L /home/kdekorte/gecko-sdk1.7/bin
-lnspr4 -lplds4 -Wl,--export-dynamic -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0
-lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0
-lgmodule-2.0 -ldl -lglib-2.0   -pthread -lgthread-2.0 -lglib-2.0


The command

./configure --with-gecko-sdk=/home/kdekorte/gecko-sdk1.7 --enable-rpath

Gives this

LDFLAGS=  -Wl,-R/home/kdekorte/gecko-sdk1.7/bin:/home/kdekorte/gecko-sdk1.7/lib
   -L/usr/X11R6/lib  -lX11   -lSM -lICE -lXext -lX11 -lXpm -lXt -L
/home/kdekorte/gecko-sdk1.7/lib -lxpcomglue -L /home/kdekorte/gecko-sdk1.7/bin
-lnspr4 -lplds4 -Wl,--export-dynamic -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0
-lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0
-lgmodule-2.0 -ldl -lglib-2.0   -pthread -lgthread-2.0 -lglib-2.0


Is that what you need? 

I'm really not sure why you need this for mplayerplug-in since it runs inside of
mozilla and uses the libs that mozilla has loaded. It seems that loading libs
from an alternate location could cause problems and perhaps crashes. If you have
a libxpcom from mozilla and a libxpcom from gecko-sdk (used by a plugin)

I will commit this, if this is what you need, I just don't see the benefit.
Comment 34 Gergan Penkov 2005-08-28 09:10:30 UTC
(In reply to comment #33)

> Is that what you need? 
Yes, thanks - but the devs, if they will use it ::)) 
> 
> I'm really not sure why you need this for mplayerplug-in since it runs inside of
> mozilla and uses the libs that mozilla has loaded. It seems that loading libs
> from an alternate location could cause problems and perhaps crashes. If you have
> a libxpcom from mozilla and a libxpcom from gecko-sdk (used by a plugin)
> 
> I will commit this, if this is what you need, I just don't see the benefit.

The problem most probably is that you have the following resolve-path first
mplayerplug-in resolves to libxpcom from gecko-sdk (because the rpath-tag), but
if the gecko-sdk is not rpath-patched and you have mozilla-directory in
ld.so.conf or you start it with the mozilla-script (which sets the
LD_LIBRARY_PATH), then the needed libraries in libxpcom will resolve to these in
the mozilla-directory, which will cause the breakage. Which is the same as
compiling against old mozilla and running against deeppark for example. Simply
there is no way to deterministicly set the way in which the libraries will
resolve, without setting this tag (which simply says, which directories should
be search first, overriding the standard path). I have had no problems with
mplayerplug-in-3.05, compiled against rpath patched gecko-sdk-1.7.x and running
in mozilla-1.7.10 and firefox-1.0.6.

And I should say thanks for the great plugin, it works awesome :)
Comment 35 Gergan Penkov 2005-08-28 09:36:24 UTC
I have tested mplayerplug-in now against firefox-cvs head, compiled in the
explained way against firefox-1.0.6 (in the same directory is now deeppark-alfa2
release - not the cvs-version, so in reallity linking against it at run-time). 
And I have run all the test on the test-page without problems.
Comment 36 Kevin DeKorte 2005-08-28 12:55:19 UTC
The --enable-rpath configure option has been committed to mplayerplug-in CVS.
Will be in release version after 3.05
Comment 37 Gergan Penkov 2005-08-30 09:00:59 UTC
I should appologize to Kevin DeKorte, because with the patch in bug #100597 for
the gecko-sdk, he really would have had the problems, which he described, I
simply forgot to update the patch there or moreover intentionally did not update
it there (but forgot about this), because I didn't like the idea of building sth
against gecko-sdk, if you have mozilla or mozilla-firefox for this.
I recognized this, when I compared the patch in bug #100597 with my patches, for
opening bug #104273 (which is the rpath patch for the gecko-sdk, as the
maintainer of gecko-sdk is Joe Jezak and not the mozilla herd), the one there
works and have worked for me ::)) 
Sorry
Comment 38 Bartek Kostrzewa 2005-09-12 00:39:12 UTC
Created attachment 68230 [details]
ebuild for mplayerplug-in 3.05 with variable media support

Since mplayerplug-in has been split into a number of plugins I think the ebuild
should reflect this. I never install the realmedia portion for instance because
there's RealPlayer for Linux and it does a better job of streaming RM than
mplayerplug-in. So here's my proposal for a new ebuild.
Comment 39 Joe Jezak (RETIRED) gentoo-dev 2005-09-12 12:06:55 UTC
Sorry everyone, I've just finished moving and haven't yet had time to look into
this.  I'll try and review what we've got and get a newer version in portage ASAP.
Comment 40 Gergan Penkov 2005-09-12 12:27:03 UTC
(In reply to comment #38)
> Created an attachment (id=68230) [edit]
> ebuild for mplayerplug-in 3.05 with variable media support
> 
> Since mplayerplug-in has been split into a number of plugins I think the ebuild
> should reflect this. I never install the realmedia portion for instance because
> there's RealPlayer for Linux and it does a better job of streaming RM than
> mplayerplug-in. So here's my proposal for a new ebuild.

this is interesting, but there are small problem with the ebuild:
you depend on:
	!firefox? ( >=www-client/mozilla-1.7.10 )
	firefox? ( >=www-client/mozilla-firefox-1.0.6 )
but after that, when you configure it you use:
myconf="${myconf} --with-gecko-sdk=/usr/$(get_libdir)/gecko-sdk"
which is there only, if you have gecko-sdk installed ::))
probably should wait for Kevin DeKorte to release the new version as he says:

>mplayerplug-in CVS as of 8/27/05 will check for the following pkg-config
>packages...
>
>mozilla-plugin
>firefox-plugin
>seamonkey-plugin

and so using direct the pkg-config files, or using the sed hack for now.
Comment 41 Kevin DeKorte 2005-09-12 16:33:06 UTC
3.10 is out now at 

http://prdownloads.sourceforge.net/mplayerplug-in/mplayerplug-in-3.10.tar.gz?download

It includes the ability to compile against firefox, mozilla or seamonkey as well
as gecko-sdk

Changelog against 3.05
https://sourceforge.net/project/shownotes.php?release_id=356093
Comment 42 Jakub Moc (RETIRED) gentoo-dev 2005-09-13 06:35:31 UTC
*** Bug 105795 has been marked as a duplicate of this bug. ***
Comment 43 Bartek Kostrzewa 2005-09-14 05:23:40 UTC
Created attachment 68453 [details]
ebuild for 3.10 with variable media support and optional use of gecko-sdk

this is for 3.10 added useflags for gtk1, gtk2 and the x toolkit, also included
is a flag for gecko-sdk (when it is not set mozilla or firefox are used
depending on useflag) but I haven't worked out how to remove dependencies on
firefox or mozilla when setting gecko-sdk... I guess.. if in doubt we could
just drop that and compile against firefox or mozilla only.

Also, rather than the if use etc.. mania in the old build I just replaced that
by use_enable!
Comment 44 Bartek Kostrzewa 2005-09-14 05:33:54 UTC
the --enable-gtk1 --enable-x etc.. features depend on what firefox or mozilla
were  built against.. would it be possible to extract that information somehow
and thus get rid of those use-flags? (since mplayerplug-in will not work with
--enable-x or --enable-gtk1 on a gtk2 firefox or mozilla)
Comment 45 Kevin DeKorte 2005-09-14 05:50:38 UTC
That is incorrect
--enable-x works on everything, but is very limited
--enable-gtk1 requires the browser to be compiled with gtk1
--enable-gtk2 required the browser to be compiled with gtk2

There is an --enable-rpath option too that was requested for Gentoo

Oh 3.11 of mplayerplug-in is out as well. Minor fix.
Comment 46 Gergan Penkov 2005-09-14 06:55:32 UTC
(In reply to comment #44)
> the --enable-gtk1 --enable-x etc.. features depend on what firefox or mozilla
> were  built against.. would it be possible to extract that information somehow
> and thus get rid of those use-flags? (since mplayerplug-in will not work with
> --enable-x or --enable-gtk1 on a gtk2 firefox or mozilla)

As Joe Jezak pointed he probably will be dropping gtk1 support, because mozilla
is always been built with gtk2 now. 
The other problem is that the ebuilds from bug #100597 are needed in this case
(which means 1.0.6-r6 and mozilla-1.7.11-r2, hard masked), because as far as I
remember, I had to patch the mozilla-nspr.pc and firefox-nspr.pc in order to
correct the library paths in them and without this the autoconfiguration will
not work correctly, moreover the versions prior to firefox-1.0.6-r6 do not
install the full nss/nspr-suite, so could not be used for building it. 
The other thing is the --enable-rpath, should not be used if there is no patched
gecko-sdk ( look here http://bugs.gentoo.org/show_bug.cgi?id=104273 ), as this
will lead to similiar problems to the ones, pointed by Kevin DeKorte in reply #33.
Comment 47 Bartek Kostrzewa 2005-09-14 07:47:22 UTC
(In reply to comment #45)
> That is incorrect
> --enable-x works on everything, but is very limited

well it crashes my firefox and mozilla.. with the same output as when
mplayerplug-in has been compiled against gtk1

> --enable-gtk1 requires the browser to be compiled with gtk1
> --enable-gtk2 required the browser to be compiled with gtk2
> 
Comment 48 Joel Martin (RETIRED) gentoo-dev 2005-09-15 07:39:09 UTC
My vote is NOT to have variable media support. There isn't really anything gained
by having them. They are tiny files and if you have mplayerplug-in you aren't 
interested in saving space. If you want to control whether they are active or not
you can do this from the config files which is the right place to do it.

If you HAVE to have variable media support, the logic should be reversed (i.e.
nowm) so that people who don't fudge with USE flags for every single package get
the correct defaults.

And just build with gtk2. The decision has already been made in mozilla land to
drop gtk1.
Comment 49 Lorenzo 2005-09-22 02:50:57 UTC
the USE flag "qt" for "quicktime support" is wrong: qt use flag already exist,
and  refers to kde graphic libraries!!!
Comment 50 Brad Laue (RETIRED) gentoo-dev 2005-09-22 18:11:40 UTC
I agree. The optional media support should be removed as it's spurious. The 
supported media formats should all be enabled, and it should be left to mplayer 
itself to decide what formats are supported.
Comment 51 Joe Jezak (RETIRED) gentoo-dev 2005-09-25 18:36:20 UTC
Created attachment 69243 [details]
3.11 ebuild

Here's what I'm thinking for the ebuild, I'd like to know if anyone has any
other suggestions?  I don't like disabling support for the optional media types
(difficult to keep straight with mplayer itself), but I would like to keep the
option open for building against gecko-sdk.
Comment 52 Gergan Penkov 2005-09-26 14:26:07 UTC
Hi, other than this typo,  works fine here (I've changed it to):
if use gecko-sdk; then
   einfo Configuring to build using gecko-sdk
   myconf="${myconf} --with-gecko-sdk=/usr/$(get_libdir)/gecko-sdk"
fi
Comment 53 Harm Geerts 2005-09-26 17:43:48 UTC
Created attachment 69303 [details, diff]
patch to let mplayerplug-in use the amd64 mplayer-bin package

For windows media support under amd64 mplayerplug-in should depend on and use
mplayer-bin.
Comment 54 Joe Jezak (RETIRED) gentoo-dev 2005-09-29 00:10:05 UTC
Gergan: Thanks, that was an oversight on my part.

Harm: Not all AMD64 users will want that though I guess.  I'm going to add it
without that patch for now, but could you make a seperate bug for that? Perhaps
it might be better to make the mplayer binary name configurable instead of just
hardcoding a value?

The 3.11 ebuild has been added to portage, thanks everyone for the testing and
ebuild writing. :)