Build path variation and __FILE__

[Sascha Steinbiss]

Hi all,

I’d like to contribute to the build path discussion as well with a few observations I made when trying to fix reproducibility problems related to that in my packages. In addition to the problem already raised by Ximin concerning upstream storing CFLAGS in artifacts, most of the issues I noticed were related to build path capture via __FILE__.
__FILE__ is typically set to the exact source file path passed to the compiler, and in quite common cases where it is used in debugging statements etc. it is included as a string in the final binaries’ rodata section. So if upstream’s build system passes absolute source paths and __FILE__ is used, the binaries will be different even with -fdebug-prefix-map set :(
This problem particularly shows in build systems that run builds outside the source tree like CMake, which makes use of absolute paths a lot. There is apparently an option CMAKE_USE_RELATIVE_PATHS but it is apparently unreliable [1] and did not help in a single case for me.
I’ll take a look at the list of reproducible packages build-depending on CMake [2] later and try to learn something.

Any ideas what to do about that in general? I can imagine that patch complexity would be increased a lot by trying to address this solely at the build system level, which also probably isn't always possible. One might think of a solution closer to the compiler, such as:

a) Introducing something like -ffile-prefix-map similarly to -fdebug-prefix-map to address this issue. There is already an unreviewed patch for gcc submitted by an unrelated party [3] and I could try and raise awareness for this bug with the GCC devs. However, this option would be incompatible with old compilers and hence probably not easily enabled in the default dpkg-buildflags. IMHO it would be a good thing to have though.

b) Using something like libelf or bin_replace_string [4] to remove or replace the build path in the resulting binary, e.g. as part of strip-nondeterminism. Not a permanent solution but would do the job.

c) Any other ideas?

Cheers
Sascha

[1] http://public.kitware.com/pipermail/cmake/2013-January/053114.html
[2] https://paste.debian.net/806611
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268
[4] http://ohnopub.net/~ohnobinki/bin_replace_string/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20160906/69b8289d/attachment.sig>