レナート   Wunschkonzert, Ponyhof und Abenteuerspielplatz   ﻟﻴﻨﺎﺭﺕ

Posted by Christian Hergert at Mon Aug 10 23:23:05 2009
Thanks for the pointer.  Do you think it would make sense to add these to the cflags for gobject-2.0?  Or is there a time where you wouldn't want this?

Now if only we had some good xplat macro's for key creation that worked on all the platforms.  For example, i want something as simple as __thread but works on more than gnu/linux.

Posted by Lennart at Mon Aug 10 23:35:03 2009
Christian, -z nodelete is a linker flag, which means you cannot put it in the .pc file.

Not sure if there is a good reason not to use it for any gobject-based library.

Posted by James Henstridge at Tue Aug 11 00:22:54 2009
If the library only implements dynamic GTypes, then there it should be fine to unload it though, right?

Posted by Andrés G. Aragoneses at Tue Aug 11 00:46:25 2009
Mmmm, I wish I could have Gendarme for C code, to detect this kind of problems automatically.

Posted by Tim Janik at Tue Aug 11 18:25:35 2009
GType does actually allow dynamic types to be unloaded. That's because it doesn't keep any (function) pointers to dynamic type implementations around. Instead, dynamic type implementations are reloaded if a once loaded&unloaded type implementation is used again (and the pointers are then reregistered). Functions like g_quark_from_static_string(), atexit(), etc shouldn't be used in dynamic plugins though, as they keep pointers into unloadable code around instead of duplicating memory.

Posted by Mart Raudsepp at Tue Aug 11 19:13:09 2009
pkg-config .pc files allow to specify linker flags just fine through Libs, for example mozilla uses it quite a bit. E.g:

Libs: -Wl,-z,nodelete -L${libdir} -lgobject-2.0

That said, I hope people won't be adding it to their projects without reading the comments here, and just avoid the kind of functions Tim mentioned in unloadable modules :)

Posted by Benjamin Otte at Wed Aug 12 04:40:24 2009
Unloadable modules in glib are a PITA because of their very strict ABI requirements. Otherwise you run into phantom bugs when this happens:
- plugin gets loaded and initializes types
- plugin gets unloaded after a while
- package upgrade installs new version of plugin
- plugin gets loaded again
Suddenly your type hierarchy must be identical and things like that.
And then there's of course the huge chunk of APIs that must not be used from inside a plugin that people conveniently forget about.

Also, Mozilla users get (got?) bitten by the unloading "feature" quite a bit when their browser crashed while the package manager was upgrading in the background and had replaced half of the plugins when they were loaded again.

Fun times...