[PATCH] tests: Compile virgdbusmock.c with GIO_COMPILATION enabled

Michal Prívozník mprivozn at redhat.com
Tue Mar 28 15:16:26 UTC 2023


On 3/28/23 14:54, Andrea Bolognani wrote:
> On Tue, Mar 28, 2023 at 02:29:10PM +0200, Michal Prívozník wrote:
>> On 3/28/23 12:58, Andrea Bolognani wrote:
>>> It looks like virgdbusmock is used by
>>>
>>>   networkxml2firewalltest
>>>   virfirewalltest
>>>   virsystemdtest
>>>   virpolkittest
>>>
>>> The first three are Linux-only; the last one is ELF-only, which
>>> Windows isn't and I *think* even throwing MinGW into the mix doesn't
>>> change that. In any case, enabling polkit support on Windows is
>>> explicitly blocked at the Meson level, so that test will never be
>>> built on that platform.
>>>
>>> It looks like it might be feasible to sidestep the issue entirely by
>>> simply not builing this specific mock on Windows after all.
>>
>> NB, this is already pushed, so whatever comes out of this discussion
>> will need to revert that commit.
> 
> I'm aware of that. I don't even mind if the currently merged solution
> is what ships with 9.2.0 and a better one, assuming we can come up
> with it, is implemented afterwards.
> 
>> Now - Windows PE - are we really sure that it can't work on Windows? I
>> mean, I only have a vague knowledge on PE, but IIRC then the dynamic
>> linker does symbol resolution that's very similar to ELF. IOW, the first
>> .dll to provide the symbol (i.e. our mock) wins the race.
>>
>> I'm not saying our mock works on Windows as is. Heck, we don't even run
>> !mock tests on Windows. We run no tests there. But if PE was able to do
>> mocking, then not compiling this would be pity.
> 
> I'm not sure what the "PE" you talk about is.

PE stands for Portable Executable:

https://en.wikipedia.org/wiki/Portable_Executable

It's a format (inspired by ELF, well, its predecessor COFF) that Windows
uses.

> 
> Anyway my point is that, at least as far as I can tell, all of the
> test programs that use virgdbusmock are effectively no-op on Windows,
> which means that mocking gdbus on Windows should not be necessary and
> thus not building the mock library on that platform should be viable.

Yeah. Though, there is a windows port of d-bus. But I guess nobody
really uses that.

> 
> Other mocks might work on Windows, I'm not sure. I haven't
> investigated, and I'm not making blanket statements about the topic.
> I'm only discussing this specific mock, which is the one currently
> causing us grief and which looks like we could simply stop building
> on Windows without losing anything in the process.
> 

Question then is whether to build all mocks. I mean, if we claim our
mocking to be ELF specific, then certainly it doesn't make sense to
build on !ELF OSes. But if my assumption is not right and mocking can
indeed work then I guess we should make our mocks at least compile.

Actually, let me see if I can build libvirt with mingw locally and run
test(s) with wine.

Michal



More information about the libvir-list mailing list