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
