Closed Bug 454025 Opened 13 years ago Closed 13 years ago

Extension functions fail because libgkplugin.so does not get installed

Categories

(Thunderbird :: Build Config, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: connor.behan, Assigned: connor.behan)

Details

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072612 GranParadiso/3.0.1
Build Identifier: trunk

It looks like libgkplugin.so was deliberately omitted from "make install" but this should not be the case. The extensions dialog fails to render, extensions fail to install and the error console gives an error for not recognizing "Components.classes" at line 844 of extensions.js. These go away when libgkplugin.so is installed. Omitting gkplugin.dll on Windows may or may not cause the same problems, I haven't tested that.

Reproducible: Always

Steps to Reproduce:
1.Build thunderbird from comm-central and install it with make install
2.Go to Addons or Error Console to notice a bunch of extension related errors
3.
Actual Results:  
Components.classes was not found in extensions.js:844 and extensions failed to install or show up in the Addons dialog.

Expected Results:  
Installing and querying extensions should have worked and exensions.js should not have had issues.
Attached patch Tentative fix (obsolete) — Splinter Review
Attachment #337249 - Flags: review?(bienvenu)
Status: UNCONFIRMED → NEW
Ever confirmed: true
it's odd that we have both libgkplugin.so and gkplugin.dll - cc'ing Mark in case he has any insight...
(In reply to comment #2)
> it's odd that we have both libgkplugin.so and gkplugin.dll - cc'ing Mark in
> case he has any insight...

I've done some investigation and found in cvs the following comment by Scott for when those files were added to the removed files list:

"fix some crashers because we don't support plugins by default"

No bug referenced though.

After a bit more thought, I'm guessing Connor has tried this on a non-static build - an investigation of my mac builds, reveals that only non-static builds have a separate libgkplugin.dylib (the mac equivalent).

So for static builds, we've actually been including it for ever, and this explains why it isn't in our windows packages file.

Therefore I think there's no point in *gkplugin* being listed in the NO_PKG_FILES section of our mail/installer/Makefile.in as its just confusing, and doesn't benefit us in any way.
Attached patch FixSplinter Review
Removes both gkplugin files.
Attachment #337249 - Attachment is obsolete: true
Attachment #337249 - Flags: review?(bienvenu)
Attachment #337338 - Flags: review?(bugzilla)
Connor, just for my confidence, please could you confirm if you were trying make install on a non-static build?
Yes. To even run make install on a non-static build I had to change other parts (bug 453920) but that's better than a static build on my system. For some reason static builds of mozilla programs always segfault for me... no idea why.
Comment on attachment 337338 [details] [diff] [review]
Fix

ok, I'm willing to take this. r=me, I'll check this in in a moment.
Attachment #337338 - Flags: review?(bugzilla) → review+
Checked in, changeset id: 293:4a8d961d55d0
Assignee: nobody → connor.behan
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.