Reproducible builds bug reported to Rust compiler as https://github.com/rust-lang/rust/issues/97955
Richard Purdie
richard.purdie at linuxfoundation.org
Sat Jun 11 09:54:14 UTC 2022
On Sat, 2022-06-11 at 11:39 +0200, Jelle van der Waa wrote:
> Hey,
>
> On 10/06/2022 19:55, Richard Purdie wrote:
> > On Fri, 2022-06-10 at 13:52 -0400, David A. Wheeler wrote:
> > > All, FYI:
> > >
> > > The current LLVM-based Rust compiler generates builds that
> > > aren't (easily) reproducible, at least in part because full paths
> > > to the source code is in the panic and debug strings recorded in
> > > the generated executable. I was made aware of this via bunny's
> > > "Rust: A Critical Retrospective" <https://www.bunniestudios.com/blog/?p=6375>.
>
> Yes, this is the case if you share a debug build with someone. I'd say
> this not that bad. GCC by default also suffers from this issue, just
> make any debug build and the path will be included:
>
> [jelle at t14s][/tmp/dontincludethisdir]%gcc -lhidapi-hidraw
> -I/usr/include/hidapi -ggdb ../foo.c -o test
> [jelle at t14s][/tmp/dontincludethisdir]%strings test| grep dontincl
> /tmp/dontincludethisdir
>
> In practice you want to reproduce a production release builds which
> strip this information.
That isn't strictly true, you can also map things to the target
locations. In Yocto Project/OpenEmbedded we use something like:
DEBUG_PREFIX_MAP = " \
-fmacro-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
-fdebug-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
-fdebug-prefix-map=${STAGING_DIR_HOST}= \
-fdebug-prefix-map=${STAGING_DIR_NATIVE}= \
"
which maps our build paths to our target system paths. We put the
source in to /usr/src/debug/XXX in our debug packages. This way you get
fully reproducible sources, reproducible packages, small target
packages yet full debug info available too.
I think newer gcc has simplified this a bit, we use the above since
there used to be issues where both macro-prefix-map and debug-prefix-
map were needed.
Cheers,
Richard
More information about the rb-general
mailing list