PYTHONHASHSEED, hashes, build failure on sparc and other fun gssapi.h stuff
mjt at tls.msk.ru
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