On 3/28/23 12:58, Andrea Bolognani wrote:
On Tue, Mar 28, 2023 at 12:27:12PM +0200, Michal Prívozník wrote:
> On 3/28/23 10:33, Andrea Bolognani wrote:
>> 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?
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.
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.
Michal