waf, PYTHONHASHSEED & -I order on other architectures

[Michael Tokarev]

09.04.2022 09:41, Michael Tokarev via samba-technical wrote:
> Hi!
> 
> I'm having a build failure of samba on sparc64.  It fails due to finding
> wrong include for <gssapi/gssapi.h>, as it has already seen before due to
> PYTHONHASHSEED not being set, having python hashes in random order so -I
> includes were unpredictable.
> 
> The good -I order is this:
> 
>   -Ithird_party/heimdal/lib/gssapi
>   -Ithird_party/heimdal/lib
> 
> the bad is:
> 
>   -Ithird_party/heimdal/lib
>   -Ithird_party/heimdal/lib/gssapi
> 
> (I picked up only the -I options for dirs where <gssapi/gssapi.h> exists).
> 
> This is stable on sparc64, all builds of samba-4.16 are failing due to
> this very issue.
> 
> How to work around this?

It turned out this is even more interesting.

The same issue started happening on alpha too now on Debian, after
update of python from 3.9 to 3.10.  Before, with python 3.9, it
worked fine.  Again, this is WITH pythonhashseed=1 set. This is
exactly the case with heimdal includes. The log is here:

https://buildd.debian.org/status/fetch.php?pkg=samba&arch=alpha&ver=2%3A4.16.0%2Bdfsg-7&stamp=1650980011&raw=0

it is exactly the same prob as on sparc64.
Neither sparc64 nor alpha are Debian release architectures,
so it is not a big deal that the build fails there, but it
looks like the thing is quite fragile.

And there's more to this. This time, the built was made
WITHOUT specifying PYTHONHASHSEED=1, - this is before I
become aware of this.  Please see here for the complete thing:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009726#10

TL;DR version: successful build sometimes results in broken
binaries due to the link order - the resulting binaries are
segfaulting randomly. This is, again, without setting
PYTHONHASHSEED=1.

But having in mind the hash order is architecture and python
version dependent, how far we are from getting broken builds
even WITH "fixed" hashes?

It looks like this whole thing needs a more real fix, so it
is not dependent on architecture or python version.  It is
not just the wrong include order and the compiler finding the
wrong include file because there are too many of files with
the same name. It is successful build producing broken binaries.

Thanks,

/mjt