082ed38 introduced it to fix the profile-per-install policy of FF 67. But since
FF 69 (or 68?), there is `MOZ_LEGACY_PROFILES`, which we use since 87e2618.
There is no reason for the `SNAP_NAME=firefox` workaround anymore.
Additionally, the combination of `SNAP_NAME=firefox` with
a large ~/.nix-profile/share in `XDG_DATA_DIRS` triggered
https://bugzilla.mozilla.org/show_bug.cgi?id=1569625 for me, so this really
fixes a bug in my configuration.
The only downside of this approach is that we lose support for running FF 67
(and possibly 68).
When firefox is executed by programs that also make changes to
`LD_LIBRARY_PATH`, the paths can conflict causing firefox to look for
shared libraries in the wrong location. This is because the wrapper
script around firefox *appends* library paths to `LD_LIBRARY_PATH`
instead of prepending them, causing library paths that are already in
the environment to take precedence over the library paths that firefox
depends on.
As an example, Discord and firefox both depend on different versions of
libnss. When Discord launches firefox, which happens when clicking on
hyperlinks, the path in `LD_LIBRARY_PATH` to libnss set by Discord takes
precedence over then one set by the firefox wrapper script causing
firefox to load a different version of libnss than the one it was built
against. This causes a fatal error in firefox which prevents it from
starting.
This commit fixes this issue by switching the firefox wrapper script to
*prepend* its library paths to `LD_LIBRARY_PATH`.
Fixes#118432
/cc original PR #114152. ESR doesn't need to go through staging.
I briefly ran it on X11 x86_64 NixOS and checked build on aarch64.
(for other's testing see the PR linked above)
Enable LTO support on Linux by default again.
Add patch to fix dependentlibs.list generation under LTO. This is
necessary for fixing firefox-wayland crashing when built with LTO.
Add makeFlags which set ar, ranlib, and nm to be llvm-ar, llvm-ranlib
and llvm-nm when building with llvm-based LTO. (bmo#1480005)
This was required to solve the XPCOMGlueLoad error when building with
LTO. However, it turns out libxul.so is supposed to have some libraries
that are reported as not found by ldd. Setting the RPATH worked around
the error as it forced dependency resolution but failed to fix the real
issue of broken generation of dependentlibs.list.
The libraries that are reported as not found by ldd are supposed to be
dlopened through the logic found in nsXPCOMGlue.cpp. However since the
generation of dependentlibs.list is broken under LTO this did not
happen. Instead of pulling libwayland-client.so from the GTK libraries
it found the stub library first (libmozwayland.so). The stub library
causes (as it should) wl_display_connect to always return NULL which is
the cause of the segmentation fault and LTO breaking wayland support.
Remove the hardcoded path used for the XPCOMGlueLoad error workaround
in NIX_LDFLAGS. libunwind is still unfortunately needed. Once the issue
of the generation of dependentlibs.list being borked is fixed it should
remedy the wayland crash issue on LTO.
Firefox has a number of optional dependencies that get dlopened.
Instead of using patchelf to set the RPATH use LD_LIBRARY_PATH.
The motivation for this is we already set LD_LIBRARY_PATH in the
wrapper on Linux.
