setting -fdebug-prefix-map via envvar

[Vagrant Cascadian]

On 2020-06-26, hartmut wrote:
> a) The build process should be well documented and obviously. It means usage of an environment
> variable inside the compiler, internal, it very bad for that. Because the value of the envvar may be
> unknown after build. It is possible to use an environment variable as argument : gcc ...
> $SPECIALOPTION but the expanded value should be documented. A good idea is documentation of the
> effective command line, may be by an echo statement. 

Well, this requires either documenting the build path of the build
environment, or documenting the environment variable that was used to
sanitize the build path. Either way, the compiler is embedding
information about the build environment that is potentially
non-deterministic. Which is why we document the build environment.

Creating a build in the same build path in many cases requires root
privledges of some form; using an environment variable is *much* easier
to set without any special privledges.


> b) Absolute Paths on build: I have the experience that the absolute path is stored in Objectfiles
> while compiling and influences the machinen code, unexpected and unfortunatelly, but it was so on some
> compiler. My solution in this kind was: Re-Compiling under same conditions of absolute paths, storing
> the "Sandbox" of sources in the same absolute path on any machine. A symbolic link on Unix is
> helpfull. Because I had need do that on a Windows PC (XP), I have used the subst command: "subst B: D:
> \my\special\path" and start the compilation from "B:\localmake". Hint: On Windows the B-drive was a
> diskette in the old past, it is usual free to use.  

Sure, building in the same path is the easiest way to work around these
sorts of issues, if you can easily control the build path. Which is why
in the reproducible builds testing for Debian the "unstable" suite
varies the build path and the "testing" suite builds in the same build
path. This gives us a rough idea to compare how many packages are
affected by this issue.

Long-term, we should address the build-path issue, but in the short to
middle term, it seems to me there are other more important issues to
address, since it is relatively easy to work around...


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20200626/e93921dc/attachment.sig>