[PATCH] v4l2: Fix compile of mpers-m32 API

Hauke Mehrtens hauke at hauke-m.de
Sun Aug 30 12:07:34 UTC 2020

On 8/30/20 12:54 PM, Eugene Syromyatnikov wrote:
> On Sun, Aug 30, 2020 at 12:10 PM Hauke Mehrtens <hauke at hauke-m.de> wrote:
>> In the mpers-m32 API the value64 member of the struct_v4l2_ext_control
>> structure is of type int32_t.
> mpers headers are generated, and the fact that int64_t[1] is 32-bit
> wide when -m32 compiler option is used is rather a bug on libc's part.
> See also [2].
> [1] https://gitlab.com/strace/strace/-/blob/v5.8/types/v4l2.h#L175
> [2] https://github.com/strace/musl/commit/6a63dbca01b26dd68483429746ec90e34551ace4

Hi Eugene,

I did this build in OpenWrt with musl libc 1.1.24 + gcc 8.4.0 for x86_64.

The file mpers-mx32/struct_v4l2_ext_control.h looks like this:
int32_t value;
int32_t value64;
} ;
} ATTRIBUTE_PACKED mx32_struct_v4l2_ext_control;
#define MPERS_mx32_struct_v4l2_ext_control mx32_struct_v4l2_ext_control
The mpers-m32/struct_v4l2_ext_control.h file looks similar.

When I compile this on my Debian with glibc and gcc 8.3.0 the value64 is
of type int64_t.

Where are these structures in mpers-m32 and mpers-mx32 generated? It
looks like some script which generates them converts the int64_t into a
int32_t under some conditions.

I see that Apline just deactivated mpers support, I think that is also
ok for OpenWrt:


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20200830/2bc670bd/attachment.bin>

More information about the Strace-devel mailing list