[RFC,v4,0/2] Improve native/cross reproducibility

This patch series is not intended for merge. I only send it out to
highlight where the problems are and to get some discussion going on how/if
we want to improve the situation.

This is a patch series that tries to improve the reproducibility of the
native/cross binaries when building in different directories. Whether this has
any real benefits I'm still not sure of, but I thought I'd share this final
version of the patch series in case someone comes up with an idea. This has
been tested on a Fedora 35 system which uses gcc 11.2.1 at the time of writing.

The RUNTIME hack is questionable, maybe there is a better way to enforce
a fixed RUNTIME entry size during linking. The build system does not do any
additional rpath manipulation for target binaries, so in those cases this is
not a problem. I did ask for some guidance on the gcc-help mailing list [1] on
how to reserve a specific RPATH size during linking, but it would seem that is
not currently possible.

If in the end we do come up with a solution, then it should be tested on the
autobuilders, since otherwise this is going to degrade overtime. It would then
be important that the build paths are of significantly different lengths.
TMPDIR=/tmp/sysrootA/ and TMPDIR=/tmp/sysrootB/ will *not* uncover all
rpath problems.

Another thing that would be useful is if buildhistory could start monitoring
the depsig.do_populate_sysroot files, since that would highlight changes in
the actual file contents, which is currently not covered by buildhistory.

The end result of this patch series is that I can build python3-native in
two different build paths, and the resuling sysroot-components/x86_64/
directories are identical, except for the 'fixmepath.cmd' files, which are not
included in the hash equiv. comparisons. Even so, there remains a lot of
native builds that are going to need to be fixed in similar ways as the
ones in this patch series.

Changes in v2:
 * Fixed building icedtea7-native/openjdk-8-native by prepending a '/' to the
   rpath padding
 * Squashed all the recipe-fixes together in one commit for now

Changes in v3:
 * Rebase on top of master
 * Instead of adding a padding entry to rpath, set phony rpaths in bitbake.conf
   and add patches for unbreaking python3-native and kernel
 * With the changes above we don't need to remove the build ID, so add it back

Changes in v4:
 * Rebase on top of master
 * Cleanup fixes for openssl/ncurses/perlcross/perl
 * Go back to padding rpath and revert the python3-native/kernel fixes, since
   this feels like the least intrusive change, and from what I understand
   cmake also does a similar type of rpath padding in some situations

Previous versions of the patch series:
v1: https://lists.openembedded.org/g/openembedded-core/message/158867
v2: https://lists.openembedded.org/g/openembedded-core/message/158998
v3: https://lists.openembedded.org/g/openembedded-core/message/159181

[1] https://gcc.gnu.org/pipermail/gcc-help/2021-November/140920.html

Jacob Kroon (2):
  bitbake.conf: Pad rpath in native binaries
  Improve native reproducibility in recipes

 meta/classes/chrpath.bbclass                  |  3 +++
 meta/classes/sstate.bbclass                   |  1 +
 meta/conf/bitbake.conf                        |  3 +++
 ...sysroot-and-debug-prefix-map-from-co.patch | 24 ++++++++++++-------
 .../openssl/openssl_3.0.0.bb                  | 12 ++++++----
 meta/recipes-core/ncurses/ncurses.inc         |  9 +++++--
 .../util-linux/util-linux_2.37.2.bb           |  2 +-
 .../libtool/libtool-native_2.4.6.bb           |  1 +
 meta/recipes-devtools/perl/perl_5.34.0.bb     |  3 +++
 .../pkgconfig/pkgconfig_git.bb                |  1 +
 .../python/python3/determinism.patch          | 17 +++++++++++++
 .../recipes-devtools/python/python3_3.10.1.bb |  8 +++++++
 12 files changed, 68 insertions(+), 16 deletions(-)
 create mode 100644 meta/recipes-devtools/python/python3/determinism.patch