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

[Michal Prívozník]

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.
> 
> 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.
> 
> 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.
> 

Ha, so after many failed attempts I am able to compile and *RUN* our
test suite under wine. I needed to hack the meson cross file mingw
ships. Anyway, what I'm seeing is couple of failed tests:


 14/213 libvirt / domaincapstest         FAIL  0.84s   exit status 1
 27/213 libvirt / sockettest             FAIL  0.42s   exit status 1
 28/213 libvirt / sysinfotest            FAIL  0.44s   exit status 1
 29/213 libvirt / storagevolxml2xmltest  FAIL  0.46s   exit status 1
 38/213 libvirt / vircryptotest          FAIL  0.42s   exit status 1
 41/213 libvirt / virfilecachetest       FAIL  0.44s   exit status 1
 46/213 libvirt / viridentitytest        FAIL  0.44s   exit status 3
 50/213 libvirt / virlockspacetest       FAIL  0.36s   exit status 1
 57/213 libvirt / virrotatingfiletest    FAIL  0.45s   exit status 1
 59/213 libvirt / virstringtest          FAIL  0.44s   exit status 1
 65/213 libvirt / vshtabletest           FAIL  0.44s   exit status 1


Now, some of these are true bugs (either in our code or in wine). I'll
try to post patches. Nevertheless, I can confirm that mocking works with
.dll too. Therefore, I'd like to continue building mocks AND keep this
original patch as is.

Michal