rustc custom target compile is broken

[stefson]

hey there,

I hope I'm at the right spot to ask for help with my problem: starting with rust-1.85.0_beta, I'm unable to compile my custom target I've been using for many years now:

rustc --print target-list | grep armv7a-unknown
> armv7a-unknown-linux-musleabihf

this is the output of rustc -Vv

rustc 1.84.0 (9fc6b4312 2025-01-07) (built from a source tarball)
binary: rustc
commit-hash: 9fc6b43126469e3858e2fe86cafb4f0fd5068869
commit-date: 2025-01-07
host: armv7a-unknown-linux-musleabihf
release: 1.84.0
LLVM version: 19.1.5

How can I hack the target infos into the vendored cc crate, please?

[NobodyXu]

If you are using cargo and using cc in build scripy, then cc should be able to infer these info from cargo environment variables passed down.

Are you using cc in build script, or in other use cases?

[stefson]

hi, my usecase is bootstraping rustc itself:

running: /var/tmp/portage/dev-lang/rust-1.85.0_beta/work/rustc-beta-src/build/bootstrap/debug/bootstrap build -vv --config=/var/tmp/portage/dev-lang/rust-1.85.0_beta/work/rustc-beta-src/config.toml -j1
WARNING: The `change-id` is missing in the `config.toml`. This means that you will not be able to track the major changes made to the bootstrap configurations.
NOTE: to silence this warning, add `change-id = 134650` at the top of `config.toml`
finding compilers


error occurred: unknown target `armv7a-unknown-linux-musleabihf`


Traceback (most recent call last):
  File "/var/tmp/portage/dev-lang/rust-1.85.0_beta/work/rustc-beta-src/./x.py", line 53, in <module>
    bootstrap.main()
  File "/var/tmp/portage/dev-lang/rust-1.85.0_beta/work/rustc-beta-src/src/bootstrap/bootstrap.py", line 1333, in main
    bootstrap(args)
  File "/var/tmp/portage/dev-lang/rust-1.85.0_beta/work/rustc-beta-src/src/bootstrap/bootstrap.py", line 1308, in bootstrap
    run(args, env=env, verbose=build.verbose, is_bootstrap=True)
  File "/var/tmp/portage/dev-lang/rust-1.85.0_beta/work/rustc-beta-src/src/bootstrap/bootstrap.py", line 236, in run
    raise RuntimeError(err)
RuntimeError: failed to run: /var/tmp/portage/dev-lang/rust-1.85.0_beta/work/rustc-beta-src/build/bootstrap/debug/bootstrap build -vv --config=/var/tmp/portage/dev-lang/rust-1.85.0_beta/work/rustc-beta-src/config.toml -j1

this is the backtrace:

RUST_BACKTRACE=full /var/tmp/portage/dev-lang/rust-1.85.0_beta/work/rustc-beta-src/build/bootstrap/debug/bootstrap build -vv --config=/var/tmp/portage/dev-lang/rust-1.85.0_beta/work/rustc-beta-src/config.toml -j1
thread 'main' panicked at src/bootstrap/src/bin/main.rs:38:43:
fs::OpenOptions::new().write(true).truncate(true).create(true).open(&lock_path) failed with No such file or directory (os error 2)
stack backtrace:
   0:   0xf306d0 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::hc18560b2598d9e23
   1:   0xf5e460 - core::fmt::write::h1d71005846ea8a6f
   2:   0xf2b7f0 - std::io::Write::write_fmt::h0ee65933c12a137e
   3:   0xf30564 - std::sys::backtrace::BacktraceLock::print::h12961e334efd2170
   4:   0xf31ee4 - std::panicking::default_hook::{{closure}}::h5a0b1665890f1cc2
   5:   0xf31cdc - std::panicking::default_hook::h314f25ba09977fe2
   6:   0xf32634 - std::panicking::rust_panic_with_hook::hbfa151c65a0e5210
   7:   0xf32324 - std::panicking::begin_panic_handler::{{closure}}::h97bdd921809c6f05
   8:   0xf30c40 - std::sys::backtrace::__rust_end_short_backtrace::hf1a1e2e30f5a34d8
   9:   0xf3204c - rust_begin_unwind
  10:   0x45d1a4 - core::panicking::panic_fmt::hf8aa1f743ac38530
  11:   0x462e80 - bootstrap::main::h7df149a85fdac2da
                       at /var/tmp/portage/dev-lang/rust-1.85.0_beta/work/rustc-beta-src/src/bootstrap/src/bin/main.rs:38:43
  12:   0x462084 - core::ops::function::FnOnce::call_once::he4f8c341d28a4588
                       at /rustc/9fc6b43126469e3858e2fe86cafb4f0fd5068869/library/core/src/ops/function.rs:250:5
  13:   0x466904 - std::sys::backtrace::__rust_begin_short_backtrace::h8b2447e5dd3de0c0
                       at /rustc/9fc6b43126469e3858e2fe86cafb4f0fd5068869/library/std/src/sys/backtrace.rs:154:18
  14:   0x461e18 - std::rt::lang_start::{{closure}}::hfef738705190f40a
                       at /rustc/9fc6b43126469e3858e2fe86cafb4f0fd5068869/library/std/src/rt.rs:195:18
  15:   0xf2137c - std::rt::lang_start_internal::h5a47ea8ee334112b
  16:   0x461df0 - std::rt::lang_start::h501fb101ec03ed78
                       at /rustc/9fc6b43126469e3858e2fe86cafb4f0fd5068869/library/std/src/rt.rs:194:17
  17:   0x464670 - main

[stefson]

If I update cc-rs locally, the error is more verbose:

running: /var/tmp/portage/dev-lang/rust-1.85.0_beta/work/rustc-beta-src/build/bootstrap/debug/bootstrap build -vv --config=/var/tmp/portage/dev-lang/rust-1.85.0_beta/work/rustc-beta-src/config.toml -j12
WARNING: The `change-id` is missing in the `config.toml`. This means that you will not be able to track the major changes made to the bootstrap configurations.
NOTE: to silence this warning, add `change-id = 134650` at the top of `config.toml`
finding compilers


error occurred in cc-rs: unknown target `x86_64-gentoo-linux-musl`.

NOTE: `cc-rs` only supports a fixed set of targets when not in a build script.
- If adding a new target, you will need to fork of `cc-rs` until the target
  has landed on nightly and the auto-generated list has been updated. See also
  the `rustc` dev guide on adding a new target:
  https://rustc-dev-guide.rust-lang.org/building/new-target.html
- If using a custom target, prefer to upstream it to `rustc` if possible,
  otherwise open an issue with `cc-rs`:
  https://github.com/rust-lang/cc-rs/issues/new

so yeah, this is how I ended up here :D

[stefson]

@NobodyXu is it correct to add my custom target to src/target/generated.rs?

[NobodyXu]

@NobodyXu is it correct to add my custom target to src/target/generated.rs?

No it's an automatic generated file.

[moonheart08]

@NobodyXu is it correct to add my custom target to src/target/generated.rs?

No it's an automatic generated file.

It is incorrect to keep a generated list of all "valid" target triples, and you should parse the target triple information instead as to not break assorted embedded vendored or os vendored compilers that bring their own platform triples.

[ChrisDenton]

I believe this is a dup of #1317