Build is not binary reproducible

[jpew]

Embedding the configure time options into the executable can lead to
non-reproducible builds, since configure options often have embedded
paths.

[jpew]

Patch to disable configure args at configure time

[andrew_b]

Thanks!
Applied with small modification as [d009ea7b8b09e0acf33663738a023ee0df5fe4d0].

[egmont]

Could you guys give a bit more context on this?

I don't think reproducible build means that a different set of compile options needs to reproduce the same binary. Most of the configure options don't meet this criterium by design.

I'm pretty sure that reproducible build means that the same compile options always result in the same binary. E.g. the build's hostname or timestamp doesn't get injected, the order of the function implementations in the binary is same, etc.

Having reproducible builds is a noble goal, but it should be the out the box behavior (and I guess it is, isn't it?), not something achieved using yet another config option... let alone, having a name and description that doesn't refer to reproducible builds at all.

Also note a copy-pasted totally broken description ("Handle all compiler warnings as errors").

[jpew]

This is in the context of the reproducible build effort for OpenEmebeded/Yocto? Project. The issue that we found was that when cross compiling, you often end up passing the path to things like the sysroot as configure options. Between two given builds, this is functionally the same (e.g. we aren't *really* changing the configure options), but because the build paths get embedded as part of the mc executable, it doesn't build reproducibly when different build paths are used.

Sorry about the copy paste error.

I wouldn't mind if it was the default, but it looks like reporting the configure options is part of the bug reporting process, so this would affect that.

[egmont]

Thanks for the clarification!

I'd still argue that this is not about "reproducible build" per se, but something slightly more, although certainly related. A friend of mine is pretty familiar with reproducible builds, I'll ask him for his opinion.

According to https://midnight-commander.org/wiki/NEWS-4.7.5...4.8.0, the mc --configure-options command line option was added to address #2495. Note, however, that what that ticket requested there was quite different: just a few more lines to the output --version listing the paths that runtime mc will use. I would find that a great feature. Also what the NEWS entry says ("easy update & reconfigure") is nowhere mentioned in that ticket as goal. I'd argue that if someone needs to query the configure flags from the final binary for a rebuild then their development workflow is quite broken.

Stuffing all the configure flags into the binary is IMO an anti-pattern, something hardly (if at all?) seen in other apps. In the name of reproducible builds, including cross-compilation with vs. without sysroot, I would personally rather see the current --configure-options be removed and replaced by what was originally asked in 2495.

[jpew]

Replying to egmont:

Thanks for the clarification!

I'd still argue that this is not about "reproducible build" per se, but something slightly more, although certainly related. A friend of mine is pretty familiar with reproducible builds, I'll ask him for his opinion.

Ok. Most of our reproducible build testing in OpenEmbedded? has been targeting elimination of build paths, so I'd be curious what he has to say. I think one of the major differences (from r-b in debian at least) is that we are always cross compiling and thus we've always tried to eliminate host build paths from our builds. FWIW, we've been pretty successful at this, and even though the debian folks might not currently be looking for different build path reproducibility, I suspect they won't be upset if it does happen :)

According to https://midnight-commander.org/wiki/NEWS-4.7.5...4.8.0, the mc --configure-options command line option was added to address #2495. Note, however, that what that ticket requested there was quite different: just a few more lines to the output --version listing the paths that runtime mc will use. I would find that a great feature. Also what the NEWS entry says ("easy update & reconfigure") is nowhere mentioned in that ticket as goal. I'd argue that if someone needs to query the configure flags from the final binary for a rebuild then their development workflow is quite broken.

Agreed.

Stuffing all the configure flags into the binary is IMO an anti-pattern, something hardly (if at all?) seen in other apps. In the name of reproducible builds, including cross-compilation with vs. without sysroot, I would personally rather see the current --configure-options be removed and replaced by what was originally asked in 2495.

Yes, I agree with this. What else need to be shown besides the output from mc -V for this to be useful? Is it the path to the ancillary programs like so:

$ mc -V
GNU Midnight Commander 4.8.23-105-g37fcb210f
Built with GLib 2.62.1
Using the S-Lang library with terminfo database
With builtin Editor
With subshell support as default
With support for background operations
With mouse support on xterm
With support for X11 events
With internationalization support
With multiple codepages support
Virtual File Systems: cpiofs, tarfs, sfs, extfs, ftpfs, fish
Data types: char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64;
PYTHON=/usr/bin/python
PERL=/usr/bin/perl
GREP=/usr/bin/grep

?

[jpew]

It looks like most of what was requested in #2495 can actual be discovered by mc -F:

$ ./build/src/mc -F
Home directory: /home/wattj
Profile root directory: /home/wattj

[System data]
    Config directory: /usr/local/etc/mc/
    Data directory:   /usr/local/share/mc/
    File extension handlers: /usr/local/libexec/mc/ext.d/
    VFS plugins and scripts: /usr/local/libexec/mc/
        extfs.d:        /usr/local/libexec/mc/extfs.d/
        fish:           /usr/local/libexec/mc/fish/

[User data]
    Config directory: /home/wattj/.config/mc/
    Data directory:   /home/wattj/.local/share/mc/
        skins:          /home/wattj/.local/share/mc/skins/
        extfs.d:        /home/wattj/.local/share/mc/extfs.d/
        fish:           /home/wattj/.local/share/mc/fish/
        mcedit macros:  /home/wattj/.local/share/mc/mc.macros
        mcedit external macros: /home/wattj/.local/share/mc/mcedit/macros.d/macro.*
    Cache directory:  /home/wattj/.cache/mc/

Perhaps --configure-options can be completely removed?

[egmont]

See also ticket:4035#comment:18.