It's a copy of `gcc12.cc` implementation. Nothing special added here.
Note that gccgo13 does not build yet (similar to existing gccgo12).
The failure is related to libgcc_s.so lookup problems. Not specific
to gcc-13 release.
Co-authored-by: Weijia Wang <9713184+wegank@users.noreply.github.com>
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Reading this [rust-issue] it seems that we have to link against
rustc_driver. The [clippy.nix] expression already does something similar
Of the 4 executables found in the result of building rustfmt only
rustfmt and git-rustfmt needed to be linked. The other worked without
linking to rustc_driver.
[rust-issue]: https://github.com/rust-lang/rust/pull/105609
[clippy.nix]: c8cf570dae/pkgs/development/compilers/rust/clippy.nix (L27-L36)
It is almost never correct to use these attributes, because they don't
work correctly with splicing. Compare:
% nix repl -f . --argstr crossSystem aarch64-linux
Welcome to Nix 2.10.3. Type :? for help.
Loading installable ''...
Added 18988 variables.
nix-repl> callPackage ({ stdenv, rustc }: (stdenv.mkDerivation { name = ""; nativeBuildInputs = [ rustc ]; }).nativeBuildInputs) {}
«derivation /nix/store/bjrkg8kcq3hvg5kb03ivb856zy91qpbk-aarch64-unknown-linux-gnu-rustc-1.69.0.drv» ]
nix-repl> callPackage ({ stdenv, rustPlatform }: (stdenv.mkDerivation { name = ""; nativeBuildInputs = [ rustPlatform.rust.rustc ]; }).nativeBuildInputs) {}
«derivation /nix/store/ra5r07j52y7akclr827r3dzxzvqnvfbl-rustc-1.69.0.drv» ]
I'm not sure this is fixable. I don't think it's worth keeping them
around considering we have top level attributes. It makes overriding
slightly more annoying, but only slightly.
Appending to search paths allows dependencies to be replaced at runtime.
This is useful, for example, to the Dart packaging mechanism, which supplies a wrapped version of Git that spoofs cached Git package revisions for Pub.
