libpython missing

[CowKeyMan]

libpython should be left in the environment. This is useful for us developing c libraries with python bindings. And in fact python expects this as well (look at the not found line below):

(myenv) username@device:/opt/pyenvs$ which python
/opt/pyenvs/myenv/bin/python
(myenv) username@device:/opt/pyenvs$ ldd /opt/pyenvs/myenv/bin/python
        linux-vdso.so.1 (0x00007ffc04b9d000)
        /opt/pyenvs/myenv/bin/../lib/libpython3.11.so.1.0 => not found
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fbf79aec000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fbf79ae7000)
        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fbf79ae2000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fbf799fb000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fbf799f4000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbf797cb000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fbf79b0e000)

Right now, it is instead being put in: ${HOME}.local/share/uv/python/cpython-3.11.9-linux-x86_64-gnu/lib, which is great for and speed, but super awful for portability. Maybe there can be a flag for this? I thought the uv venv --relocatable flag would help, but it does not. Maybe a --portable flag would be good for this?

Thanks for the awesome tool otherwise!

[frederikschubert]

We are also encountering the same issue when trying to run pytriton within a uv environment.

[smheidrich]

I guess this is only an issue for the python-build-standalone binaries uv uses by default.

If you let uv create the venv with a Python binary from another source, e.g. your system Python installation or one installed via pyenv, it works just fine because they don't have a shared library dependency on libpython*.so:

$ uv venv --python /usr/bin/python3 system-py-venv
...
$ ldd system-py-venv/bin/python
	linux-vdso.so.1 (0x00007ffc870c9000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1233c94000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1233c75000)
	libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f1233c4a000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1233a69000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f1233d9f000)

Judging by the sizes of these binaries (python-build-standalone: ~2 MB, pyenv/system: ~30 MB), I guess the latter just link libpython statically.

So maybe uv should somehow find out whether the binary in question has a relative libpython*.so dependency or not and only copy/symlink libpython*.so if so?

But this issue also messes with venvs created with python-build-standalone binaries independently of uv, so here's an issue on their side to maybe do something about it:

• Creating venvs via standard library's venv.create(..., with_pip=True) fails for binaries linked against libpython dynamically python-build-standalone#381

[charliermarsh]

Is this still an issue on latest uv, if you reinstall Python?

[frederikschubert]

I can confirm that the latest version solves this issue for us! 👍

Repro for testing which failed previously but now succeeds:

Running this script with uv run --with torch --with nvidia-pytriton --isolated server.py

[nazdridoy]

no it's not solved for me

❯ source .venv/bin/activate
❯ ldd `which python`
	linux-vdso.so.1 (0x00007f030312d000)
	/home/uv/UV/Workspace/TEMP/miscProjects/uv/.venv/bin/../lib/libpython3.12.so.1.0 => not found
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f03030dd000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f03030d8000)
	libutil.so.1 => /usr/lib/libutil.so.1 (0x00007f03030d3000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007f0302fe4000)
	librt.so.1 => /usr/lib/librt.so.1 (0x00007f0302fdd000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007f0302dec000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f030312f000)

❯ uv --version
uv 0.5.16 (333f03f11 2025-01-08)

[zanieb]

❯ uv self update
info: Checking for updates...
success: Upgraded uv from v0.5.17 to v0.5.18! https://github.com/astral-sh/uv/releases/tag/0.5.18
❯ uv python install 3.13 --reinstall
Installed Python 3.13.1 in 2.37s
 ~ cpython-3.13.1-linux-x86_64-gnu
❯ uv python find 3.13
/home/zb/.local/share/uv/python/cpython-3.13.1-linux-x86_64-gnu/bin/python3.13
❯ ldd /home/zb/.local/share/uv/python/cpython-3.13.1-linux-x86_64-gnu/bin/python3.13
	linux-vdso.so.1 (0x00007b41f3d00000)
	/home/zb/.local/share/uv/python/cpython-3.13.1-linux-x86_64-gnu/bin/../lib/libpython3.13.so.1.0 (0x00007b41f2400000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007b41f3ccf000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007b41f3cca000)
	libutil.so.1 => /usr/lib/libutil.so.1 (0x00007b41f3cc5000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007b41f3bd6000)
	librt.so.1 => /usr/lib/librt.so.1 (0x00007b41f3bcf000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007b41f220f000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007b41f3d02000)
❯ uv venv -p 3.13
Using CPython 3.13.1
Creating virtual environment at: .venv
Activate with: source .venv/bin/activate
❯ ldd .venv/bin/python
	linux-vdso.so.1 (0x000076c3c32b0000)
	/fast/workspace/uv/.venv/bin/../lib/libpython3.13.so.1.0 => not found
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x000076c3c327f000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x000076c3c327a000)
	libutil.so.1 => /usr/lib/libutil.so.1 (0x000076c3c3275000)
	libm.so.6 => /usr/lib/libm.so.6 (0x000076c3c3186000)
	librt.so.1 => /usr/lib/librt.so.1 (0x000076c3c3181000)
	libc.so.6 => /usr/lib/libc.so.6 (0x000076c3c2f8e000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x000076c3c32b2000)

[zanieb]

This seems to be "as-designed" upstream https://bugs.python.org/issue43334#msg388720

[charliermarsh]

Is there anything to resolve here then? Or na?

[zanieb]

Unless someone can point to comments contrary to what I linked, yeah I think our current behavior is correct. I guess the build system should handle resolving to the upstream binary?