Searched hist:"3 cd3df2a" (Results 1 – 2 of 2) sorted by relevance
/openbmc/qemu/ |
H A D | meson.build | 3cd3df2a Tue Aug 02 11:41:34 CDT 2022 Daniel P. Berrangé <berrange@redhat.com> linux-user: fix compat with glibc >= 2.36 sys/mount.h
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.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Message-Id: <20220802164134.1851910-1-berrange@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
|
/openbmc/qemu/linux-user/ |
H A D | syscall.c | 3cd3df2a Tue Aug 02 11:41:34 CDT 2022 Daniel P. Berrangé <berrange@redhat.com> linux-user: fix compat with glibc >= 2.36 sys/mount.h
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.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Message-Id: <20220802164134.1851910-1-berrange@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
|