PYTHONHASHSEED, hashes, build failure on sparc and other fun gssapi.h stuff

[Michael Tokarev]

So, I digged into the persistent build failure on sparc64,
https://bugzilla.samba.org/show_bug.cgi?id=15080

The problem here is - simplified - we have too deep gssapi/ directory.

third_party/heimdal/lib/gssapi/gssapi/gssapi.h

is the main header.  There's also a dummy header,

third_party/heimdal/lib/gssapi/gssapi.h

which just includes <gssapi/gssapi.h>.

But the thing is: samba build procedure has -Ithird_party/heimdal/lib/gssapi
*and* -Ithird_party/heimdal/lib in the compiler options (for the -I options,
I don't understand where they're set up in the wafsamba machinery).

So we can include either <gssapi.h> or <gssapi/gssapi.h> - *if* the lib/gssapi
include comes *after* lib include, both of these header files will be satisfied
by the same dummy third_party/heimdal/lib/gssapi/gssapi.h.  So this dummy
header just includes itself which gives us nothing.

But if -Ilib/gssapi comes *before* -Ilib, everything is fine.

But this is just too fragile.  Maybe heimdal folks should not use this directory
naming.  Or maybe - which is more appropriate it seems, since there are no include
files in there! - samba should not specify the -Ithird_party/heimdal/lib option.

For now, due to lack of understanding of wafsamba machinery with the include path,
with this (mutating) set of -I flags, we can just remove this dummy gssapi.h
header, - this way, <gssapi/gssapi.h> will resolve to the right one being included,
and everything builds fine.

Where the -Ithird_party/heimdal/lib option comes from?

Thanks,

/mjt