ibus-1.5.23 build results vary from parallelism

[bmwiedemann]

Please fill in the following items if you don't know the root cause.

Which distribution and version?:
openSUSE-Tumbleweed-20201029

Which desktop environment and version?:
N/A

Which session type?:
N/A

Which application and version?:
N/A

IBus version?:
1.5.3

Issue description:
While working on reproducible builds for openSUSE, I found that
comparing 1-core and 4-core builds of ibus, there were such variations:

/usr/lib64/ibus/ibus-extension-gtk3 differs in assembler output
--- old /usr/lib64/ibus/ibus-extension-gtk3 (disasm)
+++ new /usr/lib64/ibus/ibus-extension-gtk3 (disasm)
@@ -1730,7 +1730,7 @@
-___lambda53__ibus_emojier_load_progress_object_deserialize_unicode:
+___lambda18__ibus_emojier_load_progress_object_deserialize_unicode:

Steps to reproduce:

1. build from fresh tarball with -j1
2. build in another dir from fresh tarball with -j4
3. compare binaries

on openSUSE:

sudo zypper in osc build
osc checkout openSUSE:Factory/ibus && cd $_
for N in 1 4 ; do
    osc build --keep-pkg=RPMS.$N -j $N --noservice standard
    unrpm RPMS.$N/ibus-1*.x86_64.rpm
    strings usr/lib64/ibus/ibus-extension-gtk3 > $N.strings
done
diff -u {1,4}.strings

the string
lambda18__ibus_emojier_load_progress_object_deserialize_unicode
comes directly from the tarball's ui/gtk3/emojier.c - that is used in the -j1 case.
and the other lambda53 one seems to be from a ui/gtk3/emojier.c generated by valac during build.
strace shows the full call as

cd /home/abuild/rpmbuild/BUILD/ibus-1.5.23/ui/gtk3
/usr/bin/valac --vapidir=../../bindings/vala --vapidir=../../bindings/vala --pkg=posix --pkg=gtk+-3.0 --pkg=gdk-x11-3.0 --pkg=ibus-1.0 --pkg=config --pkg=xi --target-glib=2.46 --define=INDICATOR --pkg=gdk-wayland --define=USE_GDK_WAYLAND --define=EMOJI_DICT -C bindingcommon.vala emojier.vala extension.vala iconwidget.vala keybindingmanager.vala panelbinding.vala pango.vala

The problem is probably in the build scripts so that these .c files are not consistently regenerated before gcc uses them.

[fujiwarat]

Issue description:

What is your issue?

@@ -1730,7 +1730,7 @@
-___lambda53__ibus_emojier_load_progress_object_deserialize_unicode:
+___lambda18__ibus_emojier_load_progress_object_deserialize_unicode:

The difference should not be a problem.

[bmwiedemann]

I would like software that I can build anytime anywhere and get the same (aka bit-identical) build results. This makes it easier to trust software built by other people, because it is verifiable that it originated from published sources.

Having similar (but non-identical) build results, that probably do the same, is not as good, because verifying binaries is hard then.