Re: [PATCH for 7.1] linux-user: fix compat with glibc >= 2.36 sys/mount.h

[Peter Maydell]

On Tue, 2 Aug 2022 at 17:43, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> The latest glibc 2.36 has extended sys/mount.h so that it
> defines the FSCONFIG_* enum constants. These are historically
> defined in linux/mount.h, and thus if you include both headers
> the compiler complains:
>
> In file included from /usr/include/linux/fs.h:19,
>                  from ../linux-user/syscall.c:98:
> /usr/include/linux/mount.h:95:6: error: redeclaration of 'enum 
> fsconfig_command'
>    95 | enum fsconfig_command {
>       |      ^~~~~~~~~~~~~~~~
> In file included from ../linux-user/syscall.c:31:
> /usr/include/sys/mount.h:189:6: note: originally defined here
>   189 | enum fsconfig_command
>       |      ^~~~~~~~~~~~~~~~
> /usr/include/linux/mount.h:96:9: error: redeclaration of enumerator 
> 'FSCONFIG_SET_FLAG'
>    96 |         FSCONFIG_SET_FLAG       = 0,    /* Set parameter, supplying 
> no value */
>       |         ^~~~~~~~~~~~~~~~~
> /usr/include/sys/mount.h:191:3: note: previous definition of 
> 'FSCONFIG_SET_FLAG' with type 'enum fsconfig_command'
>   191 |   FSCONFIG_SET_FLAG       = 0,    /* Set parameter, supplying no 
> value */
>       |   ^~~~~~~~~~~~~~~~~
> ...snip...
>
> QEMU doesn't include linux/mount.h, but it does use
> linux/fs.h and thus gets linux/mount.h indirectly.
>
> glibc acknowledges this problem but does not appear to
> be intending to fix it in the forseeable future, simply
> documenting it as a known incompatibility with no
> workaround:
>
>   
> https://sourceware.org/glibc/wiki/Release/2.36#Usage_of_.3Clinux.2Fmount.h.3E_and_.3Csys.2Fmount.h.3E
>   https://sourceware.org/glibc/wiki/Synchronizing_Headers
>
> To address this requires either removing use of sys/mount.h
> or linux/fs.h, despite QEMU needing declarations from
> both.
>
> This patch removes linux/fs.h, meaning we have to define
> various FS_IOC constants that are now unavailable.

I don't suppose anybody has useful contacts with the glibc
developers so we can ask them if they can try to maybe
not break applications like this, or at least if they do
to provide workarounds ? Having to hand-define
a bunch of ioctl constants is particularly messy.

thanks
-- PMM