713827 - dlopen() gconf library in mozgnome component

Status: RESOLVED FIXED

(Toolkit :: General, defect)

Description

[Chris Coulson]

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

Comment 1

[Matthew Turnbull [Bluefang]]

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.

Comment 2

[Chris Coulson]

(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.

Comment 3

[Chris Coulson]

Attachment: dlopen() gconf library in mozgnome component

This seems to do the trick here

Comment 4

[Karl Tomlinson (:karlt back Feb 10)]

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().

Comment 5

[Chris Coulson]

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.

Comment 6

[Chris Coulson]

Attachment: dlopen() gconf library in mozgnome component (v2)

Here's the same patch but without unloading the library, and a comment explaining why

Comment 7

[Karl Tomlinson (:karlt back Feb 10)]

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.

Comment 8

[Karl Tomlinson (:karlt back Feb 10)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/04244dc1f498

Comment 9

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/04244dc1f498