widl from mingw-w64-tools-git doesn't find standard libraries and includes

[heljkon]

On preparing qemu 7.0 I had to add a

cd qga/vss-win32
widl -I${MINGW_PREFIX}/include -L${MINGW_PREFIX}/include \
  -t "${srcdir}"/${_tarname}/qga/vss-win32/qga-vss.idl -o qga-vss.tlb

because it was simply not triggered. This is the meson custom_target

$ grep widl src/qemu-7.0.0-rc4/qga/vss-win32/meson.build
                          command: [widl, '-t', '@INPUT@', '-o', '@OUTPUT@'])

But even if it would be triggered by meson, the custom_target misses includes and libraries residing in ${MINGW_PREFIX}/include, because qga-vss.idl references *.idl and *.tlb

$ egrep "*.(idl|tlb)" src/qemu-7.0.0-rc4/qga/vss-win32/qga-vss.idl
import "oaidl.idl";
import "ocidl.idl";
    importlib("stdole2.tlb");

I filed a patch for both issues, but was told to check for '--with-widl-include' by qemu-devel list. I expect the trigger patch to be accepted which leaves the options open.

Testing wild configured with '--with-widl-include' (see heljkon@0b95d5a) I still receive

[1421/1748] Generating qga/vss-win32/gen-tlb with a custom command
FAILED: qga/vss-win32/qga-vss.tlb
"C:\msys64\clang64\bin/widl.EXE" "-t" "../qemu-7.0.0-rc4/qga/vss-win32/qga-vss.idl" "-o" "qga/vss-win32/qga-vss.tlb"
error: Could not find importlib stdole2.tlb.

'--with-widl-include' seems to be a good configure option for widl option '-I${MINGW_PREFIX}/include' which leave widl option '-L${MINGW_PREFIX}/include' to be fixed.

Any ideas?

[Biswa96]

Those will be replaced with mingw-w64 headers. There was a discussion in mingw-w64 mailing list https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/CAJ%2BF1CK2LB6rqN294Rk9_uWeSKKCr5ERqouaxeBJC1NwJi9Xqw%40mail.gmail.com/#msg37601955. RedHat devs are working on this fork https://gitlab.com/bonzini/qemu/-/tree/meson-poc-next. I am not sure when it will be in upstream. You can disable qgs option in meson for now.

[Biswa96]

@elmarco may provide some detailed information.

[heljkon]

It was @elmarco who proposed to check for '--with-widl-include'.

Using the manual widl command above I succeeded in building the qemu-ga VSS module.

I've tested qemu-ga VSS module as well: it can be started and stopped after being installed as a service. Unfortunatly I wasn't able to test the functionality ot this module due to the lack of a Windows Server license

see https://github.com/heljkon/MINGW-packages/blob/mingw-w64-qemu-7.0.0-1/mingw-w64-qemu/msys2.qemu-guest-agent.txt

qemu-ga VSS module will be included in qemu 7.0

What do you mean with "Those will be replaced with mingw-w64 headers."?

Actually I'm working on very current commits made by @elmarco to the meson process - before these changes the product of widl was actually part of the qemu sources.

see https://gitlab.com/qemu-project/qemu/-/commits/master/qga/vss-win32/meson.build

[Biswa96]

What do you mean with "Those will be replaced with mingw-w64 headers."?

Scratch that, I was thinking of another IDL file which was not present in MS Windows SDK.

Unfortunately I wasn't able to test this software due to the lack of a Windows Server license

Really? 😈

'--with-widl-include' seems to be a good configure option for widl

Isn't it possible to add -I or -L options in meson file? This is required for qemu. So, adding widl command line options in meson.build seems to be a better in my opinion.

BTW, are we considering cross compilation environments also?

[heljkon]

'--with-widl-include' seems to be a good configure option for widl

Isn't it possible to add -I or -L options in meson file? This is required for qemu. So, adding widl command line options in meson.build seems to be a better in my opinion.

This was my first approach. I filed a patch for it to qemu-devel and @elmarco proposed to try '--with-widl-include'

BTW, are we considering cross compilation environments also?

I expected my patch to do no harm to other environments, because of the checks I introduced...

[elmarco]

widl should know where are the standard include and library paths.

@heljkon's QEMU patch shouldn't be necessary, it's trying to "guess" those which is not a good idea.

[heljkon]

As stated above '--with-widl-include' helps to find the referenced '*.idl' files and thus wipes the -I option. (I remember widl to complain about missing '*.idl' first)

But I didn't recognize a widl configure option to wipe the -L option.

[lhmouse]

I am not familiar with widl, but it looks to me like that --with-widl-includedir is (and probably should be) only useful if someone wishes to use non-canonical include paths, such as when cross-compiling from Linux.

[kostyanf14]

I looked into the widl source code and think that it detects the default include path incorrectly.

During the build of widl tool the corresponding variable receives an incorrect value:
BIN_TO_INCLUDEDIR = ../x86_64-w64-mingw32/include but should be
BIN_TO_INCLUDEDIR = ../include. Looks like a package mismatch,
because the /ming64/x86_64-w64-mingw32 directory exists
but contains only a few libs and no any include files.

When I checked the build using cross-compilation from Linux,
the widl tool uses proper BIN_TO_INCLUDEDIR.

So I think we don't need --with-widl-includedir for now.

[heljkon]

Thanks for your help!

I wasn't able to solve this issue by configure options only because of missing importlib stdole2.tlb

I've created a patch for tools-git now which works for me. It still needs a little bit of improvement, so I'll prepare a PullRequest after work today.