another build failure on sparc64

[Stian Halseth]

On Sun, 8 Feb 2026 09:28:02 UTC, Michael Tokarev wrote:
> Now, I don't know how to fix or work-around this - for good.

This is diagnosed, with patches in two merge requests. The short
version, since the detail is in the bugs:

hx_locl.h includes "crypto-headers.h", and two files answer to that
name - third_party/heimdal/include/crypto-headers.h from the vendored
heimdal, and Samba's replacement in third_party/heimdal_build/. The
vendored one requires PACKAGE_NAME, which nothing in a Samba build
defines, so it can only ever fail; a build succeeds when the -I order
happens to select the replacement. build_includes() in
buildtools/wafsamba/samba_deps.py decides that order by iterating an
unordered set, and appends each dependency's own directory after the
directories that dependency declares in includes=. Nine heimdal
targets declare ../heimdal/include, so which one the set yields first
decides whether the tree builds.

The useful part is that it reproduces on amd64. This has been treated
as sparc64 flakiness since 2022, and it is not:

    PYTHONHASHSEED=5 ./buildtools/bin/waf build -j20

fails on master with exactly the sparc64 error, in WDC_SAMBA4, and that
is the only distinct error in the build. Seed 5 is the one I built.
Of the 1025 targets that have both directories on their include path,
the number searching heimdal/include first ranges from 0 at seeds 1, 2,
4, 8 and 9 to 891 at seed 5; with either patch it is 0 at every seed I
tried. A seed showing 0 cannot hit this failure; a seed above 0 fails
only if one of those targets actually reaches crypto-headers.h, which
is also why the failing file differs per architecture - sdb_to_hdb.c on
the buildd, wdc-samba4.c here.

Three things worth flagging:

- buildtools/wafsamba/wscript already requires PYTHONHASHSEED=1, and
  that is not sufficient. With the seed pinned on both machines,
  hash('HEIMDAL_KRB5') is -5777948353383250625 on amd64 and
  7800708043191837418 on a sparc64 T4.

- The config.h pair you found resolves the same way on amd64, at the
  same relative positions, so it is not what differs between a working
  and a failing architecture. heimdal gets its own config.h regardless,
  through the quoted include in heimdal_build/roken.h.

- The "Node ... is created more than once" messages in Adrian's report
  are waf errcheck output, only active under -v. The successful amd64
  build of the same version prints the same four.

Bugs and merge requests:

  16229  crypto-headers.h shadowing, heimdal only
         https://gitlab.com/samba-team/samba/-/merge_requests/4684
  15080  the set order itself, tree-wide - wants a full autobuild
         https://gitlab.com/samba-team/samba/-/merge_requests/4685

Michael: the first one is what I would suggest for Debian. If you want
something smaller to carry locally, the vendored crypto-headers.h can
simply include the replacement - one line, no dependence on -I order,
and it cannot regress an architecture that builds today, because no
successful build has ever used that file.

Thanks,
Stian Halseth