Based on the error messages during the build of tools in build.sh on systems missing the u_longlong_t type, I think the build might fail with the committed patch because the messages seemed to indicate the u_longlong_t type needs to be defined before <rpc/types.h> is included (<rpc/types.h> includes <sys/types.h>, and <sys/types.h> is the header that does not have the u_longlong_t type on some Linux systems). In compat_defs.h, <rpc/types.h> is included at line 75, but the typedef for u_longlong_t is added at line 1302.
In the patch I tested with a successful build on a Debian 8 system that also did not have the u_longlong_t type, I placed the typedef for u_longlong_t between lines 74 and 75 of compat_defs.h instead of at line 1302, where it is placed in the committed patch. Although it seems logical to place the missing typedef at the same place in compat_defs.h that take care of any other missing type definitions that belong in <sys/types.h>, I am not sure that placement in the compat_defs.h file actually fixes the build of tools on Linux systems.
I don't know if this means the build of that component of tools (ctf, libctf) using build.sh is not including header files in the expected order.
Chuck Zmudzinski On 06/12/2018 04:01 AM, Andreas Gustafsson wrote:
maya%netbsd.org@localhost wrote:Thanks, I committed that.The build still fails on my Debian 9 system after that commit. The configure script prints checking for u_longlong_t... no and the build later fails with: --- ctf_create.lo --- In file included from /bracket/build/2018.06.11.18.48.25-i386/src/tools/libctf/../compat/compat_defs.h:75:0, from /bracket/build/2018.06.11.18.48.25-i386/tools/include/compat/nbtool_config.h:885, from /bracket/build/2018.06.11.18.48.25-i386/src/tools/libctf/../../external/cddl/osnet/dist/common/ctf/ctf_create.c:23: /bracket/build/2018.06.11.18.48.25-i386/src/tools/libctf/../../external/cddl/osnet/dist/uts/common/rpc/types.h:57:9: error: unknown type name 'u_longlong_t' typedef u_longlong_t ulonglong_t; ^~~~~~~~~~~~