In reply to @nbp:mozilla.org
The replaceDependencies is the closest thing there is to replacing raw path to the nix store by another one in the nix-store, but beware that if the version changes from 0.4.0 to 0.4.0a this would cause a lot of issues.

In reply to @philiptaron:matrix.org
I currently find that if I try to ask for recursive output on my configuration, I end up getting an absolutely inscrutable error about list index 0 is out of bounds in lib/generators.nix toPretty method.

the rust infra has this definition:

linkerForTarget = if shouldUseLLD pkgsTargetTarget.stdenv.targetPlatform
      && !pkgsTargetTarget.stdenv.cc.bintools.isLLVM # whether stdenv's linker is lld already
      then "${pkgsBuildTarget.llvmPackages.bintools}/bin/${pkgsTargetTarget.stdenv.cc.targetPrefix}ld.lld"
      else ccForTarget;

when cross compiling to arm-none-eabihf (target = "thumbv7em-none-eabihf") this ends up picking arm-none-eabi-gcc as CARGO_TARGET_*_LINKER which then fails due to being passed flags like --gc-sections, -flavor, --as-needed, eh-frame-hdr and similar.

the rust infra has this definition:

linkerForTarget = if shouldUseLLD pkgsTargetTarget.stdenv.targetPlatform
      && !pkgsTargetTarget.stdenv.cc.bintools.isLLVM # whether stdenv's linker is lld already
      then "${pkgsBuildTarget.llvmPackages.bintools}/bin/${pkgsTargetTarget.stdenv.cc.targetPrefix}ld.lld"
      else ccForTarget;

when cross compiling to arm-none-eabihf (target = "thumbv7em-none-eabihf") this ends up picking arm-none-eabihf-gcc as CARGO_TARGET_*_LINKER which then fails due to being passed flags like --gc-sections, -flavor, --as-needed, eh-frame-hdr and similar.