std::env::args_os always returns an empty iterator in a musl+gcompat environment about rust HOT 13 CLOSED

We should probably just unconditionally call really_init.

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

from rust.

uh.

from rust.

@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?

from rust.

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.

from rust.

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

from rust.

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

from rust.

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.

from rust.

Apparently we already have this comment:

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.

from rust.

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

from rust.

@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.

from rust.

One other thought: if we initialize arguments this way, we don't also need to initialize them in our main function in binaries. Can you compile out that code on linux-gnu?

— @joshtriplett in #66547 (review)

Well, given the remarks here seem to position this as a "wouldn't it be nice if we didn't do extra work?" and that this seems to be non-resilient in practice, as it has caused more than one open issue, I think we should be unafraid of doing a bit of extra computation.

from rust.

I more meant that the fact that libraries mess about with (what should be) immutable memory is a safety issue so ideally we would parse it at the point where it's least likely that the are multiple threads. But people would probably complain about doing unnecessary allocating and extra work pre-main.

Just storing argc and argv should be cheap though so I'm definitely not arguing against that.

from rust.

the dilemma: strictly conforming posix programs shouldn't mutate argc and argv, but strictly conforming posix programs also shouldn't be aware of argc and argv if if they're dylibs, eh?

from rust.