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