GNOME Bugzilla – Bug 458324
Browser plugin does not build with xulrunner/firefox 1.9 alpha 6
Last modified: 2008-05-30 17:45:30 UTC
The browser plugin does not build with xulrunner/firefox 1.9 alpha 6. I'm going to attach a patch.
Created attachment 91991 [details] [review] Add -fshort-wchar and -lxpcom The -fshort-wchar is taken from epiphany gecko.m4, with alpha 6 it's necessary for nsStringAPI.h to compile. Also when linking to libxpcomglue_s you also need to link to xpcom. See: http://developer.mozilla.org/en/docs/XPCOM_Glue This adds more mess to the messy mozilla configuration... maybe totem should move to use gecko.m4.
We don't link to libxpcom on purpose (bug 354490)... shouldn't it be enough that the browser binary links xpcom? That works here... The -fshort-wchar part of the patch is fine.
Christian, I don't know exactly why... but that's not enough here, I get missing symbols.
To clarify. Without -lxpcom the plugin seem to be loaded fine (by looking at about:plugins). Though it dies for missing symbols in lib-totem-base-plugin.so when you actually try to open an ogg.
Did you build Totem against that specific version of Firefox, or was it built against a different version?
Same version of xulrunner. (1.9 pre6)
It works here in epiphany with only the -fshort-wchar fix. I compile xulrunner with --disable-libxul, could that make a difference ? And epiphany links explicitly to libxpcom itself too... I guess I'm ok with linking the plugin to libxpcom in the xulrunner case; can you adapt the configure to only do that for gecko==xulrunner ?
Marking patch as needs-work as per comment #7.
Marco, could you rework the patch before 2.20?
There has been changes on xulrunner head which obsolete my patch. I'll attach a new one at some point this week.
Created attachment 98260 [details] [review] Hacks to get it working with latest xulrunner I'm attaching this just for the record. I don't have the time do integrate it properly right now (and my head hurts at the idea of integrating yet another very different configuration inside the current code). If someone beats me at fixing this properly than great, otherwise I'll get at it, at some point :/
IMO, we should just drop support for non-xulrunner geckos as soon as 1.9 is released.
Marking patch #2 as needs-work as per comment #11.
xulrunner-devel-1.9-0.beta1.1.fc9 has an xpcom pkgconfig file, and I've already done the necessary changes to trunk to build with xulrunner. Totem in F9/rawhide already builds against it (although the package has other bugs there). Leaving on NEEDINFO until Marco has a chance to check it.
The -xpcom.pc file is a fedora addition, not available from upstream.
Chris, are the additional pkgconfig files in Fedora going upstream, or will they stay Fedora only?
Created attachment 102583 [details] [review] totem-xul.patch Patch for exclusive xulrunner usage. I'll commit that patch when xulrunner is considered stable. In the meanwhile, I'll be using that patch in packages. The configure.in is bad enough looking.
Comment on attachment 102583 [details] [review] totem-xul.patch >Index: configure.in >@@ -627,8 +589,7 @@ > # separate vars > if test "$enable_browser_plugins" = "yes" ; then > PKG_CHECK_MODULES([MOZILLA_NOT_LINKED], >- [$MOZILLA-xpcom >= $MOZILLA_VERSION_MIN \ >- $MOZILLA-plugin],, >+ [libxul >= 1.8],, There really isn't a libxul 1.8 from upstream. You want 1.9. >@@ -675,24 +636,28 @@ > > # Sets some variables, and check for xpidl > if test "$enable_browser_plugins" = "yes" ; then >- MOZILLA_PREFIX="`$PKG_CONFIG $MOZILLA-xpcom --variable=prefix`" >- MOZILLA_LIBDIR="`$PKG_CONFIG $MOZILLA-xpcom --variable=libdir`" >- MOZILLA_INCLUDE_ROOT="`$PKG_CONFIG --variable=includedir $MOZILLA-xpcom`" >- MOZILLA_XPCOM_CFLAGS="-I`$PKG_CONFIG --variable=includedir $MOZILLA-xpcom`" >+ LIBXUL_SDK_DIR=`$PKG_CONFIG --variable=sdkdir libxul` >+ MOZILLA_PREFIX="`$PKG_CONFIG libxul --variable=prefix`" >+ MOZILLA_LIBDIR="`$PKG_CONFIG libxul --variable=libdir`" >+ MOZILLA_INCLUDE_ROOT="`$PKG_CONFIG --variable=includedir libxul`" >+ MOZILLA_XPCOM_CFLAGS="`$PKG_CONFIG --cflags --define-variable=includetype=unstable libxul`" This can simply use the new libxul-unstable.pc file which should have just got added to trunk a few days ago. https://bugzilla.mozilla.org/show_bug.cgi?id=408062
Created attachment 102596 [details] [review] totem-xul-2.patch Updated patch, following Christian's comments
(In reply to comment #19) <snip> > Updated patch, following Christian's comments Make that Christopher's comments :)
Created attachment 102815 [details] [review] totem-xul-3.patch Updated again, few fixes.
Since this patch is designed to only work with gecko 1.9 and up, one other thing you may wish to do is replace usage of NS_REINTERPRET_CAST and NS_STATIC_CAST throughout the totem codebase, with the respective C++ casts. That macro is dead now. No big deal though ;-)
Created attachment 103151 [details] [review] totem-xul-4.patch And link against libxpcom otherwise it fails building on x86-64. See: http://koji.fedoraproject.org/koji/getfile?taskID=347419&name=build.log
I'm confused about the touch to totemGMPPlugin.cpp in totem-xul-4.patch as it causes totem to want to play adobe flash objects on many sites. I also had to make a change to MOZILLA_PLUGINDIR= for it to install to ${libdir}/xulrunner-addons/plugins instead of mozilla/plugins. I'm not sure what the folder is supposed to be upstream or if there is some symlinking going on. Your patch is much appreciated!
The change to totemGMPPlugin.cpp is not related to this patch, and bogus.
(In reply to comment #24) > I'm confused about the touch to totemGMPPlugin.cpp in totem-xul-4.patch as it > causes totem to want to play adobe flash objects on many sites. I fail to remember for which website I wrote that patch, but it has nothing to do here. > I also had to make a change to MOZILLA_PLUGINDIR= for it to install to > ${libdir}/xulrunner-addons/plugins instead of mozilla/plugins. I'm not sure > what the folder is supposed to be upstream or if there is some symlinking going > on. %{libdir/mozilla/plugins seems to work here, I'm not sure what the upstream is either.
I just upgraded to Ubuntu Hardy and had to apply a patch from their totem package. Hardy does not seem to have any firefox3 dev packages (only dummies) so it has to link against xulrunner-dev, which does not contain any xpcom pc file.
Created attachment 107734 [details] [review] Ubuntu Hardy Patch For reference, here is the patch from Ubuntu Hardy.
The patch in Ubuntu is far from sufficient.
Well, it build just fine but I did not test the plugins after that. Just browsed the apple trailer page, the totem player controls show up but the movies never play...
Something weird is going on. I tried applying this patch to SVN head, but it fails to merge saying it looks like the patch is already merged. Yet when you try building it complains about not finding gecko. Build the version shipped with FC9 works fine, but there I get in trouble due to totem-pl-parser API change.
Created attachment 110647 [details] [review] totem-xul-5.patch One that applies cleanly to trunk
Totem doesn't use Mozilla specific APIs anymore.