NetBSD fts wasn't really designed to be used in this way, and it can
produce some strange errors — e.g. I sometimes see duplicate symbols
when musl and libnbcompat define the same symbol.
More packages used musl-fts directly than the fts package anyway,
which can now be changed to use the generic fts.
Unlike netbsd.fts, musl-fts doesn't have a setup hook, so we have to
tell packages that don't know about it to link against libfts. We
could decide to copy netbsd.fts's setup hook later if we want to.
stdenv.targetPlatform really shouldn't be used by software that
doesn't generate or manipulate binaries. I reviewed all uses of
targetPlatform outside of pkgs/development/compilers and pkgs/stdenv
and replaced those which weren't involved in something which fits
these criteria.
Fixed `aarch64-darwin` built of `curl` reported by Martin Weinelt of
form:
curl-aarch64-darwin> checking run-time libs availability... failed
curl-aarch64-darwin> configure: error: one or more libs available at link-time are not available run-time. Libs used at link-time: -lnghttp2 -lidn2 -lssh2 -lssh2 -lssl -lcrypto -lssl -lcrypto -lgssapi_krb5 -lresolv -lzstd -lzstd -lbrotlidec -lbrotlidec -lz
I think we are embedding wrong runpath. Let's rely on `nixpkgs`'s
infrastructure until the failure is better understood.
Eliminate uses of `config.cudaSupport or false` and alike, since the
option is now declared in config.nix with a default value
fd .nix -t f -x sed 's/config\.cudaSupport or false, cudaPackages [?] [{][}]/config.cudaSupport, cudaPackages ? { }/' '{}' -i
fd .nix -t f -x sed 's/config\.cudaSupport or false/config.cudaSupport/' '{}' -i
fd .nix -t f -x sed 's/cudaSupport = pkgs.config.cudaSupport/inherit (pkgs.config) cudaSupport/' '{}' -i
fd .nix -t f -x sed 's/cudaSupport = config.cudaSupport/inherit (config) cudaSupport/' '{}' -i
