libc error

[sammy-ette]

after following the getting started guide and just making a new project cargo 3ds new and trying to build it gives me this error:

$ cargo 3ds build
   Compiling std v0.0.0 (/home/sammyette/.local/share/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std)
error[E0425]: cannot find value `_SC_HOST_NAME_MAX` in crate `libc`
 --> /home/sammyette/.local/share/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/net/hostname/unix.rs:8:60
  |
8 | ...nf(libc::_SC_HOST_NAME_MAX) } {
  |             ^^^^^^^^^^^^^^^^^ not found in `libc`

For more information about this error, try `rustc --explain E0425`.
error: could not compile `std` (lib) due to 1 previous error

[arturacruz]

I am having the same problem. Looking at the PRs in the Rust Nightly, I assume it's an error from devkit's libc, and since the rust PR was closed, this is not gonna be fixed soon. Is there a workaround?
Rolling back the nightly version works, but then rust-analyzer just completely crashes out.

[FenrirWolf]

Yeah, it's a known issue with a lot of tier 3 platforms right now. There's a new API in nightly rust that makes use of some constants that were never added to the libc crate for newlib targets whatever reason. I've been meaning to make a PR to libc to fix that. Then after that we'd need to make a PR to std updating the libc version

[FenrirWolf]

Rolling back the nightly version works, but then rust-analyzer just completely crashes out.

I'm currently on rustc 1.90.0-nightly (b56aaec52 2025-07-24) and rust-analyzer has been working fine for me. Did you cargo clean after reverting the nightly version?

[arturacruz]

Yeah, but it's probably something more specific. In vscode it works fine, but not on neovim (that I use). Not a problem for this PR.
About the error, a PR to libc will probably take a long time to be accepted. Any workaround to all this besides using an old nightly version in the meanwhile?

[Meziu]

Linking rust-lang/rust#147213 since ESP-IDF targets have always been developed closely to our toolchain.

I need to research whether we we can get that value somewhere from newlib or to just default to something else. gethostname is available so we should try supporting it.

[FenrirWolf]

Those symbols do exist in newlib (see https://github.com/bminor/newlib/blob/master/newlib/libc/include/sys/unistd.h#L429 for reference). They just didn't get included in the libc crate for newlib targets for whatever reason.

[FenrirWolf]

I've opened a PR to libc here: rust-lang/libc#4811