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

Michael Tokarev mjt at
Sun Nov 6 16:53:18 UTC 2022

So, I digged into the persistent build failure on sparc64,

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


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


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?



More information about the samba-technical mailing list