On 11/21/22 08:38, Alexander Kanavin wrote:

On Mon, 21 Nov 2022 at 15:31, Kenth Eriksson
<kenth.eriksson@...> wrote:

Having trouble with reproducible builds in yocto on dunfell release with musl as libc. E.g. I can see that the build path for musl crti assembler file is leaking through and becomes visible when I do strings on libraries and binaries.

$ strings /opt/infn-xr/1.0/sysroots/aarch64-xr-linux-musl/usr/lib64/.debug/libcrypto.so.1.1 | grep crt[a-z]\.o
/data/jenkins/workspace/XR_yocto-xr_master/build/build/infn-xr/gmcu/tmp/work/aarch64-xr-linux-musl/openssl/1.1.1l-r0/recipe-sysroot/usr/lib64/crti.o
/data/jenkins/workspace/XR_yocto-xr_master/build/build/infn-xr/gmcu/tmp/work/aarch64-xr-linux-musl/openssl/1.1.1l-r0/recipe-sysroot/usr/lib64/crtn.o
$

Is this a known issue? Yocto passes -fmacro-prefix-map and -fdebug-prefix-map as part of DEBUG_PREFIX_MAP to eliminate paths to WORKDIR. But it looks as that fails for the musl assembler file?

Testing reproducibility properly is a heavy exercise (you need to
build everything from scratch, then compare), and so we do it only for
glibc.

There have been recent fixes and tests to check that host paths do not
leak into target files, but dunfell probably has neither the fix nor
the test.

This is correct; it's hard for upstream to test every possible combination for reproducibility. We do try to get some decent coverage, but ultimately if you really care about reproducible builds, you should setup a reproducible build test for your exact combination. We've tried to make this pretty easy, see https://youtu.be/zXEdqGS62Wc?t=1021

Alex