Change:
After the recent update of nixos-23.05 from to (which included , updating Firefox from 119.0.1 to 120.0) Firefox started crashing, apparently when WebGL gets used. Steps to reproduce the behavior: 120.0 with a clean profile. a crash. Some crash reports: https://crash- https://crash- These crash reports point to , which shows a matching backtrace: The underlying problem might be somewhat different though, because the offending option is not present in any Hydra build logs ( is present though). system: host os: multi-user?: sandbox: version: nixpkgs:
You can disable WebGL temporarily while the bug is being fixed. about:config webgl.disabled set to true
also works without crashing even with WebGL enabled.
Hydra build log: This is the same root cause as described in (originally for Ubuntu Firefox Beta PPA for 18.04 LTS). This is caused by building in such a way that and (and ) embed and export their own version of the code from libstdc++ (in particular ) instead of using dynamic linking to call into the code that is exported by . It is unsafe to do that because of the flag that is used to compile these binaries, and starting with Firefox 120 that results in a WebGL crash. For the Ubuntu Firefox Beta PPA this was caused by compiling with but we do not understand why this situation occurs for the NixOS 23.05 build at the moment. But it does occur (see screenshot below). <img width="399" alt="Commands showing that indeed firefox, and all export std::locale::Sinitialize with this build" src=""If someone knows how to ensure that and (and ) do not embed and export code for , that should fix the crash (we should not see a for when using on these binaries, in fact we should not see it at all because this function is internal to the implementation).
Also apparently the problem is specific to the branch:
Comparing the “good” build log () with the “bad” one () shows the difference in clang versions (and the extra option for the build, which uses clang-15): And the difference is indeed in the compiler behavior. Using the test file from the Mozilla bug report: With the new compiler from : With the old compiler from : Apparently the important difference here is that the compiler from passes the option to , and the directory contains , therefore the linker uses the definitions from the shared library as intended. However, the compiler from passes the option, which refers to a nonexistent directory ( actually exists, and there is the symlink, but these directories are not mentioned in the parameters), therefore the linker does not see and uses only from , so the resulting shared library contains copies of all libstdc++ functions, which breaks things when is also specified. So apparently the real problem is that in the branch uses wrong library paths for the GCC libraries.
I'm currently building with the following patch, thanks to trofi. This approach fails, as it overrwrites all previously accumulated flags. This was apparently fixed on master in
This will most likely be resolved through , but I'm still testing a solution that would be more localized to firefox and thus arrive quicker.
The workaround is part of the latest release-23.05 evaluation. You can follow its progress here:

Discussion:
LDFLAGS = "-Wl,-rpath,${placeholder "out"}/lib/${binaryName}"; }; <ins> # workaround for clang statically linking against libstdc++ NIX_LDFLAGS = lib.optionals stdenv.cc.isGNU [ "-L${stdenv.cc.cc.lib}/lib" ]; </ins> # tests were disabled in configureFlags doCheck = false;