2023-05-09 19:44:54 +02:00
|
|
|
{ lib, stdenv, removeReferencesTo, pkgsBuildBuild, pkgsBuildHost, pkgsBuildTarget, targetPackages
|
2021-11-30 07:49:53 +01:00
|
|
|
, llvmShared, llvmSharedForBuild, llvmSharedForHost, llvmSharedForTarget, llvmPackages
|
2019-12-15 13:52:53 +01:00
|
|
|
, fetchurl, file, python3
|
2023-11-12 22:13:26 +01:00
|
|
|
, darwin, cargo, cmake, rustc, rustfmt
|
2022-10-16 01:23:42 +02:00
|
|
|
, pkg-config, openssl, xz
|
2021-05-07 23:36:21 +02:00
|
|
|
, libiconv
|
2019-09-30 11:00:33 +02:00
|
|
|
, which, libffi
|
2018-10-30 14:56:23 +01:00
|
|
|
, withBundledLLVM ? false
|
2020-01-18 10:57:13 +01:00
|
|
|
, enableRustcDev ? true
|
2019-11-08 13:04:53 +01:00
|
|
|
, version
|
|
|
|
, sha256
|
2020-02-23 00:34:05 +01:00
|
|
|
, patches ? []
|
2022-08-23 03:10:09 +02:00
|
|
|
, fd
|
2023-02-18 16:08:57 +01:00
|
|
|
, ripgrep
|
|
|
|
, wezterm
|
2022-08-23 03:10:09 +02:00
|
|
|
, firefox
|
|
|
|
, thunderbird
|
2022-06-07 12:28:03 +02:00
|
|
|
# This only builds std for target and reuses the rustc from build.
|
|
|
|
, fastCross
|
|
|
|
, lndir
|
|
|
|
, makeWrapper
|
2018-07-20 21:54:05 +02:00
|
|
|
}:
|
2015-10-03 16:23:00 +02:00
|
|
|
|
2016-05-31 21:16:18 +02:00
|
|
|
let
|
2021-01-22 12:25:31 +01:00
|
|
|
inherit (lib) optionals optional optionalString concatStringsSep;
|
2017-12-28 20:42:23 +01:00
|
|
|
inherit (darwin.apple_sdk.frameworks) Security;
|
2023-11-12 05:51:48 +01:00
|
|
|
in stdenv.mkDerivation (finalAttrs: {
|
2023-05-09 19:44:54 +02:00
|
|
|
pname = "${targetPackages.stdenv.cc.targetPrefix}rustc";
|
2019-11-08 13:04:53 +01:00
|
|
|
inherit version;
|
2015-10-03 16:23:00 +02:00
|
|
|
|
2018-11-21 02:47:45 +01:00
|
|
|
src = fetchurl {
|
|
|
|
url = "https://static.rust-lang.org/dist/rustc-${version}-src.tar.gz";
|
2019-11-08 13:04:53 +01:00
|
|
|
inherit sha256;
|
2023-11-12 05:51:48 +01:00
|
|
|
# See https://nixos.org/manual/nixpkgs/stable/#using-git-bisect-on-the-rust-compiler
|
|
|
|
passthru.isReleaseTarball = true;
|
2018-11-21 02:47:45 +01:00
|
|
|
};
|
2017-05-30 15:48:06 +02:00
|
|
|
|
2017-10-31 07:37:15 +01:00
|
|
|
__darwinAllowLocalNetworking = true;
|
2015-10-03 16:23:00 +02:00
|
|
|
|
2018-08-14 09:40:47 +02:00
|
|
|
# rustc complains about modified source files otherwise
|
|
|
|
dontUpdateAutotoolsGnuConfigScripts = true;
|
2017-12-02 13:46:33 +01:00
|
|
|
|
2018-01-24 12:34:03 +01:00
|
|
|
# Running the default `strip -S` command on Darwin corrupts the
|
|
|
|
# .rlib files in "lib/".
|
|
|
|
#
|
|
|
|
# See https://github.com/NixOS/nixpkgs/pull/34227
|
2019-03-13 17:52:01 +01:00
|
|
|
#
|
|
|
|
# Running `strip -S` when cross compiling can harm the cross rlibs.
|
|
|
|
# See: https://github.com/NixOS/nixpkgs/pull/56540#issuecomment-471624656
|
|
|
|
stripDebugList = [ "bin" ];
|
2018-01-24 12:34:03 +01:00
|
|
|
|
2022-10-16 01:23:42 +02:00
|
|
|
# The Rust pkg-config crate does not support prefixed pkg-config executables[1],
|
|
|
|
# but it does support checking these idiosyncratic PKG_CONFIG_${TRIPLE}
|
|
|
|
# environment variables.
|
|
|
|
# [1]: https://github.com/rust-lang/pkg-config-rs/issues/53
|
lib.systems: elaborate Rust metadata
We need this stuff to be available in lib so make-derivation.nix can
access it to construct the Meson cross file.
This has a couple of other advantages:
- It makes Rust less special. Now figuring out what Rust calls a
platform is the same as figuring out what Linux or QEMU call it.
- We can unify the schema used to define Rust targets, and the schema
used to access those values later. Just like you can set "config"
or "system" in a platform definition, and then access those same
keys on the elaborated platform, you can now set "rustcTarget" in
your crossSystem, and then access "stdenv.hostPlatform.rustcTarget"
in your code.
"rustcTarget", "rustcTargetSpec", "cargoShortTarget", and
"cargoEnvVarTarget" have the "rustc" and "cargo" prefixes because
these are not exposed to code by the compiler, and are not
standardized. The arch/os/etc. variables are all named to match the
forms in the Rust target spec JSON.
The new rust.target-family only takes a list, since we don't need to
worry about backwards compatibility when that name is used.
The old APIs are all still functional with no warning for now, so that
it's possible for external code to use a single API on both 23.05 and
23.11. We can introduce the warnings once 23.05 is EOL, and make them
hard errors when 23.11 is EOL.
2023-05-09 15:38:32 +02:00
|
|
|
"PKG_CONFIG_${builtins.replaceStrings ["-"] ["_"] stdenv.buildPlatform.rust.rustcTarget}" =
|
2022-10-16 01:23:42 +02:00
|
|
|
"${pkgsBuildHost.stdenv.cc.targetPrefix}pkg-config";
|
|
|
|
|
2019-10-30 01:12:09 +01:00
|
|
|
NIX_LDFLAGS = toString (
|
2018-10-30 14:56:23 +01:00
|
|
|
# when linking stage1 libstd: cc: undefined reference to `__cxa_begin_catch'
|
|
|
|
optional (stdenv.isLinux && !withBundledLLVM) "--push-state --as-needed -lstdc++ --pop-state"
|
2023-07-08 15:32:32 +02:00
|
|
|
++ optional (stdenv.isDarwin && !withBundledLLVM) "-lc++ -lc++abi"
|
2023-03-01 17:42:07 +01:00
|
|
|
++ optional stdenv.isDarwin "-rpath ${llvmSharedForHost}/lib");
|
2015-11-30 21:54:04 +01:00
|
|
|
|
2017-01-12 14:25:20 +01:00
|
|
|
# Increase codegen units to introduce parallelism within the compiler.
|
|
|
|
RUSTFLAGS = "-Ccodegen-units=10";
|
|
|
|
|
2023-11-18 12:19:27 +01:00
|
|
|
RUSTDOCFLAGS = "-A rustdoc::broken-intra-doc-links";
|
|
|
|
|
2016-05-31 21:16:18 +02:00
|
|
|
# We need rust to build rust. If we don't provide it, configure will try to download it.
|
2018-04-12 22:16:09 +02:00
|
|
|
# Reference: https://github.com/rust-lang/rust/blob/master/src/bootstrap/configure.py
|
2018-11-21 02:47:45 +01:00
|
|
|
configureFlags = let
|
2023-07-24 17:42:43 +02:00
|
|
|
prefixForStdenv = stdenv: "${stdenv.cc}/bin/${stdenv.cc.targetPrefix}";
|
|
|
|
ccPrefixForStdenv = stdenv: "${prefixForStdenv stdenv}${if (stdenv.cc.isClang or false) then "clang" else "cc"}";
|
|
|
|
cxxPrefixForStdenv = stdenv: "${prefixForStdenv stdenv}${if (stdenv.cc.isClang or false) then "clang++" else "c++"}";
|
lib.systems: elaborate Rust metadata
We need this stuff to be available in lib so make-derivation.nix can
access it to construct the Meson cross file.
This has a couple of other advantages:
- It makes Rust less special. Now figuring out what Rust calls a
platform is the same as figuring out what Linux or QEMU call it.
- We can unify the schema used to define Rust targets, and the schema
used to access those values later. Just like you can set "config"
or "system" in a platform definition, and then access those same
keys on the elaborated platform, you can now set "rustcTarget" in
your crossSystem, and then access "stdenv.hostPlatform.rustcTarget"
in your code.
"rustcTarget", "rustcTargetSpec", "cargoShortTarget", and
"cargoEnvVarTarget" have the "rustc" and "cargo" prefixes because
these are not exposed to code by the compiler, and are not
standardized. The arch/os/etc. variables are all named to match the
forms in the Rust target spec JSON.
The new rust.target-family only takes a list, since we don't need to
worry about backwards compatibility when that name is used.
The old APIs are all still functional with no warning for now, so that
it's possible for external code to use a single API on both 23.05 and
23.11. We can introduce the warnings once 23.05 is EOL, and make them
hard errors when 23.11 is EOL.
2023-05-09 15:38:32 +02:00
|
|
|
setBuild = "--set=target.${stdenv.buildPlatform.rust.rustcTarget}";
|
|
|
|
setHost = "--set=target.${stdenv.hostPlatform.rust.rustcTarget}";
|
|
|
|
setTarget = "--set=target.${stdenv.targetPlatform.rust.rustcTarget}";
|
2023-07-24 17:42:43 +02:00
|
|
|
ccForBuild = ccPrefixForStdenv pkgsBuildBuild.targetPackages.stdenv;
|
|
|
|
cxxForBuild = cxxPrefixForStdenv pkgsBuildBuild.targetPackages.stdenv;
|
|
|
|
ccForHost = ccPrefixForStdenv pkgsBuildHost.targetPackages.stdenv;
|
|
|
|
cxxForHost = cxxPrefixForStdenv pkgsBuildHost.targetPackages.stdenv;
|
|
|
|
ccForTarget = ccPrefixForStdenv pkgsBuildTarget.targetPackages.stdenv;
|
|
|
|
cxxForTarget = cxxPrefixForStdenv pkgsBuildTarget.targetPackages.stdenv;
|
2018-11-21 02:47:45 +01:00
|
|
|
in [
|
2023-11-16 19:07:23 +01:00
|
|
|
"--sysconfdir=${placeholder "out"}/etc"
|
2018-11-21 02:47:45 +01:00
|
|
|
"--release-channel=stable"
|
2023-05-12 16:17:16 +02:00
|
|
|
"--set=build.rustc=${rustc}/bin/rustc"
|
|
|
|
"--set=build.cargo=${cargo}/bin/cargo"
|
2023-11-12 05:51:48 +01:00
|
|
|
] ++ lib.optionals (!(finalAttrs.src.passthru.isReleaseTarball or false)) [
|
|
|
|
# release tarballs vendor the rustfmt source; when
|
|
|
|
# git-bisect'ing from upstream's git repo we must prevent
|
|
|
|
# attempts to download the missing source tarball
|
|
|
|
"--set=build.rustfmt=${rustfmt}/bin/rustfmt"
|
|
|
|
] ++ [
|
2024-04-10 23:07:04 +02:00
|
|
|
"--tools=rustc,rustdoc,rust-analyzer-proc-macro-srv"
|
2018-11-21 02:47:45 +01:00
|
|
|
"--enable-rpath"
|
|
|
|
"--enable-vendor"
|
lib.systems: elaborate Rust metadata
We need this stuff to be available in lib so make-derivation.nix can
access it to construct the Meson cross file.
This has a couple of other advantages:
- It makes Rust less special. Now figuring out what Rust calls a
platform is the same as figuring out what Linux or QEMU call it.
- We can unify the schema used to define Rust targets, and the schema
used to access those values later. Just like you can set "config"
or "system" in a platform definition, and then access those same
keys on the elaborated platform, you can now set "rustcTarget" in
your crossSystem, and then access "stdenv.hostPlatform.rustcTarget"
in your code.
"rustcTarget", "rustcTargetSpec", "cargoShortTarget", and
"cargoEnvVarTarget" have the "rustc" and "cargo" prefixes because
these are not exposed to code by the compiler, and are not
standardized. The arch/os/etc. variables are all named to match the
forms in the Rust target spec JSON.
The new rust.target-family only takes a list, since we don't need to
worry about backwards compatibility when that name is used.
The old APIs are all still functional with no warning for now, so that
it's possible for external code to use a single API on both 23.05 and
23.11. We can introduce the warnings once 23.05 is EOL, and make them
hard errors when 23.11 is EOL.
2023-05-09 15:38:32 +02:00
|
|
|
"--build=${stdenv.buildPlatform.rust.rustcTargetSpec}"
|
|
|
|
"--host=${stdenv.hostPlatform.rust.rustcTargetSpec}"
|
2023-04-17 07:21:21 +02:00
|
|
|
# std is built for all platforms in --target.
|
2020-12-12 21:18:30 +01:00
|
|
|
"--target=${concatStringsSep "," ([
|
lib.systems: elaborate Rust metadata
We need this stuff to be available in lib so make-derivation.nix can
access it to construct the Meson cross file.
This has a couple of other advantages:
- It makes Rust less special. Now figuring out what Rust calls a
platform is the same as figuring out what Linux or QEMU call it.
- We can unify the schema used to define Rust targets, and the schema
used to access those values later. Just like you can set "config"
or "system" in a platform definition, and then access those same
keys on the elaborated platform, you can now set "rustcTarget" in
your crossSystem, and then access "stdenv.hostPlatform.rustcTarget"
in your code.
"rustcTarget", "rustcTargetSpec", "cargoShortTarget", and
"cargoEnvVarTarget" have the "rustc" and "cargo" prefixes because
these are not exposed to code by the compiler, and are not
standardized. The arch/os/etc. variables are all named to match the
forms in the Rust target spec JSON.
The new rust.target-family only takes a list, since we don't need to
worry about backwards compatibility when that name is used.
The old APIs are all still functional with no warning for now, so that
it's possible for external code to use a single API on both 23.05 and
23.11. We can introduce the warnings once 23.05 is EOL, and make them
hard errors when 23.11 is EOL.
2023-05-09 15:38:32 +02:00
|
|
|
stdenv.targetPlatform.rust.rustcTargetSpec
|
2023-04-17 07:21:21 +02:00
|
|
|
|
2023-11-18 12:19:27 +01:00
|
|
|
# Other targets that don't need any extra dependencies to build.
|
|
|
|
] ++ optionals (!fastCross) [
|
|
|
|
"wasm32-unknown-unknown"
|
|
|
|
|
2023-04-17 07:21:21 +02:00
|
|
|
# (build!=target): When cross-building a compiler we need to add
|
|
|
|
# the build platform as well so rustc can compile build.rs
|
|
|
|
# scripts.
|
2022-06-07 12:28:03 +02:00
|
|
|
] ++ optionals (stdenv.buildPlatform != stdenv.targetPlatform && !fastCross) [
|
lib.systems: elaborate Rust metadata
We need this stuff to be available in lib so make-derivation.nix can
access it to construct the Meson cross file.
This has a couple of other advantages:
- It makes Rust less special. Now figuring out what Rust calls a
platform is the same as figuring out what Linux or QEMU call it.
- We can unify the schema used to define Rust targets, and the schema
used to access those values later. Just like you can set "config"
or "system" in a platform definition, and then access those same
keys on the elaborated platform, you can now set "rustcTarget" in
your crossSystem, and then access "stdenv.hostPlatform.rustcTarget"
in your code.
"rustcTarget", "rustcTargetSpec", "cargoShortTarget", and
"cargoEnvVarTarget" have the "rustc" and "cargo" prefixes because
these are not exposed to code by the compiler, and are not
standardized. The arch/os/etc. variables are all named to match the
forms in the Rust target spec JSON.
The new rust.target-family only takes a list, since we don't need to
worry about backwards compatibility when that name is used.
The old APIs are all still functional with no warning for now, so that
it's possible for external code to use a single API on both 23.05 and
23.11. We can introduce the warnings once 23.05 is EOL, and make them
hard errors when 23.11 is EOL.
2023-05-09 15:38:32 +02:00
|
|
|
stdenv.buildPlatform.rust.rustcTargetSpec
|
2023-04-17 07:21:21 +02:00
|
|
|
|
|
|
|
# (host!=target): When building a cross-targeting compiler we
|
|
|
|
# need to add the host platform as well so rustc can compile
|
|
|
|
# build.rs scripts.
|
2022-06-07 12:28:03 +02:00
|
|
|
] ++ optionals (stdenv.hostPlatform != stdenv.targetPlatform && !fastCross) [
|
lib.systems: elaborate Rust metadata
We need this stuff to be available in lib so make-derivation.nix can
access it to construct the Meson cross file.
This has a couple of other advantages:
- It makes Rust less special. Now figuring out what Rust calls a
platform is the same as figuring out what Linux or QEMU call it.
- We can unify the schema used to define Rust targets, and the schema
used to access those values later. Just like you can set "config"
or "system" in a platform definition, and then access those same
keys on the elaborated platform, you can now set "rustcTarget" in
your crossSystem, and then access "stdenv.hostPlatform.rustcTarget"
in your code.
"rustcTarget", "rustcTargetSpec", "cargoShortTarget", and
"cargoEnvVarTarget" have the "rustc" and "cargo" prefixes because
these are not exposed to code by the compiler, and are not
standardized. The arch/os/etc. variables are all named to match the
forms in the Rust target spec JSON.
The new rust.target-family only takes a list, since we don't need to
worry about backwards compatibility when that name is used.
The old APIs are all still functional with no warning for now, so that
it's possible for external code to use a single API on both 23.05 and
23.11. We can introduce the warnings once 23.05 is EOL, and make them
hard errors when 23.11 is EOL.
2023-05-09 15:38:32 +02:00
|
|
|
stdenv.hostPlatform.rust.rustcTargetSpec
|
2020-12-12 21:18:30 +01:00
|
|
|
])}"
|
2018-11-21 02:47:45 +01:00
|
|
|
|
|
|
|
"${setBuild}.cc=${ccForBuild}"
|
|
|
|
"${setHost}.cc=${ccForHost}"
|
|
|
|
"${setTarget}.cc=${ccForTarget}"
|
|
|
|
|
|
|
|
"${setBuild}.linker=${ccForBuild}"
|
|
|
|
"${setHost}.linker=${ccForHost}"
|
|
|
|
"${setTarget}.linker=${ccForTarget}"
|
|
|
|
|
|
|
|
"${setBuild}.cxx=${cxxForBuild}"
|
|
|
|
"${setHost}.cxx=${cxxForHost}"
|
|
|
|
"${setTarget}.cxx=${cxxForTarget}"
|
2021-10-17 12:44:49 +02:00
|
|
|
|
|
|
|
"${setBuild}.crt-static=${lib.boolToString stdenv.buildPlatform.isStatic}"
|
|
|
|
"${setHost}.crt-static=${lib.boolToString stdenv.hostPlatform.isStatic}"
|
|
|
|
"${setTarget}.crt-static=${lib.boolToString stdenv.targetPlatform.isStatic}"
|
2019-11-13 14:17:33 +01:00
|
|
|
] ++ optionals (!withBundledLLVM) [
|
2018-11-21 02:47:45 +01:00
|
|
|
"--enable-llvm-link-shared"
|
2021-05-01 04:03:30 +02:00
|
|
|
"${setBuild}.llvm-config=${llvmSharedForBuild.dev}/bin/llvm-config"
|
|
|
|
"${setHost}.llvm-config=${llvmSharedForHost.dev}/bin/llvm-config"
|
|
|
|
"${setTarget}.llvm-config=${llvmSharedForTarget.dev}/bin/llvm-config"
|
2020-07-21 22:11:36 +02:00
|
|
|
] ++ optionals (stdenv.isLinux && !stdenv.targetPlatform.isRedox) [
|
2019-07-31 17:55:33 +02:00
|
|
|
"--enable-profiler" # build libprofiler_builtins
|
2020-11-29 18:47:51 +01:00
|
|
|
] ++ optionals stdenv.buildPlatform.isMusl [
|
|
|
|
"${setBuild}.musl-root=${pkgsBuildBuild.targetPackages.stdenv.cc.libc}"
|
|
|
|
] ++ optionals stdenv.hostPlatform.isMusl [
|
|
|
|
"${setHost}.musl-root=${pkgsBuildHost.targetPackages.stdenv.cc.libc}"
|
2020-11-29 01:32:43 +01:00
|
|
|
] ++ optionals stdenv.targetPlatform.isMusl [
|
2020-11-29 18:47:51 +01:00
|
|
|
"${setTarget}.musl-root=${pkgsBuildTarget.targetPackages.stdenv.cc.libc}"
|
lib.systems: elaborate Rust metadata
We need this stuff to be available in lib so make-derivation.nix can
access it to construct the Meson cross file.
This has a couple of other advantages:
- It makes Rust less special. Now figuring out what Rust calls a
platform is the same as figuring out what Linux or QEMU call it.
- We can unify the schema used to define Rust targets, and the schema
used to access those values later. Just like you can set "config"
or "system" in a platform definition, and then access those same
keys on the elaborated platform, you can now set "rustcTarget" in
your crossSystem, and then access "stdenv.hostPlatform.rustcTarget"
in your code.
"rustcTarget", "rustcTargetSpec", "cargoShortTarget", and
"cargoEnvVarTarget" have the "rustc" and "cargo" prefixes because
these are not exposed to code by the compiler, and are not
standardized. The arch/os/etc. variables are all named to match the
forms in the Rust target spec JSON.
The new rust.target-family only takes a list, since we don't need to
worry about backwards compatibility when that name is used.
The old APIs are all still functional with no warning for now, so that
it's possible for external code to use a single API on both 23.05 and
23.11. We can introduce the warnings once 23.05 is EOL, and make them
hard errors when 23.11 is EOL.
2023-05-09 15:38:32 +02:00
|
|
|
] ++ optionals stdenv.targetPlatform.rust.isNoStdTarget [
|
2022-10-07 16:35:29 +02:00
|
|
|
"--disable-docs"
|
2022-09-24 04:27:21 +02:00
|
|
|
] ++ optionals (stdenv.isDarwin && stdenv.isx86_64) [
|
|
|
|
# https://github.com/rust-lang/rust/issues/92173
|
|
|
|
"--set rust.jemalloc"
|
2018-11-21 02:47:45 +01:00
|
|
|
];
|
2015-10-03 16:23:00 +02:00
|
|
|
|
2022-06-07 12:28:03 +02:00
|
|
|
# if we already have a rust compiler for build just compile the target std
|
|
|
|
# library and reuse compiler
|
|
|
|
buildPhase = if fastCross then "
|
|
|
|
runHook preBuild
|
|
|
|
|
lib.systems: elaborate Rust metadata
We need this stuff to be available in lib so make-derivation.nix can
access it to construct the Meson cross file.
This has a couple of other advantages:
- It makes Rust less special. Now figuring out what Rust calls a
platform is the same as figuring out what Linux or QEMU call it.
- We can unify the schema used to define Rust targets, and the schema
used to access those values later. Just like you can set "config"
or "system" in a platform definition, and then access those same
keys on the elaborated platform, you can now set "rustcTarget" in
your crossSystem, and then access "stdenv.hostPlatform.rustcTarget"
in your code.
"rustcTarget", "rustcTargetSpec", "cargoShortTarget", and
"cargoEnvVarTarget" have the "rustc" and "cargo" prefixes because
these are not exposed to code by the compiler, and are not
standardized. The arch/os/etc. variables are all named to match the
forms in the Rust target spec JSON.
The new rust.target-family only takes a list, since we don't need to
worry about backwards compatibility when that name is used.
The old APIs are all still functional with no warning for now, so that
it's possible for external code to use a single API on both 23.05 and
23.11. We can introduce the warnings once 23.05 is EOL, and make them
hard errors when 23.11 is EOL.
2023-05-09 15:38:32 +02:00
|
|
|
mkdir -p build/${stdenv.hostPlatform.rust.rustcTargetSpec}/stage0-{std,rustc}/${stdenv.hostPlatform.rust.rustcTargetSpec}/release/
|
rustc: add a compiler wrapper
We keep running into situations where we can't get the right
combination of rustc flags through build systems into rustc.
RUSTFLAGS is the only variable supported across build systems, but if
RUSTFLAGS is set, Cargo will ignore all other ways of specifying rustc
flags, including the target-specific ones, which we need to make
dynamic musl builds work. (This is why pkgsCross.musl64.crosvm is
currently broken — it works if you unset separateDebugInfo, which
causes RUSTFLAGS not to be set.)
So, we need to do the same thing we do for C and C++ compilers, and
add a compiler wrapper so we can inject the flags we need, regardless
of the build system.
Currently the wrapper only supports a single mechanism for injecting
flags — the NIX_RUSTFLAGS environment variable. As time goes on,
we'll probably want to add additional features, like target-specific
environment variables.
2023-10-18 13:02:45 +02:00
|
|
|
ln -s ${rustc.unwrapped}/lib/rustlib/${stdenv.hostPlatform.rust.rustcTargetSpec}/libstd-*.so build/${stdenv.hostPlatform.rust.rustcTargetSpec}/stage0-std/${stdenv.hostPlatform.rust.rustcTargetSpec}/release/libstd.so
|
|
|
|
ln -s ${rustc.unwrapped}/lib/rustlib/${stdenv.hostPlatform.rust.rustcTargetSpec}/librustc_driver-*.so build/${stdenv.hostPlatform.rust.rustcTargetSpec}/stage0-rustc/${stdenv.hostPlatform.rust.rustcTargetSpec}/release/librustc.so
|
|
|
|
ln -s ${rustc.unwrapped}/bin/rustc build/${stdenv.hostPlatform.rust.rustcTargetSpec}/stage0-rustc/${stdenv.hostPlatform.rust.rustcTargetSpec}/release/rustc-main
|
lib.systems: elaborate Rust metadata
We need this stuff to be available in lib so make-derivation.nix can
access it to construct the Meson cross file.
This has a couple of other advantages:
- It makes Rust less special. Now figuring out what Rust calls a
platform is the same as figuring out what Linux or QEMU call it.
- We can unify the schema used to define Rust targets, and the schema
used to access those values later. Just like you can set "config"
or "system" in a platform definition, and then access those same
keys on the elaborated platform, you can now set "rustcTarget" in
your crossSystem, and then access "stdenv.hostPlatform.rustcTarget"
in your code.
"rustcTarget", "rustcTargetSpec", "cargoShortTarget", and
"cargoEnvVarTarget" have the "rustc" and "cargo" prefixes because
these are not exposed to code by the compiler, and are not
standardized. The arch/os/etc. variables are all named to match the
forms in the Rust target spec JSON.
The new rust.target-family only takes a list, since we don't need to
worry about backwards compatibility when that name is used.
The old APIs are all still functional with no warning for now, so that
it's possible for external code to use a single API on both 23.05 and
23.11. We can introduce the warnings once 23.05 is EOL, and make them
hard errors when 23.11 is EOL.
2023-05-09 15:38:32 +02:00
|
|
|
touch build/${stdenv.hostPlatform.rust.rustcTargetSpec}/stage0-std/${stdenv.hostPlatform.rust.rustcTargetSpec}/release/.libstd.stamp
|
|
|
|
touch build/${stdenv.hostPlatform.rust.rustcTargetSpec}/stage0-rustc/${stdenv.hostPlatform.rust.rustcTargetSpec}/release/.librustc.stamp
|
rustc: Fix building cross-compilers for no_std targets.
When building a cross-compiler, the rustc derivation does some tricks to
only build the standard library and reuse the host's compiler, leading
to much faster build time.
Unfortunately, the way the build system was invoked, it would always
build the `std` crate, whether or not the target supports it. Some
bare-metal targets only support building the `core` and `alloc` crates.
By being more vague about the build command, using `library` instead of
`library/std`, Rust's build system is able to figure out exactly which
crates to build:
https://github.com/rust-lang/rust/blob/1.74.1/src/bootstrap/compile.rs#L370-L412
Oddly enough, the install command still needs to use `library/std`, even
if building just a subset:
https://github.com/rust-lang/rust/blob/1.74.1/src/bootstrap/install.rs#L207
The following command was used to reproduce the original issue. Without
this patch, it leads to a build failure when trying to compile one of
std's dependencies. With the patch it completes succesfully and produces
a working cross-compiler.
nix build --impure --expr '(import ./. {
crossSystem = {
config = "riscv32-none-elf";
rustc.config = "riscv32imc-unknown-none-elf";
};
}).buildPackages.rustc'
2024-01-04 10:43:06 +01:00
|
|
|
python ./x.py --keep-stage=0 --stage=1 build library
|
2022-06-07 12:28:03 +02:00
|
|
|
|
|
|
|
runHook postBuild
|
|
|
|
" else null;
|
|
|
|
|
|
|
|
installPhase = if fastCross then ''
|
|
|
|
runHook preInstall
|
|
|
|
|
|
|
|
python ./x.py --keep-stage=0 --stage=1 install library/std
|
|
|
|
mkdir -v $out/bin $doc $man
|
2024-03-02 13:03:26 +01:00
|
|
|
ln -s ${rustc.unwrapped}/bin/{rustc,rustdoc} $out/bin
|
rustc: add a compiler wrapper
We keep running into situations where we can't get the right
combination of rustc flags through build systems into rustc.
RUSTFLAGS is the only variable supported across build systems, but if
RUSTFLAGS is set, Cargo will ignore all other ways of specifying rustc
flags, including the target-specific ones, which we need to make
dynamic musl builds work. (This is why pkgsCross.musl64.crosvm is
currently broken — it works if you unset separateDebugInfo, which
causes RUSTFLAGS not to be set.)
So, we need to do the same thing we do for C and C++ compilers, and
add a compiler wrapper so we can inject the flags we need, regardless
of the build system.
Currently the wrapper only supports a single mechanism for injecting
flags — the NIX_RUSTFLAGS environment variable. As time goes on,
we'll probably want to add additional features, like target-specific
environment variables.
2023-10-18 13:02:45 +02:00
|
|
|
ln -s ${rustc.unwrapped}/lib/rustlib/{manifest-rust-std-,}${stdenv.hostPlatform.rust.rustcTargetSpec} $out/lib/rustlib/
|
lib.systems: elaborate Rust metadata
We need this stuff to be available in lib so make-derivation.nix can
access it to construct the Meson cross file.
This has a couple of other advantages:
- It makes Rust less special. Now figuring out what Rust calls a
platform is the same as figuring out what Linux or QEMU call it.
- We can unify the schema used to define Rust targets, and the schema
used to access those values later. Just like you can set "config"
or "system" in a platform definition, and then access those same
keys on the elaborated platform, you can now set "rustcTarget" in
your crossSystem, and then access "stdenv.hostPlatform.rustcTarget"
in your code.
"rustcTarget", "rustcTargetSpec", "cargoShortTarget", and
"cargoEnvVarTarget" have the "rustc" and "cargo" prefixes because
these are not exposed to code by the compiler, and are not
standardized. The arch/os/etc. variables are all named to match the
forms in the Rust target spec JSON.
The new rust.target-family only takes a list, since we don't need to
worry about backwards compatibility when that name is used.
The old APIs are all still functional with no warning for now, so that
it's possible for external code to use a single API on both 23.05 and
23.11. We can introduce the warnings once 23.05 is EOL, and make them
hard errors when 23.11 is EOL.
2023-05-09 15:38:32 +02:00
|
|
|
echo rust-std-${stdenv.hostPlatform.rust.rustcTargetSpec} >> $out/lib/rustlib/components
|
2022-06-07 12:28:03 +02:00
|
|
|
lndir ${rustc.doc} $doc
|
|
|
|
lndir ${rustc.man} $man
|
|
|
|
|
|
|
|
runHook postInstall
|
|
|
|
'' else null;
|
|
|
|
|
2017-10-07 00:12:22 +02:00
|
|
|
# the rust build system complains that nix alters the checksums
|
|
|
|
dontFixLibtool = true;
|
|
|
|
|
2020-02-23 00:34:05 +01:00
|
|
|
inherit patches;
|
|
|
|
|
2015-10-03 16:23:00 +02:00
|
|
|
postPatch = ''
|
2018-02-20 10:59:26 +01:00
|
|
|
patchShebangs src/etc
|
|
|
|
|
2021-01-24 10:19:10 +01:00
|
|
|
${optionalString (!withBundledLLVM) "rm -rf src/llvm"}
|
2015-10-03 16:23:00 +02:00
|
|
|
|
|
|
|
# Useful debugging parameter
|
2016-08-24 11:56:02 +02:00
|
|
|
# export VERBOSE=1
|
2022-09-28 23:07:46 +02:00
|
|
|
'' + lib.optionalString (stdenv.isDarwin && stdenv.isx86_64) ''
|
|
|
|
# See https://github.com/jemalloc/jemalloc/issues/1997
|
|
|
|
# Using a value of 48 should work on both emulated and native x86_64-darwin.
|
|
|
|
export JEMALLOC_SYS_WITH_LG_VADDR=48
|
2023-11-12 05:51:48 +01:00
|
|
|
'' + lib.optionalString (!(finalAttrs.src.passthru.isReleaseTarball or false)) ''
|
|
|
|
mkdir .cargo
|
|
|
|
cat > .cargo/config <<\EOF
|
|
|
|
[source.crates-io]
|
|
|
|
replace-with = "vendored-sources"
|
|
|
|
[source.vendored-sources]
|
|
|
|
directory = "vendor"
|
|
|
|
EOF
|
2015-10-03 16:23:00 +02:00
|
|
|
'';
|
|
|
|
|
2019-02-27 04:24:42 +01:00
|
|
|
# rustc unfortunately needs cmake to compile llvm-rt but doesn't
|
2016-08-24 11:56:02 +02:00
|
|
|
# use it for the normal build. This disables cmake in Nix.
|
|
|
|
dontUseCmakeConfigure = true;
|
2016-07-19 10:25:35 +02:00
|
|
|
|
2022-10-16 01:27:12 +02:00
|
|
|
depsBuildBuild = [ pkgsBuildHost.stdenv.cc pkg-config ];
|
2022-10-16 01:23:42 +02:00
|
|
|
|
2018-11-21 02:47:45 +01:00
|
|
|
nativeBuildInputs = [
|
2023-05-12 16:17:16 +02:00
|
|
|
file python3 rustc cmake
|
2022-10-16 01:23:42 +02:00
|
|
|
which libffi removeReferencesTo pkg-config xz
|
2022-06-07 12:28:03 +02:00
|
|
|
]
|
|
|
|
++ optionals fastCross [ lndir makeWrapper ];
|
2016-07-19 10:25:35 +02:00
|
|
|
|
2019-09-26 14:51:12 +02:00
|
|
|
buildInputs = [ openssl ]
|
2022-12-16 00:38:33 +01:00
|
|
|
++ optionals stdenv.isDarwin [ libiconv Security ]
|
2018-10-30 14:56:23 +01:00
|
|
|
++ optional (!withBundledLLVM) llvmShared;
|
2015-10-03 16:23:00 +02:00
|
|
|
|
2017-07-11 11:14:14 +02:00
|
|
|
outputs = [ "out" "man" "doc" ];
|
2016-04-08 15:56:26 +02:00
|
|
|
setOutputFlags = false;
|
2015-10-03 16:23:00 +02:00
|
|
|
|
2022-06-07 12:28:03 +02:00
|
|
|
postInstall = lib.optionalString (enableRustcDev && !fastCross) ''
|
2020-01-11 13:00:00 +01:00
|
|
|
# install rustc-dev components. Necessary to build rls, clippy...
|
|
|
|
python x.py dist rustc-dev
|
|
|
|
tar xf build/dist/rustc-dev*tar.gz
|
|
|
|
cp -r rustc-dev*/rustc-dev*/lib/* $out/lib/
|
2020-12-07 22:27:42 +01:00
|
|
|
rm $out/lib/rustlib/install.log
|
|
|
|
for m in $out/lib/rustlib/manifest-rust*
|
|
|
|
do
|
|
|
|
sort --output=$m < $m
|
|
|
|
done
|
2020-01-11 13:00:00 +01:00
|
|
|
|
2020-01-18 10:57:13 +01:00
|
|
|
'' + ''
|
2020-01-11 13:00:00 +01:00
|
|
|
# remove references to llvm-config in lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
|
|
|
|
# and thus a transitive dependency on ncurses
|
2018-10-30 14:56:23 +01:00
|
|
|
find $out/lib -name "*.so" -type f -exec remove-references-to -t ${llvmShared} '{}' '+'
|
2020-12-26 21:33:37 +01:00
|
|
|
|
|
|
|
# remove uninstall script that doesn't really make sense for Nix.
|
|
|
|
rm $out/lib/rustlib/uninstall.sh
|
2018-10-30 14:56:23 +01:00
|
|
|
'';
|
|
|
|
|
2017-06-23 23:45:27 +02:00
|
|
|
configurePlatforms = [];
|
2017-01-12 14:25:20 +01:00
|
|
|
|
2023-02-25 20:40:40 +01:00
|
|
|
enableParallelBuilding = true;
|
2017-01-12 14:25:20 +01:00
|
|
|
|
2019-07-07 14:44:04 +02:00
|
|
|
setupHooks = ./setup-hook.sh;
|
|
|
|
|
2019-01-24 18:30:35 +01:00
|
|
|
requiredSystemFeatures = [ "big-parallel" ];
|
|
|
|
|
2021-11-02 17:34:05 +01:00
|
|
|
passthru = {
|
|
|
|
llvm = llvmShared;
|
2021-11-30 07:49:53 +01:00
|
|
|
inherit llvmPackages;
|
2023-02-18 16:08:57 +01:00
|
|
|
tests = {
|
|
|
|
inherit fd ripgrep wezterm;
|
|
|
|
} // lib.optionalAttrs stdenv.hostPlatform.isLinux { inherit firefox thunderbird; };
|
2021-11-02 17:34:05 +01:00
|
|
|
};
|
2020-02-18 02:58:48 +01:00
|
|
|
|
2021-01-22 12:25:31 +01:00
|
|
|
meta = with lib; {
|
2020-02-18 02:58:48 +01:00
|
|
|
homepage = "https://www.rust-lang.org/";
|
2017-01-12 14:25:20 +01:00
|
|
|
description = "A safe, concurrent, practical language";
|
2023-10-24 13:09:45 +02:00
|
|
|
maintainers = with maintainers; [ havvy ] ++ teams.rust.members;
|
2017-01-12 14:25:20 +01:00
|
|
|
license = [ licenses.mit licenses.asl20 ];
|
2023-04-24 19:35:35 +02:00
|
|
|
platforms = [
|
|
|
|
# Platforms with host tools from
|
|
|
|
# https://doc.rust-lang.org/nightly/rustc/platform-support.html
|
|
|
|
"x86_64-darwin" "i686-darwin" "aarch64-darwin"
|
2024-04-01 15:52:41 +02:00
|
|
|
"i686-freebsd" "x86_64-freebsd"
|
2023-04-24 19:35:35 +02:00
|
|
|
"x86_64-solaris"
|
2023-06-25 15:23:47 +02:00
|
|
|
"aarch64-linux" "armv6l-linux" "armv7l-linux" "i686-linux"
|
2023-10-09 15:02:41 +02:00
|
|
|
"loongarch64-linux" "powerpc64-linux" "powerpc64le-linux"
|
|
|
|
"riscv64-linux" "s390x-linux" "x86_64-linux"
|
2023-04-24 19:35:35 +02:00
|
|
|
"aarch64-netbsd" "armv7l-netbsd" "i686-netbsd" "powerpc-netbsd"
|
|
|
|
"x86_64-netbsd"
|
|
|
|
"i686-openbsd" "x86_64-openbsd"
|
|
|
|
"i686-windows" "x86_64-windows"
|
|
|
|
];
|
2017-01-12 14:25:20 +01:00
|
|
|
};
|
2023-11-12 05:51:48 +01:00
|
|
|
})
|