On 11/21/22 08:38, Alexander Kanavin wrote:
On Mon, 21 Nov 2022 at 15:31, Kenth Eriksson
<kenth.eriks...@infinera.com> 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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58602): https://lists.yoctoproject.org/g/yocto/message/58602
Mute This Topic: https://lists.yoctoproject.org/mt/95172718/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
