| Summary: | net-www/mplayerplug-in-3.05, linking against mozilla/mozilla-firefox and the rpath patch | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Gergan Penkov <gpp666_999> |
| Component: | New packages | Assignee: | Joe Jezak (RETIRED) <josejx> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | brad, daryl.ball, frp.bissey, genstef, h.mth, jesse, kanaka, kdekorte, lars, mozilla, phil, rmay31, rossi.f |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 100597 | ||
| Bug Blocks: | 93546, 101543 | ||
| Attachments: |
mplayerplugin-in-rpath.patch
mplayerplug-in-3.01.ebuild mplayerplug-in-rpath.patch mplayerplug-in-3.05.ebuild mplayerplug-in-3.05.ebuild ebuild for 3.05 without rpath, with gecko-sdk from mozilla mplayerplug-in-3.05.ebuild ebuild for mplayerplug-in 3.05 with variable media support ebuild for 3.10 with variable media support and optional use of gecko-sdk 3.11 ebuild patch to let mplayerplug-in use the amd64 mplayer-bin package |
||
|
Description
Gergan Penkov
2005-07-30 06:05:08 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.
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. 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.
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.
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? 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. 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 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. 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
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? 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. 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.
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.
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. 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. *** Bug 101594 has been marked as a duplicate of this bug. *** 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
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. 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. works good for me... (together with mozilla-firefox (not -bin)) 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).
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? (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. 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. 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. 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):( 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. 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 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? 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? 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.
(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. 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. (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 :) 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. The --enable-rpath configure option has been committed to mplayerplug-in CVS. Will be in release version after 3.05 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 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.
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. (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. 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 *** Bug 105795 has been marked as a duplicate of this bug. *** 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!
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) 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. (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. (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 > 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. the USE flag "qt" for "quicktime support" is wrong: qt use flag already exist, and refers to kde graphic libraries!!! 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. 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.
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
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.
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. :) |
