[Reproducible-builds] Bug#806331: [xz-devel] Re: xz-utils: make the selected POSIX shell stable accross build environments

Ximin Luo infinity0 at debian.org
Thu Jun 16 01:20:11 UTC 2016

Thorsten Glaser:
> Ximin Luo dixit:
>> needs to more clearly distinguish between the build and the host
>> environment - like how compilers do. So for example, here the "most
>> correct" solution would be to add a HOST_POSIX_SHELL and default this
> No, this is outside of the scope of autotools and a common misuse
> of them actually.
> The real bug here is that the configure.ac script of the package
> hardcodes POSIX_SHELL in the output while your reproducible builds
> effort treats this as a(n unsupported, at least in this scenario)
> cross compilation.
> The same issue would happen when you set CONFIG_SHELL=/bin/bash
> and then cross-compile xz-utils from GNU/Linux to, say, MirBSD,
> where There Is No Such Thing As /bin/bash.
> So the root of the problem is that xz-utils is not cross-compilable
> (well, not completely, and enough for Helmut’s bootstrapping effort).

I agree there is an issue with configure.ac, but it can only be fully solved via HOST_POSIX_SHELL. 

In other words, the reason that xz-utils is not completely cross-compilable is *because* there is no such thing as HOST_POSIX_SHELL. xz-utils (using gnulib macros) is *unable* to distinguish between these two cases:

1. build-time scripts that require a POSIX shell
2. places where it needs to embed POSIX_SHELL into a shebang line, for scripts installed into the host architecture

xz-utils is forced to use POSIX_SHELL for both these cases, and that is where the "bug" comes in. It has nothing to do with reproducible builds, although it does manifest in a more obvious way if you are trying to reproducible a build across different machines.

If HOST_POSIX_SHELL was available, then xz-utils could use this for case (2). Then, if we wanted to cross-compile xz-utils from GNU/Linux to MirBSD, we would set HOST_POSIX_SHELL to whatever shell works on MirBSD.

Distinguishing cases (1) and (2) is not a "misuse" nor "outside the scope" of autotools, but a vital part of any well-engineered build tool.


GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE

More information about the Reproducible-builds mailing list