Description
selinux 3.8 fails to build on libc-x32 due to a mismatch in the assumptions of sizeof(unsigned long), sizeof(uint32_t), and sizeof(__ino_t), as seen in https://github.com/SELinuxProject/selinux/blob/main/libselinux/src/matchpathcon.c#L270.
Given the hijinks involved in x32 with the 32-bit address space, 64-bit registers, and 64-bit kernel, making unsigned long not 32 bits, I'm actually not sure what the right thing to do here is. Maybe avoid bare unsigned long for mathpathcon_filesppec_add IAW sourceware's recommendations on x32/glibc at https://www.sourceware.org/glibc/wiki/x32?
While not necessarily relevant here, this does hit at least the debian x32 port:
cc -Wdate-time -D_FORTIFY_SOURCE=2 -D_LARGEFILE64_SOURCE -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<<PKGBUILDDIR>>=. -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -fcf-protection -fno-semantic-interposition -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I../include -D_GNU_SOURCE -DNO_ANDROID_BACKEND -DUSE_PCRE2 -DPCRE2_CODE_UNIT_WIDTH=8 -DHAVE_STRLCPY -DHAVE_REALLOCARRAY -c -o matchpathcon.o matchpathcon.c
In file included from matchpathcon.c:1:
matchpathcon.c:270:1: error: static assertion failed: "inode size mismatch"
270 | static_assert(sizeof(unsigned long) == sizeof(__ino_t), "inode size mismatch");
| ^~~~~~~~~~~~~
make[3]: *** [Makefile:178: matchpathcon.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/<<PKGBUILDDIR>>/src'
make[2]: *** [Makefile:54: all] Error 1
make[2]: Leaving directory '/<<PKGBUILDDIR>>'
make[1]: *** [debian/rules:56: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
make: *** [debian/rules:50: binary-arch] Error 2
I suspect the 'right' thing to do is actually test on what x86_64-linux-gnux32/sys/types.h ends up declaring, but I don't know if that's sufficient for selinux. Hacking the static_asserts to do basically that seems to work, but I'm not in a spot where I can test that properly right now.