jetson-inference build fails on Ubuntu 24.04 (noble) — jetson-utils submodule out of sync

jetson-inference build fails on Ubuntu 24.04 (noble) — jetson-utils submodule out of sync

Environment

• Board: Jetson Orin (developer kit)
• JetPack: 7.2 (L4T R39.2), Ubuntu 24.04 ("noble")
• CUDA: 13.2
• Built via jetson-containers build jetson-inference (dusty-nv/jetson-containers), base image chain: l4t-pytorch → ... → gstreamer → jetson-inference
• jetson-inference cloned fresh via:
  bash复制

  git clone --recursive --depth=1 https://github.com/dusty-nv/jetson-inference $source_dir

Symptom

cmake configure fails while building the Python bindings, with the classic duplicate-target signature seen in several older closed issues (#538, #1228, #1799, #1730):

-- found Python version:  3.12 (3.12.3)
...
CMake Error at utils/cuda/FindCUDA.cmake:1809 (add_library):
  add_library cannot create target "jetson-utils-python-312" because another
  target with the same name already exists. The existing target is a shared
  library created in source directory
  "/opt/jetson-inference/utils/python/bindings". See documentation for
  policy CMP0002 for more details.
Call Stack (most recent call first):
  utils/python/bindings/CMakeLists.txt:57 (cuda_add_library)

CMake Error at utils/python/bindings/CMakeLists.txt:59 (target_link_libraries):
  Attempt to add link library "jetson-utils" to target
  "jetson-utils-python-312" which is not built in this directory.
  This is allowed only when policy CMP0079 is set to NEW.

CMake Error at utils/python/bindings/CMakeLists.txt:62 (target_link_libraries):
  Attempt to add link library "npymath" to target "jetson-utils-python-312"
  which is not built in this directory.
  This is allowed only when policy CMP0079 is set to NEW.

-- detecting Python 3.7...

The build tries a second, different requested Python version ("detecting Python 3.7...") right after a successful pass for 3.12 — same pattern as every historical instance of this bug: the PYTHON_BINDING_VERSIONS list contains multiple entries, more than one of which resolve to the same real interpreter on the host, causing a duplicate CMake target.

Root cause

dusty-nv/jetson-inference's own python/CMakeLists.txt already has the correct fix on current master:

if(LSB_RELEASE_CODENAME MATCHES "noble")
	set(PYTHON_BINDING_VERSIONS 3.12)

However, the error trace above is happening inside utils/python/bindings/CMakeLists.txt — i.e. inside the jetson-utils submodule, not the top-level jetson-inference/python/CMakeLists.txt. git clone --recursive pins jetson-utils to whatever commit the parent repo's .gitmodules/tree currently references — a specific commit hash, not jetson-utils's own master branch.

Hypothesis (not yet 100% confirmed with a diff): the pinned jetson-utils submodule commit predates the equivalent noble fix landing in jetson-utils' own python/CMakeLists.txt, so it still falls through to a stale else() branch with multiple old Python version entries (e.g. 2.7 3.6 3.7-style list) — all of which resolve to the single Python 3.12 actually present on Ubuntu 24.04, producing the duplicate target.

This exact class of bug (stale/missing LSB_RELEASE_CODENAME branch → multiple version entries collapsing onto one real interpreter) has been reported many times before for older codenames (focal, bionic) — see issues #538, #1228, #1799, #1684 — but always fixed by editing the version list for the new codename each time a new Ubuntu release ships. It looks like this happened for jetson-inference itself for noble, but the jetson-utils submodule pin wasn't bumped in lockstep.

Attempted fix (in progress)

Plan: patch utils/python/CMakeLists.txt post-clone (either locally, or as a sed step in the jetson-containers build.sh for this package) to add the same noble branch jetson-inference's own file already has:

if(LSB_RELEASE_CODENAME MATCHES "noble")
	set(PYTHON_BINDING_VERSIONS 3.12)
else()
	...  # existing list
endif()

Not yet validated end-to-end (full jetson-inference build takes ~3+ hours on this hardware, so validating the patch with just cmake .. — not the full make — before committing to a full rebuild).

Suggested upstream fix

1. Bump the jetson-utils submodule pin in dusty-nv/jetson-inference to a commit that includes the noble/Python 3.12 fix in jetson-utils/python/CMakeLists.txt, keeping both repos' codename handling in sync.
2. Longer-term: consider deriving PYTHON_BINDING_VERSIONS dynamically (e.g. from whatever python3 is actually resolved on PATH) rather than maintaining a hardcoded, codename-gated version list that needs a manual patch release-over-release as new Ubuntu versions ship.

Open question for maintainers

Can you confirm whether the jetson-utils submodule commit currently pinned by jetson-inference@master predates the noble fix in jetson-utils/python/CMakeLists.txt? If so, a submodule bump alone should resolve this without needing any local patching.