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