Mike Hommey 6a956c6f97 Bug 1187533 - Change how Gtk+2 plugin-container is started on Gtk+3 builds. r=billm ... The current situation looks like this: Firefox launches the plugin-container with two environment variables set: LD_LIBRARY_PATH=$FIREFOX_DIR:$LD_LIBRARY_PATH LD_PRELOAD=$FIREFOX_DIR/libmozgtk2.so:$LD_PRELOAD libxul.so has a dependency on libmozgtk.so (without "2"), but libmozgtk2.so has a SONAME of libmozgtk.so, so ld.so recognizes libmozgtk2.so as a dependency of libxul.so, and uses it instead of the actual libmozgtk.so, making the plugin-container use Gtk+2 instead of Gtk+3 to load Gtk+2 plugins. Now, ASan sets things up in shared libraries such that they needs a symbol from the executable binary. So in the case of plugin-container, the plugin-container executable itself contains some ASan symbols such as __asan_init_v3. libmozgtk2.so, OTOH, contains an undefined weak reference to that symbol, like all other Firefox shared libraries. Since libmozgtk2.so is LD_PRELOADed, it is loaded _before_ the plugin-container executable, and __asan_init_v3 can't be resolved. Disabling ASan for libmozgtk2.so would be a possibility, but the build system doesn't really know how to do that, and filtering out -fsanitize=address can be fragile. The alternative possibility, implemented here, is to change the library loading strategy, renaming libmozgtk2.so to gtk2/libmozgtk.so, and setting the following environment variable when Firefox launches the plugin-container: LD_LIBRARY_PATH=$FIREFOX_DIR/gtk2:$FIREFOX_DIR:$LD_LIBRARY_PATH		2015-07-28 08:19:13 +09:00
..
moz.build	Bug 1187533 - Change how Gtk+2 plugin-container is started on Gtk+3 builds. r=billm	2015-07-28 08:19:13 +09:00