make gtk3Support non-optional, because it hasn't been for a long time
also make gtk2 conditional on firefox older than 90, because we can get
rid of it with firefox 90, but it's still needed by the current ESR
release
Firefox 81 introduced a new print dialog. Under NixOS, this dialog
offers only "Save as PDF" as the destination. To print to a real
printer, one has to click "Print using the system dialog" and print
from there. This is not only one unnecessary extra click, but the
system dialog also does not offer preview.
With this commit, Firefox starts offering real printers in its
printing dialog, removing the above mentioned deficiencies.
CUPS is needed because Firefox uses dlopen() to load libcups.so.2 at
runtime. See
https://searchfox.org/mozilla-central/rev/b52cf6bbe214bd9d93ed9333d0403f7d556ad7c8/widget/nsCUPSShim.cpp#28
In order to make the man pages accessible, the previous code used
nix-support/propagated-user-env-packages. However this file is also used to set
the PATH when the application is executed with `nix run`, thus including the
wrapped and the wrappee in the environment.
Having the wrappee enumerated first in the environment caused `firefox` to
default to the wrappee, and as such not being able to find a proper GTK. This
was a source of failures while opening a file-picker.
This change removes the code to propagate the wrappe in the environment, as the
man pages are already linked in the wrapper output.
Since 37194a325d llvmPackages*.bintools is a bintools-wrapper. Thus it
only contains a wrapper for `as` and `ld`. This change makes sense, but
causes regressions like this one. Since the buildStdenv uses the llvm
bintool set including lld as a linker we can use the
cc.bintools.bintools derivation to get all the tools we need.
Technically we wouldn't need to set absolute paths as all tools are also
added to PATH, but it doesn't hurt either.
This will begin the process of breaking up the `useLLVM` monolith. That
is good in general, but I hope will be good for NetBSD and Darwin in
particular.
Co-authored-by: sterni <sternenseemann@systemli.org>
Also begin to start work on cross compilation, though that will have to
be finished later.
The patches are based on the first version of
https://reviews.llvm.org/D99484. It's very annoying to do the
back-porting but the review has uncovered nothing super major so I'm
fine sticking with what I've got.
Beyond making the outputs work, I also strove to re-sync the packages,
as they have been drifting pointlessly apart for some time.
----
Other misc notes, highly incomplete
- lvm-config-native and llvm-config are put in `dev` because they are
tools just for build time.
- Clang no longer has an lld dep. That was introduced in
db29857eb3, but if clang needs help
finding lld when it is used we should just pass it flags / put in the
resource dir. Providing it at build time increases critical path
length for no good reason.
----
A note on `nativeCC`:
`stdenv` takes tools from the previous stage, so:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.stdenv.cc`: `(?0, ?1, x)`
while:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.targetPackages`: `(x, x, ?2)`
3. `pkgsBuildBuild.targetPackages.stdenv.cc`: `(?1, x, x)`
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)
