<p></p>
<blockquote>
<p>On Fri, Apr 10, 2020 at 01:20:03PM -0700, Jory A. Pratt wrote: In file included from static_assert.h:11, from v4l2.c:13: xlat/v4l2_ioctl_cmds.h:43:1: error: static assertion failed: "VIDIOC_QUERYBUF != _IOWR('V', 9, struct_v4l2_buffer)" 43 | static_assert((VIDIOC_QUERYBUF) == (_IOWR('V', 9, struct_v4l2_buffer)), "VIDIOC_QUERYBUF != _IOWR('V', 9, struct_v4l2_buffer)"); | ^~~~~~~~~~~~~ xlat/v4l2_ioctl_cmds.h:64:1: error: static assertion failed: "VIDIOC_QBUF != _IOWR('V', 15, struct_v4l2_buffer)" 64 | static_assert((VIDIOC_QBUF) == (_IOWR('V', 15, struct_v4l2_buffer)), "VIDIOC_QBUF != _IOWR('V', 15, struct_v4l2_buffer)"); | ^~~~~~~~~~~~~ xlat/v4l2_ioctl_cmds.h:71:1: error: static assertion failed: "VIDIOC_DQBUF != _IOWR('V', 17, struct_v4l2_buffer)" 71 | static_assert((VIDIOC_DQBUF) == (_IOWR('V', 17, struct_v4l2_buffer)), "VIDIOC_DQBUF != _IOWR('V', 17, struct_v4l2_buffer)"); This is build using linux-headers-5.6 with musl-1.2.0, this is a regression as 5.5 compiles fine.<br>
The reason why 5.5 compiles fine is that the check was introduced in 5.6, but the problem lies elsewhere. Definitions of VIDIOC_QUERYBUF, VIDIOC_QBUF, and VIDIOC_DQBUF in <linux/videodev2.h> use struct v4l2_buffer which in turn uses struct timeval. The size of struct timeval on a traditional 32-bit architecture like x86 depends on libc and its version thanks to time_t problem. As result, the value of VIDIOC_QUERYBUF on a traditional 32-bit architecture like x86 depends on libc and its version. When v4l2.c is compiled in mpers mode to handle x86 and x32 personality syscalls on x86_64, the value for VIDIOC_QUERYBUF is taken from the appropriate linux/<em>/ioctls_inc</em>.h file. There is only one value there for each architecture, not two. If you are unhappy enough to have time_t size different from the one used to generate that ioctls_inc file, you get this failed assertion. The kernel starting with Linux kernel commit v5.6-rc1<del>93^2</del>102 supports both sets of ioctl values, but strace will recognize and decode only one of them so far. I don't see an easy fix of this issue for early adopters of 64-bit time_t on 32-bit architectures, sorry.<br>
<a href="#">…</a><br>
-- ldv</p>
</blockquote>
<p>I find this rather funny you want to keep talking about 32bit issues, this problem is seen in 64bit systems such as ppc64 aarch64 which are far from 32bit arch.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you commented.<br />Reply to this email directly, <a href="https://github.com/strace/strace/issues/133#issuecomment-633101727">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AOVBTR4JRNMSOCOAPSLS3VTRTACDJANCNFSM4MFV2MDA">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AOVBTR3YZWYPRSFX6PJVRO3RTACDJA5CNFSM4MFV2MDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEW6F3HY.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/strace/strace/issues/133#issuecomment-633101727",
"url": "https://github.com/strace/strace/issues/133#issuecomment-633101727",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>