Reproducible builds vs debugedit vs relative debug paths

[Mark Wielaard]

Hi Holger,

On Sat, Mar 28, 2026 at 02:21:27PM +0000, Holger Levsen wrote:
> On Sun, Mar 22, 2026 at 08:39:08PM +0100, Mark Wielaard wrote:
> > But then we found https://reproducible-builds.org/docs/build-path/
> > which explicitly seems to recommend using them. And has a note on
> > debugedit:
> > https://reproducible-builds.org/docs/build-path/#fn:debugedit
> > 
> >   debugedit can replace the path used at build time by a
> >   predefined one but it does that by rewriting bytes in place.
> >   As this does not reorder the hash table of strings,
> >   the resulting bytes are still depending on the original
> >   build path.
> > 
> > I wonder if that comment might be based on some older version of
> > debugedit? 
> 
> this might well be the case, this file was last touched in 2020, see
> https://salsa.debian.org/reproducible-builds/reproducible-website/-/blob/master/_docs/build_path.md?ref_type=heads

Thanks for the git repo link. I seems like the debugedit comment seems
to have been there from the start in 2015. So yes, debugedit was
basically rewritten in 2017 to do string rewrites "properly" through
rewriting the string tables.

> is there a improved wording you could suggest?

I am not sure because I don't fully understand the original comment. I
hope running debugedit --base=OLD --dest=NEW on the binaries is an
alternative to using -fdebug-prefix-map=OLD=NEW. And to discourage
having a NEW being "." or some relative path (because that has its own
troubles).
 
> > Current versions do rewrite the .debug_str and other
> > similar string tables. But maybe I am missing something else that
> > makes debugedit not deterministic in path rewriting.
> > 
> > Have people tried more modern versions of debugedit to get
> > deterministic (absolute) DWARF paths and found issues with it?
> 
> not sure, this is really not my area of expertize. Anyone else?

Please let me know how debugedit can help (or how it currently doesn't
help) with reproducibility.

Thanks,

Mark