diff mbox series

[v2,05/13] qemu-plugin.h: remove GCC < 4

Message ID 20201126112915.525285-6-marcandre.lureau@redhat.com
State New
Headers show
Series Remove GCC < 4.8 checks | expand

Commit Message

Marc-André Lureau Nov. 26, 2020, 11:29 a.m. UTC
From: Marc-André Lureau <marcandre.lureau@redhat.com>

Since commit efc6c07 ("configure: Add a test for the minimum compiler
version"), QEMU explicitely depends on GCC >= 4.8.

(clang >= 3.8 advertizes itself as GCC >= 4.2 compatible)

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 include/qemu/qemu-plugin.h | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

Comments

Peter Maydell Nov. 26, 2020, 11:57 a.m. UTC | #1
On Thu, 26 Nov 2020 at 11:30, <marcandre.lureau@redhat.com> wrote:
>
> From: Marc-André Lureau <marcandre.lureau@redhat.com>
>
> Since commit efc6c07 ("configure: Add a test for the minimum compiler
> version"), QEMU explicitely depends on GCC >= 4.8.
>
> (clang >= 3.8 advertizes itself as GCC >= 4.2 compatible)
>
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
>  include/qemu/qemu-plugin.h | 9 ++-------
>  1 file changed, 2 insertions(+), 7 deletions(-)

This is an interesting case, because it's a header intended
for external use (people compiling plugins), not part of
QEMU proper. I don't know whether we want to impose the
same clang/gcc requirements on plugin builders, though it's
probably not a bad idea to do so. Alex ?

thanks
-- PMM
Daniel P. Berrangé Nov. 26, 2020, 12:12 p.m. UTC | #2
On Thu, Nov 26, 2020 at 11:57:14AM +0000, Peter Maydell wrote:
> On Thu, 26 Nov 2020 at 11:30, <marcandre.lureau@redhat.com> wrote:
> >
> > From: Marc-André Lureau <marcandre.lureau@redhat.com>
> >
> > Since commit efc6c07 ("configure: Add a test for the minimum compiler
> > version"), QEMU explicitely depends on GCC >= 4.8.
> >
> > (clang >= 3.8 advertizes itself as GCC >= 4.2 compatible)
> >
> > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > ---
> >  include/qemu/qemu-plugin.h | 9 ++-------
> >  1 file changed, 2 insertions(+), 7 deletions(-)
> 
> This is an interesting case, because it's a header intended
> for external use (people compiling plugins), not part of
> QEMU proper. I don't know whether we want to impose the
> same clang/gcc requirements on plugin builders, though it's
> probably not a bad idea to do so. Alex ?

IIUC, we expect that the plugins are built specifically to go with
the QEMU you have built. With that in mind, it looks reasonable to
assume the same compiler toolchain versions for both.

Regards,
Daniel
Peter Maydell Nov. 26, 2020, 12:14 p.m. UTC | #3
On Thu, 26 Nov 2020 at 12:12, Daniel P. Berrangé <berrange@redhat.com> wrote:
> On Thu, Nov 26, 2020 at 11:57:14AM +0000, Peter Maydell wrote:
> > This is an interesting case, because it's a header intended
> > for external use (people compiling plugins), not part of
> > QEMU proper. I don't know whether we want to impose the
> > same clang/gcc requirements on plugin builders, though it's
> > probably not a bad idea to do so. Alex ?
>
> IIUC, we expect that the plugins are built specifically to go with
> the QEMU you have built.

No, the point of the plugin interface is that it actually is
a (constrained) stable ABI with version-querying and checking
so you don't have to build a plugin against the exact matching
QEMU version. (But "don't use really ancient gcc" doesn't seem
like a very major thing to ask of its users.)

thanks
-- PMM
Alex Bennée Nov. 26, 2020, 1:13 p.m. UTC | #4
Peter Maydell <peter.maydell@linaro.org> writes:

> On Thu, 26 Nov 2020 at 12:12, Daniel P. Berrangé <berrange@redhat.com> wrote:
>> On Thu, Nov 26, 2020 at 11:57:14AM +0000, Peter Maydell wrote:
>> > This is an interesting case, because it's a header intended
>> > for external use (people compiling plugins), not part of
>> > QEMU proper. I don't know whether we want to impose the
>> > same clang/gcc requirements on plugin builders, though it's
>> > probably not a bad idea to do so. Alex ?
>>
>> IIUC, we expect that the plugins are built specifically to go with
>> the QEMU you have built.
>
> No, the point of the plugin interface is that it actually is
> a (constrained) stable ABI with version-querying and checking
> so you don't have to build a plugin against the exact matching
> QEMU version. (But "don't use really ancient gcc" doesn't seem
> like a very major thing to ask of its users.)

Quite. But I agree using a GCC from this decade seems reasonable
especially as the feature has only been in QEMU for a few cycles.

Acked-by: Alex Bennée <alex.bennee@linaro.org>
diff mbox series

Patch

diff --git a/include/qemu/qemu-plugin.h b/include/qemu/qemu-plugin.h
index bab8b0d4b3..5775e82c4e 100644
--- a/include/qemu/qemu-plugin.h
+++ b/include/qemu/qemu-plugin.h
@@ -28,13 +28,8 @@ 
   #endif
   #define QEMU_PLUGIN_LOCAL
 #else
-  #if __GNUC__ >= 4
-    #define QEMU_PLUGIN_EXPORT __attribute__((visibility("default")))
-    #define QEMU_PLUGIN_LOCAL  __attribute__((visibility("hidden")))
-  #else
-    #define QEMU_PLUGIN_EXPORT
-    #define QEMU_PLUGIN_LOCAL
-  #endif
+  #define QEMU_PLUGIN_EXPORT __attribute__((visibility("default")))
+  #define QEMU_PLUGIN_LOCAL  __attribute__((visibility("hidden")))
 #endif
 
 typedef uint64_t qemu_plugin_id_t;