[rb-general] advice on stashing compiler options in a binary

Orians, Jeremiah (DTMB) OriansJ at michigan.gov
Wed Mar 20 12:19:31 CET 2019


>> Similarly to other interpreted
>>languages, the compiler options used are stashed in the binary for later use.
>I don't know what everyone else here believes, but I recommend that those not be included in the binaries at all, but instead be put elsewhere so they can be more easily separated. 
> In particular, no one really cares what the build directory is. I had to fight this earlier with GCC.
Personally, I wish the default for gcc and other compilers when setting the debug flag is simply include the full source in an ELF stub(s);
that way we can be done with this path nonsense that keeps showing up.


>>I recently realized this leads to a paradox with the -fdebug-prefix-map 
>>option, since the original build directory is recorded in the stashed 
>>compiler options.
> Building in such a way so that others can easily reuse exactly the same build directory is and alternative.
Or waste some disk space and not care about build locations at all.

>In today's world, or you can easily create full containers or at least chroot sandboxes, those are pretty easy to recreate.
Or a simpler option, fully static binaries like those M2-Planet creates.
https://github.com/oriansj/M2-Planet
Where there is no possible input that could possibly create non-deterministic output.
Build directories, paths, timestamps, library paths, host instruction set or any other of that nonsense, just doesn't matter.

-Jeremiah


More information about the rb-general mailing list