> 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
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.
Reproducible-builds mailing list