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

Couldn't parse /bin/sh for detecting the ld version #1810

Closed
Ch3ri0ur opened this issue Feb 21, 2024 · 0 comments · Fixed by #1818
Closed

Couldn't parse /bin/sh for detecting the ld version #1810

Ch3ri0ur opened this issue Feb 21, 2024 · 0 comments · Fixed by #1818
Assignees
Labels
bug Something isn't working

Comments

@Ch3ri0ur
Copy link

When I try to use uv venv I get:

uv venv
  × Failed to detect the operating system version: Couldn't parse /bin/sh for detecting the ld version: Invalid magic
  │ number: 0x642f6e69622f2123

I am on a wsl x86 ubuntu 22.04 variant from my company.
uv --version => uv 0.1.6

I took a look at our /bin/sh:
It looks like my company replaced the usual symlink to dash with:

#!/bin/dash

# some proxy exports

dash "$@"

I just wanted to mention that. Apparently one can not rely on anything. :-)

Thanks for your effort and keep up the good work!

@BurntSushi BurntSushi self-assigned this Feb 21, 2024
BurntSushi added a commit that referenced this issue Feb 21, 2024
Previously, we were only checking /bin/sh. While that works in most
cases, it seems like there are still scenarios where /bin/sh isn't an
executable itself, and is instead just a shell script that calls
/bin/dash. (See #1810 for example.)

In this PR, we make the `ld` detection a bit more robust by trying
multiple paths. As with previous changes, we emit copious logs to help
debug this in the future.

It's not totally clear how to test this. I'm not sure how to reproduce
the environment mentions in #1810 specifically since it seems like an
internal variant of WSL Ubuntu.

Fixes #1810
BurntSushi added a commit that referenced this issue Feb 21, 2024
Previously, we were only checking /bin/sh. While that works in most
cases, it seems like there are still scenarios where /bin/sh isn't an
executable itself, and is instead just a shell script that calls
/bin/dash. (See #1810 for example.)

In this PR, we make the `ld` detection a bit more robust by trying
multiple paths. As with previous changes, we emit copious logs to help
debug this in the future.

It's not totally clear how to test this. I'm not sure how to reproduce
the environment mentions in #1810 specifically since it seems like an
internal variant of WSL Ubuntu.

Fixes #1810
BurntSushi added a commit that referenced this issue Feb 21, 2024
Previously, we were only checking /bin/sh. While that works in most
cases, it seems like there are still scenarios where /bin/sh isn't an
executable itself, and is instead just a shell script that calls
/bin/dash. (See #1810 for example.)

In this PR, we make the `ld` detection a bit more robust by trying
multiple paths. As with previous changes, we emit copious logs to help
debug this in the future.

It's not totally clear how to test this. I'm not sure how to reproduce
the environment mentions in #1810 specifically since it seems like an
internal variant of WSL Ubuntu.

Fixes #1810
@BurntSushi BurntSushi added the bug Something isn't working label Feb 21, 2024
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
Development

Successfully merging a pull request may close this issue.

2 participants