Binaries builds with Nuitka from a uv-installed Python fails on Ubuntu: libpython3.13.so.1.0 not found

[kdeldycke]

Tl;Dr: System Python installed by actions/setup-python is working but not the Python installed by uv.

I made up a simple project to demonstrate this issue: https://github.com/kdeldycke/nuitka-issue-3325

Works with actions/setup-python

This project is a simple CLI compiled to a standalone binary on all major platforms (Ubuntu, macOS and Windows) and 2 different architectures (x86_64 and arm64).

This is performed by a GitHub workflow available at: https://github.com/kdeldycke/nuitka-issue-3325/blob/main/.github/workflows/system-python.yaml

The process works perfectly on all platforms.

Note that in the logs, Nuitka is picking the right Python version from the system:

Nuitka: Starting Python compilation with Nuitka '2.6.4' on Python (flavor GitHub Actions Python), '3.13' commercial grade 'not installed'.

Issue with uv

Now let's modify the working workflow used above, and completely remove the use of actions/setup-python. Instead, we will rely on uv alone to install our target Python version, by invoking:

$ uv venv --python 3.13

That new workflow is available at: https://github.com/kdeldycke/nuitka-issue-3325/blob/main/.github/workflows/uv-python.yaml

Here is an explicit highlight of the differences between the two workflows:

$ diff -ru ./.github/workflows/system-python.yaml ./.github/workflows/uv-python.yaml        
--- ./.github/workflows/system-python.yaml	2025-02-03 10:49:36
+++ ./.github/workflows/uv-python.yaml	2025-02-03 10:49:36
@@ -6,7 +6,7 @@
 
 jobs:
 
-  system-python:
+  uv-python:
     strategy:
       matrix:
         os:
@@ -19,15 +19,12 @@
     continue-on-error: true
     steps:
       - uses: actions/checkout@v4.2.2
-      - uses: actions/setup-python@v5.4.0
-        with:
-          python-version: "3.13"
       - name: Install uv
         run: |
           python -m pip install "uv == 0.5.28"
       - name: Install Nuitka
         run: |
-          uv --no-progress venv
+          uv --no-progress venv --python 3.13
           uv --no-progress pip install "nuitka == 2.6.4"
 
       - name: uv run -m nuitka --version

Despite these differences, I expect no change in the results. But this is not the case as you can see in this run: https://github.com/kdeldycke/nuitka-issue-3325/actions/runs/13151107465

All the Ubuntu builds fail. The binary is still produced on these platforms, but running them ends up with this error message:

my-cli-ubuntu-24.04.bin: error while loading shared libraries: libpython3.13.so.1.0: cannot open shared object file: No such file or directory

Note that in this case, Nuitka properly reports the Python 3.13 flavor as sourced from uv:

Nuitka: Starting Python compilation with Nuitka '2.6.4' on Python (flavor UV-Python), '3.13' commercial grade 'not installed'.

Context

This has been tested with:

• Latest nuitka: 2.6.4
• Latest uv: 0.5.28
• Latest Python: 3.13
• Latest actions/setup-python: 5.4.0

This issue has also been reported at: Nuitka/Nuitka#3325

[kdeldycke]

I don't know much about the whole Python builds toolchain (that's why I love uv and nuitka because they make my life easy), but is this possible that this issue is related to:

• Can't compile Meson extensions against managed Python due to pkg-config #11028
• Make the installed pkg-config files relocatable (astral-sh/uv#11028) python-build-standalone#507
• libpython missing #6812
• Can't uv run a simple script when Python binary is a symlink with uv 0.5.x #10674
• venv base path does not resolve symlinks using realpath() python/cpython#106045
• [bug] Can't build Rust extensions via pyo3 if using a uv-managed Python interpreter #10598
• uv Standalone Python Build Breaking Program Built with Nuitka #10555

[kdeldycke]

Also note this warning from the Nuitka project regarding uv-managed Python:

Nuitka/Nuitka@f5e7640#diff-940a5fc082e89e5397d5015ec587ebed5409309cf2ebe9faad105a9ca74918a7R1740

[geofft]

Sigh - this is the ldd bug discussed in #6812. Looks like Nuitka uses ldd to figure out what libraries are needed. Let me see if I can send Nuitka a PR to work around this....

A kind of terrible workaround is

LD_LIBRARY_PATH=$(dirname "$(realpath "$(uv python find)")")/../lib uv run nuitka --onefile ...

which you only need for the Nuitka build step (because that will trick ldd as invoked by Nuitka into doing the right thing (at which point Nuitka will find libpython and embedd it into your --onefile binary, so you don't need it when actually running the binary).

[geofft]

Actually, no, this is Nuitka not knowing we need an rpath (which is probably reasonable, there's not yet a really good way for us to tell a downstream build system that). Let me continue over on Nuitka/Nuitka#3325.