std::env::args_os always returns an empty iterator in a musl+gcompat environment

[rjsberry]

I tried this code in Alpine Linux cross compiled to x86_64-unknown-linux-gnu:

use std::env;

fn main() {
    println!("{:?}", env::args_os().collect::<Vec<_>>());
}

For reference I ran this in a container on an M1 Macbook:

$ docker run --rm -it --platform linux/amd64 alpine
# apk add gcompat libgcc

I always see [] printed, even when I pass the program arguments.

I'm not sure this is an issue with the environment as the following C program works as expected:

#include <stdio.h>

int main(int argc, char **argv) {
    for (int i = 0; i < argc; i++) {
        printf("%d: %s\n", i, argv[i]);
    }
}

Meta

rustc +nightly --version --verbose:

rustc 1.79.0-nightly (becebb315 2024-04-17)
binary: rustc
commit-hash: becebb3158149a115cad8a402612e25436a7e37b
commit-date: 2024-04-17
host: aarch64-apple-darwin
release: 1.79.0-nightly
LLVM version: 18.1.3

[workingjubilee]

uh.

[workingjubilee]

@rjsberry Could you clarify: Does this problem arise with code ran on an ordinary gnu system? Say, a Debian container? Or x86_64-unknown-linux-musl itself?

[ChrisDenton]

I can take a guess at why this happens. For glibc targets we assume that the arguments can be retrieved without needing to store argc and argv. However if this musl compatibility layer doesn't use the .init_array then we can't retrieve them.

[workingjubilee]

Ah yeah, it seems that behavior is a GNU extension that Rich Felker doesn't want to support?

[workingjubilee]

Does env::args() just not work at all on musl if we're a cdylib, then?

[bjorn3]

Correct. When libstd's start function isn't used, env::args() only works on Windows, macOS and Linux with Glibc. On any other target it returns an empty list.

[workingjubilee]

Apparently we already have this comment:

rust/library/std/src/sys/pal/unix/args.rs

Lines 101 to 107 in 07d0d7c

	pub unsafe fn init(_argc: isize, _argv: *const *const u8) {
	// On Linux-GNU, we rely on `ARGV_INIT_ARRAY` below to initialize
	// `ARGC` and `ARGV`. But in Miri that does not actually happen so we
	// still initialize here.
	#[cfg(any(miri, not(all(target_os = "linux", target_env = "gnu"))))]
	really_init(_argc, _argv);
	}

In other words, we are already hacking around this issue for the miri emulator, and not using the fact that we are still given argv "naturally" via execve.

We should probably just unconditionally call really_init.

[bjorn3]

We should probably just unconditionally call really_init.

That would fix rust-lang/rustc_codegen_cranelift#1048 on Linux + glibc too.

[ChrisDenton]

Note that this was intentionally done #66547 but there have been other issues #105999

[workingjubilee]

@ChrisDenton I still think we can consider #105999 to still be fixed, as we just get our char **argv and it will be the same thing, even if the char*s behind the char** have been rearranged, right? So we'll set the atomics twice to the same value, which sounds very Working As Intended.