Bump to the latest relase. The current version is outdated and doesn't
seem to be able to boot my CM4 to mass storage device mode. This version
does, and according to
https://github.com/raspberrypi/usbboot/releases/tag/20221215-105525, it
"works on all current Raspberry Pi models and uses the default
bootloader that is signed with the secure-boot ROM key".
libiconv is already defined per-platform. The actual libiconv library
won't be built on platforms like Linux where it doesn't need to be, so
there's no need to maintain a separate platform list here.
Required to build for FreeBSD.
As the comment says, this should only have happened on Linux, not all
non-Darwin platforms.
Fixes pkgsCross.x86_64-netbsd.fzf.
Fixes: 1693ed2be9 ("fzf: wrap 'perl' in scripts with LOCALE_ARCHIVE")
systemd does not support being built statically[1], which means that,
prior to this patch, nothing that depends on udev can be built
statically. libudev-zero is a daemonless implementation of libudev,
that supports being built statically. So, by setting udev to be
libudev-zero when systemd is unavailable, we can get static builds of
packages like linuxPackages.usbip.
[1]: https://github.com/systemd/systemd/issues/20600#issuecomment-912338965
"llvm-as is an LLVM IR -> LLVM bitcode assembler not a system
assembler"[1], and therefore should not be linked as "as".
The "as" symlink was removed in 46e5ea5af6 ("llvm*: remove symlinks
to llvm-diff, llvm-as and associated LLVM IR utilities."), but that
was partially reverted by b331c72f03 ("llvm: setup some symlinks for
compatibility with binutils"), which restored a bunch of symlinks that
were incorrectly removed, but also incorrectly restored "as". This
was pointed out[2] at the time but apparently never fixed.
[1]: https://github.com/NixOS/nixpkgs/issues/93523#issue-661663683
[2]: b331c72f03 (commitcomment-40981705)
We were missing symlinks for some programs e.g. strings, which caused
e.g. pkgsLLVM.x264 to fail to build.
Here, I have filled in all the symlinks that LLVM would create if
built with the LLVM_INSTALL_BINUTILS_SYMLINKS option. Where an
existing symlink's target has changed, it's to avoid a double
indirection e.g. strip -> llvm-strip -> llvm-objcopy has because just
strip -> llvm-objcopy.
There's also the related problem that we are creating a as -> llvm-as
symlink, which doesn't make sense, but I'll remove that in a
subsequent commit so that if it somehow breaks something it's easy to
revert just that change.
Fixes: https://github.com/NixOS/nixpkgs/pull/210983