Can we tailor the version of the compiler-builtins package that is compiled and linked together with the core crate?

[parraman]

We would like to know if it is currently possible to change the version of the compiler-builtins package that is compiled together with the core crate.

We are having problems with the current version of compiler-builtins on the sparc-unknown-linux-gnu target. A new version has been produced to fix the issue. However, we are not able to test it because we cannot prevent the original one from being included. We would like to be able to link the new version, which is stored on a separate branch, instead of the current version.

We cannot add a dependency to the other version of the package into our Cargo.toml file because then cargo will include both versions and generate a linking error telling us that there are currently two versions of the same functions.

[SimonSapin]

Not knowing much about all this, it sounds like something that should be tested within the rust-lang/rust repository instead of using Cargo’s build-std.

[ehuss]

It is currently not possible to change the version with build-std. As @SimonSapin mentioned, typically testing should be done by updating it in a clone of the rust-lang/rust repository and building rustc from there. Assuming things work, anyone is welcome to post a PR to bump the version (see rust-lang/rust#78209 for an example).

Supporting custom code with build-std is tracked in #7, though there isn't much of a plan or strategy on how that will work, yet.

[Hecatron]

I also ran into this exact same problem while trying to use a custom version of compiler_builtins on disk
while using xtensa-esp32-none-elf with build-std (uses a separate rustc llvm fork)

There's currently a conflict with memcpy functions from esp32hal and compiler_builtins which hasn't been fixed yet so I was trying to use a custom version of compiler_builtins on disk to get around it.
For now I'll have to stick with cargo xbuild from the looks of things.

I did try patching via

[patch.crates-io]
compiler_builtins = { path = './patched/compiler-builtins' }

But it looks as if the build-std is pulling in packages in such a way that they're not shown via "cargo tree"

[ehuss]

Closing per the comment in #61 (comment).