mirror of
https://github.com/brl/mutter.git
synced 2024-11-22 08:00:42 -05:00
Make plugin loading failure fatal
If a plugin was explicitly specified, falling back to the default silently is bad; a manager component like gnome-session can do a better job of handling this scenario. An example we've hit in gnome-shell is where SpiderMonkey changes without gjs being rebuilt, and loading the plugin fails due to unresolved symbols. But there are obviously others, like the file being missing or corrupt. https://bugzilla.gnome.org/show_bug.cgi?id=641384
This commit is contained in:
parent
5822443b20
commit
1133a4ff9c
@ -31,6 +31,7 @@
|
||||
#include "../core/window-private.h"
|
||||
|
||||
#include <string.h>
|
||||
#include <stdlib.h>
|
||||
|
||||
#include <clutter/x11/clutter-x11.h>
|
||||
|
||||
@ -281,8 +282,15 @@ meta_plugin_manager_load (MetaPluginManager *plugin_mgr)
|
||||
}
|
||||
}
|
||||
else
|
||||
g_warning ("Unable to load plugin module [%s]: %s",
|
||||
path, g_module_error());
|
||||
{
|
||||
/* This is fatal under the assumption that a monitoring
|
||||
* process like gnome-session will take over and handle
|
||||
* our untimely exit.
|
||||
*/
|
||||
g_printerr ("Unable to load plugin module [%s]: %s",
|
||||
path, g_module_error());
|
||||
exit (1);
|
||||
}
|
||||
|
||||
g_free (path);
|
||||
g_free (plugin_string);
|
||||
|
Loading…
Reference in New Issue
Block a user