dlopen() gconf library in mozgnome component

RESOLVED FIXED in mozilla12

Status

()

defect
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: chrisccoulson, Assigned: chrisccoulson)

Tracking

Trunk
mozilla12
x86_64
Linux
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

So that GIO / GSettings support works on systems without gconf installed, we need to drop the hard runtime requirement on gconf from the mozgnome component
Blocks: 713802
Assignee: nobody → chrisccoulson
Blocks: 563628
Blocks: 547800
All of the external libraries in libmozgnome should be dynamically opened. gnome-vfs is as much a problem. I currently build my own libmozgnome so I can have GIO support in Nightly without having gnome-vfs installed.

I had originally suggested that libmozgnome be split up into its constituent components (bug 547800), since all of the implementations are independent of each other. But since the current strategy seems to be the opposite, putting everything into a single library, dynamically loading all of these external libraries seems to make more sense.
(In reply to Matthew Turnbull [Bluefang] from comment #1)
> All of the external libraries in libmozgnome should be dynamically opened.
> gnome-vfs is as much a problem. I currently build my own libmozgnome so I
> can have GIO support in Nightly without having gnome-vfs installed.
> 

gnomevfs support is being turned off (see bug 713802), so it's unlikely we'll spend time fixing that.
This seems to do the trick here
Attachment #584825 - Flags: review?(karlt)
Comment on attachment 584825 [details] [diff] [review]
dlopen() gconf library in mozgnome component

> nsGConfService::~nsGConfService()
> {
>+  if (gconfLib) {
>+    PR_UnloadLibrary(gconfLib);
>+    gconfLib = nsnull;
>+  }
>+
>   if (mClient)
>     g_object_unref(mClient);

My experience with GConf is that we can't close the library (bug 408122 comment 13).

Please instead leave a comment, after g_object_unref(mClient), to say that gconfLib is not closed because libORBit-2 uses atexit().
Attachment #584825 - Flags: review?(karlt) → review+
Yes, you're right there. I should have known that, seeing as I've previously investigated other application crashes because of that same problem :)

And it's not only that - unloading any GObject based library will normally result in a crash, as the types that are registered in gobject's dynamic type system aren't removed.
Here's the same patch but without unloading the library, and a comment explaining why
Attachment #584981 - Flags: review?(karlt)
Comment on attachment 584981 [details] [diff] [review]
dlopen() gconf library in mozgnome component (v2)

The unload in Init() was probably fine because I assume no GConf code would have been run at that stage, but I don't mind exactly what we do there as that is not a path we expect to hit.
Attachment #584981 - Flags: review?(karlt) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/04244dc1f498
Flags: in-testsuite-
Target Milestone: --- → mozilla12
https://hg.mozilla.org/mozilla-central/rev/04244dc1f498
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Blocks: 821291
You need to log in before you can comment on or make changes to this bug.