It has Python 2.x as a build-time dependency, which has been EOL for years and was finally marked as insecure in https://github.com/NixOS/nixpkgs/pull/201859.
As such, it has been unbuildable on master without enabling insecure packages for almost half a year.
Upstream has no plans to migrate their build system away from py2 (though they might accept help with it), so we'll have to drop it:
https://forum.palemoon.org/viewtopic.php?f=62&t=28863&p=232152
`libgcc` is not usable as is and as a result no packages use it today.
`gcc.cc.libgcc` should provide the same library. But ideally it should
not be used at all as it's an implementation detail of `gcc` support
libraries.
Because llvmPackages_latest is used in Nixpkgs, by quite a few
packages, it's difficult to keep it up to date, because updating it
requires some level of confidence that every package that uses it is
going to keep working after the update. The result of this is that
llvmPackages_latest is not updated, and so we end up in the situation
that "latest" is two versions older than the latest version we
actually provide. This is confusing and unexpected.
"But won't this end up fragmenting our LLVM versions, if every package
previously using _latest is separately pinned to LLVM 14?", I hear you
ask. No. That fragmentation is already happening, even with an
llvmPackages_latest, because packages that actually require the
_latest_ version of LLVM (15/16), have already been decoupled from
llvmPackages_latest since it hasn't been upgraded. So like it or not,
we can't escape packages depending on specific recent LLVMs. The only
real fix is to get better at keeping the default LLVM up to
date (which I'm reasonably confident we're getting into a better
position to be feasibly better able to do).
So, unless we want to double down on providing a confusingly named
"llvmPackages_latest" attribute that refers to some arbitrary LLVM
version that's probably not the latest one (or even the latest one
available in Nixpkgs), we only have two options here: either we don't
provide such an attribute at all, or we don't use it in Nixpkgs so we
don't become scared to bump it as soon as we have a new LLVM available.
