Message ID | 20220215120625.64711-1-f4bug@amsat.org (mailing list archive) |
---|---|
Headers | show |
Series | buildsys: More fixes to use GCC on macOS | expand |
On Tue, Feb 15, 2022 at 9:06 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > > Few fixes to be able to use GCC extensions which are not > available on Clang. > > Philippe Mathieu-Daudé (4): > osdep: Avoid using Clang-specific __builtin_available() > osdep: Un-inline qemu_thread_jit_execute/write > audio: Rename coreaudio extension to use Objective-C compiler > ui/cocoa: Ignore 'initializer overrides' warnings > > audio/{coreaudio.c => coreaudio.m} | 0 > audio/meson.build | 2 +- > include/qemu/osdep.h | 21 ++------------------- > ui/cocoa.m | 5 +++++ > util/osdep.c | 20 ++++++++++++++++++++ > 5 files changed, 28 insertions(+), 20 deletions(-) > rename audio/{coreaudio.c => coreaudio.m} (100%) > > -- > 2.34.1 > Compiler portability is always nice to have. Making QEMU on macOS compatible with GCC is good, but I don't think that would justify abandoning compatibility with Clang. Regards, Akihiko Odaki
On 15/2/22 14:06, Akihiko Odaki wrote: > On Tue, Feb 15, 2022 at 9:06 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: >> >> Few fixes to be able to use GCC extensions which are not >> available on Clang. >> >> Philippe Mathieu-Daudé (4): >> osdep: Avoid using Clang-specific __builtin_available() >> osdep: Un-inline qemu_thread_jit_execute/write >> audio: Rename coreaudio extension to use Objective-C compiler >> ui/cocoa: Ignore 'initializer overrides' warnings >> >> audio/{coreaudio.c => coreaudio.m} | 0 >> audio/meson.build | 2 +- >> include/qemu/osdep.h | 21 ++------------------- >> ui/cocoa.m | 5 +++++ >> util/osdep.c | 20 ++++++++++++++++++++ >> 5 files changed, 28 insertions(+), 20 deletions(-) >> rename audio/{coreaudio.c => coreaudio.m} (100%) >> >> -- >> 2.34.1 >> > > Compiler portability is always nice to have. Making QEMU on macOS > compatible with GCC is good, but I don't think that would justify > abandoning compatibility with Clang. I am certainly not abandoning compatibility with Clang. What gives you this impression?
On Tue, Feb 15, 2022 at 10:25 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > > On 15/2/22 14:06, Akihiko Odaki wrote: > > On Tue, Feb 15, 2022 at 9:06 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > >> > >> Few fixes to be able to use GCC extensions which are not > >> available on Clang. > >> > >> Philippe Mathieu-Daudé (4): > >> osdep: Avoid using Clang-specific __builtin_available() > >> osdep: Un-inline qemu_thread_jit_execute/write > >> audio: Rename coreaudio extension to use Objective-C compiler > >> ui/cocoa: Ignore 'initializer overrides' warnings > >> > >> audio/{coreaudio.c => coreaudio.m} | 0 > >> audio/meson.build | 2 +- > >> include/qemu/osdep.h | 21 ++------------------- > >> ui/cocoa.m | 5 +++++ > >> util/osdep.c | 20 ++++++++++++++++++++ > >> 5 files changed, 28 insertions(+), 20 deletions(-) > >> rename audio/{coreaudio.c => coreaudio.m} (100%) > >> > >> -- > >> 2.34.1 > >> > > > > Compiler portability is always nice to have. Making QEMU on macOS > > compatible with GCC is good, but I don't think that would justify > > abandoning compatibility with Clang. > > I am certainly not abandoning compatibility with Clang. What gives > you this impression? I read the description as it says it allows to introduce GCC extensions which breaks builds with Clang.