CMake not found in pip wheel build: fix the duplicate cmake install

A pip install of a 3D camera SDK's Python wrapper — the kind that drives 3D sensors such as laser profilers and stereo cameras — fails with a banner reading "!! CMake not found !!" while the same container runs cmake --version without complaint. The wheel never reached a compiler: pip's build step launched a cmake probe, the probe crashed, and the setup script summarized the crash as "not found". Below you get the log decoded line by line, two commands that prove which cmake copy is at fault, and the fix — one cmake owner per image — with the decision for the three cases you will meet. Fetch the SDK and its wrapper only from the camera maker's own distribution.

Why does pip report "CMake not found" when cmake --version works in the same container?

The banner lies about the failure: pip's build step did find a cmake and launched it, but the probe process died with exit code -11, and the SDK's setup script reports any failed cmake --version check as CMake not found.

Read the traceback from the bottom up. The failed phase is Getting requirements to build wheel, which runs before a single source file is compiled. Inside it, the wrapper's setup code runs a C++17 toolchain check that shells out to cmake --version. The process wait returned RuntimeError: Wait failed with exit code -11, the script translated that into RuntimeError: Process failed: 'cmake --version', and only then printed the banner. Pip's own note — the error originates from a subprocess and is likely not a problem with pip — is accurate: the environment pip built was faithful; the tool inside it crashed.

What does exit code -11 in the wheel build log mean?

A negative exit code from a Python subprocess means the child was killed by a signal, and -11 is signal 11, SIGSEGV, so a cmake binary was found, launched and crashed rather than missing.

The convention splits the failure space in two. A command that is genuinely absent comes back differently: a shell returns 127, and Python raises a file-not-found error before any process exists. A command that starts and then dies on signal 11 comes back as -11 from Python's subprocess layer and as 128 + 11 = 139 from a shell, with Segmentation fault (core dumped) on the terminal. Your log shows the second case, so the working question is never "which package do I install" — it is "which cmake did the build launch, and why did that binary crash". The copy your login shell runs was healthy the whole time; the crash belongs to a different invocation path.

Why does a second cmake appear during pip install?

Because the wheel is built from source inside an isolated environment: pip creates a temporary environment under /tmp/pip-build-env-pi44coz_/, installs the wrapper's declared build dependencies into it, and those dependencies include cmake, while the apt layer of the same image holds a second copy.

Two package managers, one command name. The apt side holds /usr/bin/cmake because the Dockerfile carries the habit line apt install cmake — a leftover from C++ work this image never does. The pip side holds its own cmake because the wrapper declares it among its dependencies, and on a system-wide install its launcher lands in /usr/local/bin, which the default PATH searches before /usr/bin.

The SDK vendor's support stated the diagnosis plainly: installing the wrapper pulls cmake from pip as well, so the image can hold two versions at once, and a system-wide wrapper install makes the pip copy system-wide too. Inside the isolated build environment the PATH differs from your login shell yet again, so the probe resolves through a third search order. The temporary directory name is random per build; the one in your log is the fingerprint. As for why the identical file built cleanly a month earlier: the file is not the only moving part, and the FAQ entry on base-image drift covers that.

How do you confirm which cmake the wheel build is using?

Run which -a cmake inside the container: it prints every cmake on PATH in launch order, and a response that lists both /usr/local/bin/cmake and /usr/bin/cmake proves the duplicate, while python3 -m pip show cmake names the copy pip owns.

Work the four checks in order:

1. Launch order: two cmake lines in the which -a output prove the duplicate.
2. Ownership and Location of the pip copy from pip show; no output means pip owns none in this environment.
3. cmake --version; echo $? in an interactive shell — exit status 0 while the build still fails puts the difference in the build environment's PATH, not your login shell.
4. Re-run the install once and read the log order: the build-dependencies line completing before the crash proves the isolated environment existed and was populated.

Decision rule: two paths in check 1 mean you apply the fix in the next section. One path with the same -11 means the duplicate is not your problem — rebuild the base layer, and if the crash survives it, treat the base image itself as broken. A log that gets past this probe and fails later on missing targets or libraries belongs to a different failure family, covered by CMake missing dependency diagnostics for vision builds.

What fix removes the duplicate cmake conflict?

Remove cmake from the image's apt install line and rebuild: the wrapper's pip dependencies bring their own working cmake, this single edit ended the reported failure, and it restores the one-owner rule that keeps the build environment predictable.

1. Delete cmake from the apt install line in the Dockerfile. Keep python3, python3-dev and python3-pip, plus whatever line fetches the SDK archives.
2. Keep the SDK packages coming from the camera maker's own download server; a mirror risks pairing the wrapper with the wrong library stack.
3. Rebuild clean with docker build --no-cache . so no cached layer preserves the old apt state.
4. Verify inside the fresh image: which -a cmake lists exactly one path, python3 -m pip list shows the wrapper at its pinned version, and importing the wrapper in Python prints its version.
5. Freeze the combination: digest-pin the base image in the FROM line and pin the wrapper with an == specifier, so the next rebuild reproduces this working pair.

This is the edit that ended the reported failure: the reporter deleted the apt cmake line, rebuilt, and the wrapper installed and imported. Nothing else in the file needed to change.

When should you keep apt's cmake instead?

Keep the apt copy only when an earlier layer genuinely builds native code with the system toolchain, and then give each build one owner: system cmake for those layers, pip's cmake confined to a virtual environment for the wrapper.

Wrapper-only image. The common camera container: the image exists to serve one SDK, so apt's cmake goes and the fix above applies.

Mixed image. If an earlier layer compiles native code, split the build into two stages: a compile stage that keeps the build tools and the system cmake, and a runtime stage that copies the artifacts across and installs only the wrapper. Each stage owns exactly one cmake and neither sees the other.

Shared host. Outside containers, give each project its own virtual environment; pip's cmake then lives inside the venv's bin directory and stops competing with /usr/bin/cmake. The environment setup behind this is covered in GPU vision Python environment compatibility checks.

Deliberate isolation drop. pip install --no-build-isolation is the escape hatch, and the FAQ entry explains why it is not the first move.

A log in which cmake runs and fails later belongs to other articles: undefined Boost targets on ARM builds in 3D camera SDK on ARM fails: CMake Boost targets undefined, OpenCV not found in samples in CMake can't find OpenCV in SDK samples: fix the config path, and link-stage faults in CMake -fPIC relocation errors when linking a vision SDK plus C++ camera SDK linking errors: diagnose CMake dependencies. Those failures mean the toolchain works; yours means it never got the chance.

How do you keep the build from breaking again next month?

Pin the three moving parts: the base image by its sha256 digest in the FROM line, the wrapper with an == version specifier, and the binary-versus-source choice itself by preferring a wheel so pip never enters the build-isolation path at all.

Read the download line to know which mode you got. A source install prints a Downloading line ending in .tar.gz followed by Installing build dependencies; a wheel install prints a .whl file and finishes without touching a compiler. pip install --only-binary=:all: makes pip refuse a source build outright instead of starting one, which is what you want in CI, where a surprise compile is a surprise failure. One cmake owner per image is the invariant that prevents this entire class of failure: decide at Dockerfile-writing time whether apt or pip owns cmake, and leave a comment on that line so the next editor knows. For the wider pinning discipline — one library version everywhere, not just the one that bit you — Docker build SDK version mismatch: pin one library version everywhere is the companion read.

Rebuilt and green again? Keep the invariant: one cmake owner, pinned base, pinned wrapper. If this rebuild is part of commissioning a laser profiler cell, the optical safety case stays in the maker's laser-safety documentation — a pip fix does not touch it.

When you are sizing the computer that runs these containers beside the cameras, the vision controllers category is the short list to work from, and the camera finder filters 3D sensors by type and series. The systems topic page collects more build and integration fixes like this one, and if you want a second pair of eyes on the Dockerfile before the next production build, send it through the contact page.