With Firefox 98.0 the remoting name now depends on the update channel
(mozbz#1752418), which resulted in a weird app_id/wmclass of
`firefox-default`, which broke window association in GNOME and likely
other desktops.
Fixes: #165107
Currently `clangUseLLVM` is broken since it uses libcxx and compiler-rt but
also specifies `--gcc-toolchain`, which leads to weird compile errors when
including C++ headers.
The cacert package can now generate p11-kit-compatible output itself,
as well as generating the correct set of outputs for fully-joined
and unbundled "traditional" outputs (in standard PEM and
OpenSSL-compatible formats).
This should not change the derivation, but the new attribute names make
more sense once we package something that is not Firefox using this
expression.
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
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)`
