Thanks so much for your help, @rkruppe and @jethrogb!
I was able to stub out the atomic compare exchange routines. Now I have a
libstd that successfully built for my target, but the build fails during “
Building stage 1 compiler artifacts”. It is trying to build the
libc crate but
cargo is picking the public
libc from GH and not my local
rust/src/liblibc one. The build failures are regarding
c_char and other types that I defined in
src/liblibc/src/unit/notbsd/linux/musl/b32/new_tgt.rs. I tried patching the
src/cargo/Cargo.toml with a
[patch.crates.io], but that wasn’t effective. I saw these same build failures during an earlier step before I patched
Let me take a step back and sanity check my build process:
./x.py build -vv --stage 1 my_tgt.toml # this step is redundant if I do the next one?
./x.py build -vv --stage 2 my_tgt.toml
my_tgt.toml features nothing terribly out of the ordinary, I think –
use-jemalloc=false for now. I’ve tried with and without
extended=true with the hopes of fixing this and it doesn’t seem to.
I’ve patched the files below:
src/libunwind/lib.rs # different set of `link()` for this target
src/liblibc/src/unit/notbsd/linux/musl/mod.rs # pub use self::my_tgt::*;
src/liblibc/src/unit/notbsd/linux/musl/b32/mod.rs # target_arch="my_tgt" before "mod b32;pub use self::b32::*;"
src/liblibc/src/unit/notbsd/linux/musl/b32/new_tgt.rs # new for my target
src/libcore/sync/atomic.rs # basic impl of atomic cas
src/libpanic_unwind/gcc.rs # unwind registers
src/libunwind/libunwind.rs # unwind private data size
I’ll see if I can share a detailed log, if it’ll help.
As an aside: when I do the stage 1 build, it fails during
Building stage0 std artifacts (after it already does
Building stage1 std artifacts for my target). It is using the bootstrap
rustc to ask about this new target I’ve added.
error: failed to run rustc to learn about target-specific information /
... Could not find specification for target "my-tgt-...." . But that seems like a bug with
bootstrap/, maybe? It should expect that to fail when there’s a new target that’s missing from the bootstrap. Either that or I’m running the wrong
In any case, if I ignore the failure and proceed with stage 2, I’m still able to get
build/x86-unknown-linux-gnu/stage2/lib/rustlib/mytgt-.../lib/libstd-<hash>.so before I see that failure above.