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

[TimTheBig]

When do you think the new version of libc with the PR will make it into nightly?

[FenrirWolf]

I'm not sure. They apparently have some kind of automated infrastructure that's supposed to cut releases in some way, but I think it's tied to their CI pipeline and that all seems to be broken currently.

[FenrirWolf]

the libc changes are now live in https://github.com/rust-lang/libc/releases/tag/0.2.178

now we just have to update the version used by std and we'll be back in business

[jedenastka]

Issue on the rustc/std repo: rust-lang/rust#147437 (technically for Vita but same issue in terms of broken libc)

Apparently the new libc version has a regression so this will take more time.

[pheki]

Hey, apparently that regression only blocks compilation when you're compiling in the rust-lang/rust repo. When just using the compiler that lint is capped, more details on this comment. Sorry, that's on me (I'm the one who originally reported the regression).

std's libc dependency has since been updated to 0.2.178 and it does seem to be compiling correctly since 2025-12-10, can someone check if latest nightly is working fine for the 3DS?

[jedenastka]

std's libc dependency has since been updated to 0.2.178 and it does seem to be compiling correctly since 2025-12-10, can someone check if latest nightly is working fine for the 3DS?

I was able to build and run (on real hardware) my simple 3DS project on the latest nightly.