Ricardo Wurmus writes:

> When building packages, Guix embeds the absolute file name of the output
> directory in the resulting binary.  That’s usually fine and what we
> want.
>
> Now let’s assume that we’d like to build the GCC sources with diverse
> double compilation: we’d have a “gcc” package that’s built with
> “gcc-core”; we’d also have a “gcc-from-clang” package that uses Clang as
> its input.  Since the GCC build procedure is performed at least two
> times (once with the bootstrap compiler, and then again with the GCC
> variant this produces), the resulting GCC binaries should be identical.
>
> Except that they are not.  One of the reasons is that the binaries that
> Guix produces embed the target output directories.  This means that the
> two compiler binaries that result from diverse double compilation will
> *always* differ in at least the embedded paths, such as paths to itself
> (e.g. to binaries in the libexec directory) and paths to.
>
> I wonder if we can use $ORIGIN in the compiler binaries, so that we can
> avoid (most) references to the output directories, thereby making the
> equality check between the diversely built compiler binaries simpler.
>
> Is this at all possible?  Or do we need to accept that the equality
> check for diverse double compilation for binaries built with Guix must
> be aware of /gnu/store references and ignore those?
>
> Alternatively, could we move all of these store references into a
> wrapper script that would tell the binary about them via environment
> variables?  The equality check would only need to exclude the wrapper
> script then and compare the two sets of compiler binaries naively.
>
> Does this make any sense?

Attached is a patch prototyping this diverse double compilation test.

janneke