Yocto Runtime Library Paths: Diagnose rpaths and useless-rpaths Separately

A Yocto package reports rpaths after a successful link. Another reports useless-rpaths. These findings describe different conditions, and a blanket suppression hides the evidence needed to distinguish them.

The important boundary is the packaged ELF file. A temporary build-tree search path may be intentional during compilation but inappropriate after installation. Diagnose the QA predicate and the installation transition together.

Read the exact check that produced the finding

The Yocto QA reference distinguishes build-system paths in runtime metadata from redundant standard-library paths. Its recommended starting point for a bad runtime path is the linker command and its flags.

The examined Scarthgap insane class implementation is more specific:

• Both functions inspect non-symlink ELF files and parse RPATH lines from objdump output.
• The rpaths check searches the captured string for BASE_WORKDIR or STAGING_DIR_TARGET as substrings.
• The useless-rpaths check normalizes the entire captured string and compares it with libdir and base_libdir.

This implementation does not split a colon-separated string into entries for the latter comparison. Its regex also does not match a RUNPATH line. Those are boundaries of the examined checks, not reasons to preserve undesirable paths that happen to evade them.

For the failing recipe, obtain the effective values of those four directory variables. Match the diagnostic's filename to the file under the corresponding split package, rather than inspecting a similarly named executable left in the build directory.

Compare build and installed files

CMake illustrates why the same target can legitimately have different path metadata at two stages. Its BUILD_RPATH reference describes automatically selected build-tree search paths and optional additional entries. These build-tree paths normally give way to installation settings.

The INSTALL_RPATH reference describes editing or relinking targets during installation. The install property defaults to empty, but projects can set it explicitly or populate it through other CMake settings.

Consequently, a recipe that manually copies a linked executable from B into D may bypass the project's installation-time correction. This is a diagnostic inference from CMake's lifecycle, not a claim that every copy operation is wrong. Inspect do_install before trying another linker flag.

Compare the same target at three locations: the build output, the staged installation under D, and the split package named by QA. Use the cross-toolchain objdump with -p and inspect both RPATH and RUNPATH entries. Substitute each actual filename; no particular output is assumed here.

Correct the first unwanted transition

If the build file contains a work-directory path and the installed file retains it, inspect whether the maintained CMake install rules ran. Restore the supported installation route where practical. If installation ran but produced the wrong value, inspect the target's install property and generated installation script.

CMake initializes INSTALL_RPATH from CMAKE_INSTALL_RPATH when the target is created. Setting the initialization variable after creating the target may therefore fail to change that target. Inspect the effective target property instead of concluding that a cache assignment necessarily controlled every executable.

If the installed file is correct but the split package differs, trace later recipe hooks or copy operations. A post-install substitution can reintroduce an older build artifact even when CMake behaved correctly.

For a redundant standard-directory value, locate the project setting or link flag that adds it and remove the unnecessary entry. Do not replace it with an arbitrary private directory just to change the warning category.

Check the repair beyond the narrow predicate

Rebuild the affected installation and packaging tasks through BitBake, then inspect the resulting packaged ELF again. Check that the intended installation transition occurred and that neither runtime-path tag contains build-only locations.

A passing QA task establishes only that its enabled checks found no violation. It does not certify every runtime-path entry, every tag or the application's library-loading behavior. Keep functional library-discovery testing separate, while making the packaging repair precise enough to explain why the original finding disappeared.