On 3/28/23 10:33, Andrea Bolognani wrote:
> On Mon, Mar 27, 2023 at 02:47:40PM +0200, Michal Privoznik wrote:
>> There are couple of g_dbus_*() functions we provide an
>> alternative implementation for in our virgdbusmock.c. However,
>> these functions are declared in gio/gdbusconnection.h as:
>>
>> GIO_AVAILABLE_IN_ALL
>> GDBusConnection *g_bus_get_sync (GBusType bus_type,
>> GCancellable *cancellable,
>> GError **error);
>>
>> where GIO_AVAILABLE_IN_ALL is declared as (in
>> /gio/gio-visibility.h):
>>
>> #if (defined(_WIN32) || defined(__CYGWIN__)) && !defined(GIO_STATIC_COMPILATION)
>> # define _GIO_EXPORT __declspec(dllexport)
>> # define _GIO_IMPORT __declspec(dllimport)
>> #elif __GNUC__ >= 4
>> # define _GIO_EXPORT __attribute__((visibility("default")))
>> # define _GIO_IMPORT
>> #else
>> # define _GIO_EXPORT
>> # define _GIO_IMPORT
>> #endif
>> #ifdef GIO_COMPILATION
>> # define _GIO_API _GIO_EXPORT
>> #else
>> # define _GIO_API _GIO_IMPORT
>> #endif
>>
>> #define _GIO_EXTERN _GIO_API extern
>>
>> #define GIO_AVAILABLE_IN_ALL _GIO_EXTERN
>>
>> Now, on mingw the functions we mock are declared with dllimport
>> attribute which makes the compiler unhappy:
>>
>> ../tests/virgdbusmock.c:25:24: error: 'g_bus_get_sync'
>> redeclared without dllimport attribute: previous dllimport
>> ignored [-Werror=attributes]
>>
>> The solution is to do what glib does when it compiles the gio
>> module: set GIO_COMPILATION macro which in turn annotates the
>> function with dllexport attribute.
>
> I will point out that GIO_COMPILATION is not intended to be used
> outside of GLib: it signals that the gio module is in the process of
> being built, which can result (as is the case here) in different
> behavior compared to what you'd see when building *against* gio.
>
> So defining it as part of building libvirt is quite yucky, and I
> wouldn't be surprised if this trick stopped working or ended up
> causing other unintended consequences in the future.
That's something we're already used to since switching to glib. This but
another quirk that we have to deal with.
>
> Unfortunately, I also don't really have a better alternative to
> suggest, so I guess it is what it is :)
>
Maybe don't build mocks on mingw? Do they even work, or better: can they?
Michal
