11.0-CURRENT buildworld lib32/libsoft failures: ioctl.c and sys/dev/ciss/cissio.h and __amd64__ vs. __amd64 example; LIBCOMPATWMAKEFLAGS and CP="${XCPP}"

I'm currently getting errors for CCIS_PASSTHRU32 and others in ioctl.c not being defined while an amd64 context updates itself from -r297514 to -r297769 via buildworld. The problem is during lib32's build activity. A grep of the log shows:

> ioctl.c:472:18: error: use of undeclared identifier 'CCISS_PASSTHRU32'
> ioctl.c:1186:18: error: use of undeclared identifier 'IPMICTL_RECEIVE_MSG_32'
> ioctl.c:1190:18: error: use of undeclared identifier 'IPMICTL_RECEIVE_MSG_TRUNC_32'
> ioctl.c:1196:18: error: use of undeclared identifier 'IPMICTL_SEND_COMMAND_32'
> ioctl.c:1394:18: error: use of undeclared identifier 'MPTIO_RAID_ACTION32'
> ioctl.c:1398:18: error: use of undeclared identifier 'MPTIO_READ_CFG_HEADER32'
> ioctl.c:1402:18: error: use of undeclared identifier 'MPTIO_READ_CFG_PAGE32'
> ioctl.c:1406:18: error: use of undeclared identifier 'MPTIO_READ_EXT_CFG_HEADER32'
> ioctl.c:1410:18: error: use of undeclared identifier 'MPTIO_READ_EXT_CFG_PAGE32'
> ioctl.c:1414:18: error: use of undeclared identifier 'MPTIO_WRITE_CFG_PAGE32'


sys/dev/ciss/cissio.h is an example of a more general issue here for lib32 (for amd64 not cross built) and libsoft (for amd64 cross building for a rpi2 as an example).

sys/dev/ciss/cissio.h has code such as:

> #ifdef __amd64__
> typedef struct {
>     LUNAddr_struct      LUN_info;       /* 8 */
>     RequestBlock_struct Request;        /* 20 */
>     ErrorInfo_struct    error_info;     /* 48 */
>     u_int16_t           buf_size;       /* 2 */
>     u_int32_t           buf;            /* 4 */
> } __packed IOCTL_Command_struct32;
> #endif
> . . .
> #ifdef __amd64
> #define CCISS_PASSTHRU32        _IOWR ('C', 210, IOCTL_Command_struct32)
> #endif

Note the __ suffix vs. not after the "amd64". There can be headers around that produce such variations of macros. arm has one of those that makes macros that track characteristics of specific types of arm variants, for example.

The details of what happen for this sort of thing can depend on Makefile.libcompat's:

> LIBCOMPATWMAKEFLAGS+= CC="${XCC} ${LIBCOMPATCFLAGS}" \
>                 CXX="${XCXX} ${LIBCOMPATCFLAGS} ${LIBCOMPATCXXFLAGS}" \
>                 DESTDIR=${LIBCOMPATTMP} \
>                 -DNO_CPU_CFLAGS \
>                 MK_CTF=no \
>                 -DNO_LINT \
>                 MK_TESTS=no

vs. also having CPP="${XCPP}" listed as can be required for cross builds (such amd64 building for an rpi2 [libsoft] or powerpc64 [lib32]):

> LIBCOMPATWMAKEFLAGS+= CC="${XCC} ${LIBCOMPATCFLAGS}" \
>                 CXX="${XCXX} ${LIBCOMPATCFLAGS} ${LIBCOMPATCXXFLAGS}" \
>                 CPP="${XCPP}" \
>                 DESTDIR=${LIBCOMPATTMP} \
>                 -DNO_CPU_CFLAGS \
>                 MK_CTF=no \
>                 -DNO_LINT \
>                 MK_TESTS=no


Because of previously needing it for cross compiles I currently have the CPP="${XCPP}" in place in my context: an arm header was processed by the amd64 preprocessor and the header could not detect its context correctly:

> --- all_subdir_lib/libsysdecode ---
> In file included from <stdin>:17:
> In file included from /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/dev/nvme/nvme.h:36:
> In file included from /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/sys/param.h:135:
> In file included from /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/param.h:49:
> /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/acle-compat.h:182:4: error: Unable to determine architecture version.
> #  error Unable to determine architecture version.
> ^


Is this area broken overall? Or is there something that I need to do differently in order to have amd64 rebuild itself (not a cross build) but also to also have amd64 do cross builds (such as arm and its libsoft)?


===
Mark Millard
markmi at dsl-only.net