Yocto Package QA: Fix Build-Path Leakage Instead of Silencing the Warning

A package can run correctly on the target while still carrying an absolute path from the build server. The path might be a harmless-looking diagnostic string, a source location in debug information, or a generated configuration value that will fail later. A buildpaths warning identifies the leaked bytes, but the repair depends on how those bytes entered the file.

In Yocto embedded Linux development, fix the producer of the path before suppressing the check. This article follows Yocto Project 5.0.12 and uses GCC 13.3 documentation for macro path mapping.

Classify the occurrence before choosing a compiler flag

The QA message reference describes buildpaths as detecting build-system path references in packaged output. Start with the exact package and pathname in the warning. Inspect that file in the packaging output, not a similarly named executable left in an earlier build directory.

For text, examine the surrounding setting or generated comment. For an ELF file, use the target-compatible inspection tools to distinguish debug records, ordinary string data, and dynamic-loader paths. A plain string search is a useful locator, but it cannot establish what the matching bytes mean at runtime.

A build directory in an RPATH requires a linker or build-system repair. A generated configuration file containing the source checkout directory requires a generator or configuration repair. Applying a debug-prefix flag to either case may leave the actual defect untouched.

Check whether the supplied flags reached this compilation

Yocto's DEBUG_PREFIX_MAP reference explains the compiler prefix-mapping options used for location-independent output. The variable is set by the build system and is not intended as a user configuration knob.

Inspect the actual compiler command in log.do_compile for the object that contains the path. Compare it with the effective recipe flags. A custom Makefile that overwrites CFLAGS, invokes a different compiler, or compiles one helper through an ad hoc rule can bypass flags that other files receive correctly.

Repair that rule to honor the toolchain and flags passed by the recipe. Avoid replacing the entire flag set with one mapping option, since the original set also carries architecture and other required settings. Then inspect the rebuilt object before it is linked, which narrows the search if the final executable still contains the path.

Distinguish macro expansion from generated string literals

The GCC macro-prefix option changes paths produced by __FILE__, __BASE_FILE__, and __builtin_FILE(). That is different from a script writing an absolute directory into a C string literal before the compiler runs.

For example, a generator might emit a diagnostic field whose value is the current source directory. Even with correct compiler flags, that literal remains application data. Change the generator to emit a stable relative identifier if the field is only descriptive. If the program genuinely needs a runtime resource directory, supply an appropriate target path or runtime configuration instead.

Keep the meaning of the field intact. Blindly replacing every occurrence of the build prefix with an empty string can produce malformed paths or hide a legitimate lookup requirement. The desired replacement depends on whether the consumer expects a source label, an installation location, or a runtime-discovered resource.

Verify the repaired cause with a changed build location

Rerun the affected packaging and QA path, and inspect the same file role again. Include its debug companion if the original finding was there. Removing debug information solely to hide a path trades away debugging capability and does not explain why mapping failed.

For a stronger location-independence check, build the relevant component from two different absolute build roots with equivalent inputs. Ensure the comparison actually recompiles the affected output rather than restoring the same cached result into both locations. Compare the outputs and investigate remaining differences; two clean buildpaths checks alone do not prove complete reproducibility.

The successful repair is causal: a missing flag now reaches its compiler invocation, a generator no longer serializes its working directory, or a target setting no longer contains a host location. That explanation remains useful when the upstream build system changes again.