After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 354490 - Difference in libxpcom can cause undefined symbols errors
Difference in libxpcom can cause undefined symbols errors
Status: RESOLVED NOTGNOME
Product: totem
Classification: Core
Component: Browser plugin (obsolete)
1.5.x
Other Linux
: Normal major
: ---
Assigned To: totem-browser-maint
totem-browser-maint
: 358668 360149 453354 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-09-05 18:07 UTC by Bastien Nocera
Modified: 2007-07-03 13:06 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16



Description Bastien Nocera 2006-09-05 18:07:40 UTC
+++ This bug was initially created as a clone of Bug #351266 +++

What a huge pile of crappety-crap.


If I use the plugin in Firefox, but compile it against Mozilla, I get the
useful:
/usr/lib/firefox-1.5.0.6/firefox-bin: symbol lookup error:
/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so: undefined symbol:
_ZN8nsMemory5AllocEj
when using any Javascript functions.

We might just need to link against all the necessary libraries (those given by
the CFLAGS), and install only in the subdir for the version we compiled
against.
That sucks, but I think that's the only way to get it to work properly.
Comment 1 Bastien Nocera 2006-09-05 18:10:04 UTC
Firefox 1.5.x, and Mozilla 1.7.13 have different symbols for nsMemory::Alloc, used in totemScriptablePlugin::GetInterfaces.

00000320 <_ZN21totemScriptablePlugin13GetInterfacesEPjPPP4nsID>:
 320:   55                      push   %ebp
 321:   89 e5                   mov    %esp,%ebp
 323:   56                      push   %esi
 324:   53                      push   %ebx
 325:   83 ec 10                sub    $0x10,%esp
 328:   8b 75 10                mov    0x10(%ebp),%esi
 32b:   c7 04 24 10 00 00 00    movl   $0x10,(%esp)
 332:   e8 fc ff ff ff          call   333 <_ZN21totemScriptablePlugin13GetInterfacesEPjPPP4nsID+0x13>
                        333: R_386_PC32 _ZN8nsMemory5AllocEj
Comment 2 Christian Fredrik Kalager Schaller 2006-09-28 09:52:31 UTC
I can confirm this problem. Firefox was crashing for me whenever I tried to change the sound volume for instance. Giving me:
/usr/lib/firefox-1.5.0.7/firefox-bin: symbol lookup error: /usr/lib/mozilla/plugins/libtotem-gmp-plugin.so: undefined symbol: _ZN8nsMemory5AllocEj

Using Mozilla it works fine.
Comment 3 Christian Persch 2006-09-28 13:46:58 UTC
So, we should use only frozen exports. That means NS_Alloc/NS_Free instead of nsMemory::*, which means dropping support for gecko 1.7.
And to solve the string API problem, we should link the plugin against libxpcomglue.a (or maybe libxpcomglue_s.a). The problem is that afaik no distribution's firefox-dev or xulrunner-dev package ships these static libraries...
Comment 4 Loïc Minier 2006-09-28 14:50:24 UTC
Indeed, only the shared /usr/lib/libxpcomglue.so is provided by these.  However, ISTR that xpcomglue is the way upstream recommends so perhaps we should require these libs in the firefox/xulrunner dev packages.
Comment 5 Bastien Nocera 2006-10-01 22:28:13 UTC
*** Bug 358668 has been marked as a duplicate of this bug. ***
Comment 6 Christian Persch 2006-10-07 11:06:29 UTC
*** Bug 360149 has been marked as a duplicate of this bug. ***
Comment 7 Christian Persch 2006-11-16 19:40:11 UTC
We now link libxpcomglue_s if it's present, but that still depends on getting the frozen exports from libxpcom.
Comment 8 Bastien Nocera 2006-12-15 16:51:30 UTC
I'll close this as NOTGNOME, and distributions will hopefully all use the same flavour of Mozilla as a base for Gecko browsers.
Comment 9 Bastien Nocera 2007-07-03 13:06:15 UTC
*** Bug 453354 has been marked as a duplicate of this bug. ***