mirror of
https://gitlab.winehq.org/wine/wine-gecko.git
synced 2024-09-13 09:24:08 -07:00
5cb6216446
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 |
||
|---|---|---|
| .. | ||
| app | ||
| chromium | ||
| contentproc | ||
| dbus | ||
| glue | ||
| hal | ||
| ipdl | ||
| keystore | ||
| netd | ||
| nfc | ||
| ril | ||
| testshell | ||
| unixfd | ||
| unixsocket | ||
| moz.build | ||
| pull-chromium.py | ||