Commit Graph

16 Commits

Author SHA1 Message Date
Jörg Thalheim
e25b2d4e37
rustc: link to https homepage 2023-12-25 20:52:38 +01:00
Jörg Thalheim
4d8e7dfe21
cargo: fix description and homepage 2023-12-25 20:51:26 +01:00
linsui
49db25dccb rust: set sourceProvenance for bootstrap binary 2023-12-25 21:36:29 +08:00
Alyssa Ross
8b51cdd3be 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-11-30 09:23:06 +00:00
figsoda
8f4874ca39 rustc: 1.70.0 -> 1.71.0
https://blog.rust-lang.org/2023/07/13/Rust-1.71.0.html

https://github.com/rust-lang/rust/releases/tag/1.71.0
2023-07-14 10:16:41 -04:00
Stéphan Kochen
da85286b28 rustc: don't strip bootstrap on darwin 2022-10-20 09:02:51 +10:00
Yureka
fb7811bf03 rustc: use autoPatchelfHook for bootstrap binaries
This is both simpler and works in more cases, e.g. for the bootstrap binaries
linked against musl libc.
2022-08-13 15:17:24 +02:00
Felix Buehler
6381ee34b5 rust: rename name to pname 2022-03-01 12:09:56 +01:00
Ben Siraphob
e03c068af5 treewide: makeWrapper buildInputs to nativeBuildInputs 2021-02-19 20:09:16 +07:00
Ben Siraphob
acc5f7b18a pkgs/development/compilers: stdenv.lib -> lib 2021-01-23 08:57:37 +07:00
Vladimír Čunát
89023c38fc
Recover the complicated situation after my bad merge
I made a mistake merge.  Reverting it in c778945806 undid the state
on master, but now I realize it crippled the git merge mechanism.
As the merge contained a mix of commits from `master..staging-next`
and other commits from `staging-next..staging`, it got the
`staging-next` branch into a state that was difficult to recover.

I reconstructed the "desired" state of staging-next tree by:
 - checking out the last commit of the problematic range: 4effe769e2
 - `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken
   merge commit and its revert from that range (while keeping
   reapplication from 4effe769e2)
 - merging the last unaffected staging-next commit (803ca85c20)
 - fortunately no other commits have been pushed to staging-next yet
 - applying a diff on staging-next to get it into that state
2020-10-26 09:01:04 +01:00
Vladimír Čunát
c778945806
Revert "Merge #101508: libraw: 0.20.0 -> 0.20.2"
I'm sorry; I didn't notice it contained staging commits.

This reverts commit 17f5305b6c, reversing
changes made to a8a018ddc0.
2020-10-25 09:41:51 +01:00
Finn Behrens
75ead1b43a
rust: 1.46.0 -> 1.47.0 2020-10-12 22:29:20 +02:00
Michael Reilly
84cf00f980
treewide: Per RFC45, remove all unquoted URLs 2020-04-10 17:54:53 +01:00
volth
08f68313a4 treewide: remove redundant rec 2019-08-28 11:07:32 +00:00
Eelco Dolstra
a4fc84de44 rustc: 1.36.0 -> 1.37.0 2019-08-16 14:10:13 +02:00