Build-machine absolute paths leak into the shipped binary's RUNPATH, masking missing bundled libs

[takusaito-ctrl]

Environment: linux-arm64 (Raspberry Pi) · CMake 3.28.3 · SDK V2.02.00

Summary

CameraWebApp ships with the build machine's absolute source-tree paths baked into its RUNPATH, and those paths ride along into the .mcpb. The distributed bundle therefore contains a hardcoded pointer back to whoever built it.

$ readelf -d api/server/build/CameraWebApp | grep RUNPATH
RUNPATH: [$ORIGIN:/home/<user>/Desktop/Github/alpha-sdk-api/shared/sdk/lib:
                  /home/<user>/Desktop/Github/alpha-sdk-api/shared/opencv/Linux:]

This is not what CMakeLists asks for

api/server/CMakeLists.txt:88-93 already requests $ORIGIN only:

elseif(UNIX)
    set_target_properties(${WEBAPP_TARGET} PROPERTIES
        BUILD_RPATH "$ORIGIN"
        INSTALL_RPATH "$ORIGIN"
    )
endif()

The extra entries are CMake's automatic build-tree RPATH: because the target links libCr_Core.so and the OpenCV libs by absolute path, CMake appends their containing directories. The explicit $ORIGIN is prepended, not substituted.

Why the entries are pure redundancy

The build already copies every runtime lib next to the binary via POST_BUILD (CMakeLists.txt:153-163), so api/server/build/ is self-contained:

api/server/build/libCr_Core.so
api/server/build/libmonitor_protocol.so
api/server/build/libmonitor_protocol_pf.so
api/server/build/libopencv_{core,highgui,imgcodecs,imgproc}.so.408
api/server/build/CrAdapter/{libCr_PTP_IP,libCr_PTP_USB,libssh2,libusb-1.0}.so

$ORIGIN alone already resolves everything, in the build tree and in the bundle. Nothing depends on the absolute paths.

Impact

1. It hides missing bundled libraries — this is the real cost. This is exactly why #33 went unnoticed for so long: the loader tried $ORIGIN, missed, fell through to the build machine's checkout, and succeeded. Every test on the build machine passed while the shipped bundle was broken for everyone else (exit 127 in the loader, before main()). Any library dropped from the bundle in future will hide the same way. The linksOpenCv() guard added in #51 only covers OpenCV specifically; it does not address the general blindness.

2. It leaks the builder's username and directory layout in every distributed copy.

3. Load-order surprise. On a machine that happens to have those paths — same username with a clone in the same location — the binary silently prefers the source tree's libs over the bundled ones, with no indication. A user could run a different OpenCV than was shipped.

Suggested fix

Set BUILD_WITH_INSTALL_RPATH on the target so the build-tree link uses INSTALL_RPATH directly and CMake skips computing the automatic build RPATH. Since the libs are already co-located, the dev workflow is unaffected.

macOS

Very likely the same leak — BUILD_RPATH "@executable_path" (line 86) gets the same automatic augmentation, and there is no INSTALL_RPATH set there at all. Not verified, no macOS hardware here. Worth confirming separately before changing, given the recent CrAdapter path fix (4e1927a) makes that platform delicate.