win32/msys: libva.pc causes app dependency on non-existing va.dll

[dvrogozh]

Using msys2 to build libva and libva-utils:

pacman -S msys/bison msys/flex msys/git mingw64/mingw-w64-x86_64-meson mingw64/mingw-w64-x86_64-python-mako mingw-w64-x86_64-toolchain
git clone https://github.com/intel/libva.git && cd libva
meson setup --prefix=/c/install _build
meson compile -C _build
meson install -C _build
cd ..
export PKG_CONFIG_PATH=/c/install/lib/pkgconfig
git clone https://github.com/intel/libva-utils.git && cd libva-utils
meson setup --prefix=/c/install _build
meson compile -C _build
meson install -C _build

After that we are getting this:

$ ls
libva.dll  libva_win32.dll  vainfo.exe
$ ldd vainfo.exe
        ntdll.dll => /c/windows/SYSTEM32/ntdll.dll (0x7ffe1eaa0000)
        KERNEL32.DLL => /c/windows/System32/KERNEL32.DLL (0x7ffe1ceb0000)
        KERNELBASE.dll => /c/windows/System32/KERNELBASE.dll (0x7ffe1c3e0000)
        msvcrt.dll => /c/windows/System32/msvcrt.dll (0x7ffe1e9b0000)
        va.dll => not found
        va_win32.dll => not found

I.e. vainfo depends on non-existing va.dll and va_win32.dll. @sivileri : fyi

[dvrogozh]

@eli-schwartz can you advise on this issue? is there a way in meson to query library link name to put in .pc file?

[eli-schwartz]

So clearly it should depend on libva.dll rather than va.dll, but due to Microsoft things, either one could be intended by -lva. This is somewhat more complex because actually it looks for an import library, not a dll, at link time.

Obviously this worked somehow when compiling libva-utils -- meson, and the compiler, found the intended libraries. This would be reported by the verbose compilation logs that were omitted from the bug report

So the question is, why does libva-utils link to an import library successfully, but then erroneously think that the associated DLL file name to embed into the vainfo.exe binary metadata should be different from what it actually is?

[eli-schwartz]

  vs_module_defs : 'libva.def',

This file hardcodes the library name as "va", which is fine as long as you also conditionally set the name prefix in meson to empty on platforms where that def file is used.

[dvrogozh]

Should we just drop hardcoding library name entirely from .def file and fully rely on the compiler?

$ cat libva_win32.def
EXPORTS
    vaGetDisplayWin32

This seems working with mingw32 and vainfo start depend on libva*.dll libs. I am not sure though how much specifying LIBRARY in the .def file is a requirement.

So, I create #712 PR with such a fix. Appreciate review.