Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support alternative platform detection mechanisms other than reading /bin/ls #1395

Closed
robin-nitrokey opened this issue Feb 16, 2024 · 3 comments · Fixed by #1433 or #1493
Closed

Support alternative platform detection mechanisms other than reading /bin/ls #1395

robin-nitrokey opened this issue Feb 16, 2024 · 3 comments · Fixed by #1433 or #1493
Labels
bug Something isn't working

Comments

@robin-nitrokey
Copy link
Contributor

The find_libc function that is used to determine whether uv is running on musllinux or manylinux tries to read /bin/ls:

/// Find musl libc path from executable's ELF header.
fn find_libc() -> Result<PathBuf, PlatformError> {
let buffer = fs::read("/bin/ls")?;
let error_str = "Couldn't parse /bin/ls for detecting the ld version";
let elf = Elf::parse(&buffer)
.map_err(|err| PlatformError::OsVersionDetectionError(format!("{error_str}: {err}")))?;
if let Some(elf_interpreter) = elf.interpreter {
Ok(PathBuf::from(elf_interpreter))
} else {
Err(PlatformError::OsVersionDetectionError(
error_str.to_string(),
))
}
}

If /bin/ls does not exist, uv cannot be run. This is the case namely on NixOS which does not follow the Filesystem Hierarchy Standard. I understand that this is a special case, but it would be great if you would provide a way to skip this check, e. g. by setting an environment variable (or maybe using /bin/sh instead which is available on NixOS).

@zanieb zanieb added the bug Something isn't working label Feb 16, 2024
@zanieb
Copy link
Member

zanieb commented Feb 16, 2024

Thanks for the clear report!

@zanieb
Copy link
Member

zanieb commented Feb 16, 2024

If you patch this to read /bin/sh does it "just work"?

@robin-nitrokey
Copy link
Contributor Author

Yes, with /bin/sh it works for me.

BurntSushi pushed a commit that referenced this issue Feb 16, 2024
…path (#1433)

I'm not sure if we should just switch to _always_ reading from sh
instead? I don't love that all these errors are strings and I if
`/bin/ls` exists but can't be parsed we still won't try `/bin/sh`. We
may want to address these things in the future.

Closes #1395
BurntSushi added a commit that referenced this issue Feb 16, 2024
It turns out that /bin/ls can sometimes be plain text file. For
example, in Rocky Linux 9:

```
$ cat /bin/ls
#!/usr/bin/coreutils --coreutils-prog-shebang=ls
```

However, `/bin/sh` is an ELF binary:

```
$ file /bin/sh
/bin/sh: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=7acbb41bf6f1b7d977f1b44675bf3ed213776835, for GNU/Linux 3.2.0, stripped
```

In a related issue (#1433), @zanieb fixed #1395 where, on NixOS,
`/bin/ls` doesn't exist but `/bin/sh` does. However, the fix attempts
`/bin/ls` first and only tries `/bin/sh` if `/bin/ls` doesn't exist. If
`/bin/ls` exists but isn't a valid ELF file, then the entire enterprise
gives up and `uv` fails to detect the version of `libc` that is
installed.

Instead of tweaking the logic to keep trying `/bin/ls` and then
`/bin/sh` after even if parsing `/bin/ls` fails, we just switch over to
reading `/bin/sh` only. It seems like a more fundamental thing to sniff
and likely less error prone.

We can adjust this heuristic as needed if it provdes to be problematic.

I tested this fix manually on Rocky Linux 9 via Docker:

```
$ cross b -r -p uv --target x86_64-unknown-linux-musl
$ cp target/x86_64-unknown-linux-musl/release/uv ~/astral/issues/uv/i1486/uv
$ docker run --rm -it --mount type=bind,src=/home/andrew/astral/issues/uv/i1486,dst=/host rockylinux:9 bash
[root@df2baa65d2f8 /]# /host/uv venv
Using Python 3.9.18 interpreter at /usr/bin/python3.9
Creating virtualenv at: .venv
[root@df2baa65d2f8 /]#
```

Fixes #1486, Ref #1433
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
2 participants