Native winelib support?

[cwabbott0]

As part of an adventure to get DXVK working with Hangover (https://github.com/AndreRH/hangover) I ran against the fact that there are no readily available aarch64 mingw toolchains, so the only way to build the host DLL's is as a winelib library, and for performance reasons we want DXVK to be built as a host library. DXVK used to have some support for being built as a winelib, but it was removed because it was a maintenance burden and was frequently broken. I have some hacks to get it to work again, but I think that some of the hackiness could be reduced by adding support for winelib builds in meson directly. Some of the differences compared to vanilla mingw-gcc I ran into are:

• An object suffix of .obj is not supported, it only recognizes .o, but meson uses obj by default except for cygwin (which enables other stuff like the cyg dll prefix that we don't want).
• -pthread isn't currently supported so only -lpthread works, and since the host C++ stdlib is used, you need pthread when using C++ threads like DXVK does. So the threads dependency doesn't work out of the box.
• Executables and dll's have two parts, a wrapper (a shell script for executables, and stub PE file for dll's) and the actual ELF file. Wine itself understands and can execute/link the ELF file, but the wrapper can be used with things outside of wine, like linking a normal executable/library compiled with mingw-gcc directly against a winelib dll without using the implib. For executables, the scheme is straightforward: compiling foo or foo.exe produces a wrapper called foo.exe that just calls the wine loader and an internal foo.exe.so. However for dll's it's a bit more complicated: specifying an output of foo.dll when linking makes winegcc produce foo.dll.fake (don't ask me why...) and foo.dll.so. The wine makefiles install foo.dll.fake as foo.dll together with foo.dll.so.

Some of this could, and maybe should, be worked around with patches to wine instead. But at least the last one probably needs to be handled in meson. DXVK doesn't actually require building the dll, because no one is linking against DXVK directly and wine can load the .dll.so directly, so the old winelib support in DXVK had a hack to change the shared library suffix to .dll.so and ignore the wrapper. That works enough for our use-case, but obviously isn't great.

Are there opinions about how this should be added? Should there be a winelib platform or should this be auto-detected somehow based on the compiler name?

[tristan957]

@cwabbott0 this sounds like you need to create a new Compiler class that inherits off of one of the already-existing compilers, since you only have a couple of issues to fix.

That last bullet kind of sounds like a module would be the way to attack the problem. I think your module could be akin to the GNOME module. Specific behaviors for working with WINE-based projects just the GNOME module is specific behaviors for working with GNOME-based projects.

[dcbaker]

I suppose conceptually winelib based outputs really aren't that different than cygwin or msys. I think it's doable, and it's probably worth solving for dxvk if nothing else. I might be able to spend some time looking at it in the future, though I've got a pretty fully plate at the moment.

[cwabbott0]

As an update, my wine patches fixing the first two bullets have now landed and are in Wine 6.12.

Revisiting this again, I don't think a module is the right solution. The issue is that both the executable wrapper and .so ELF file are created at the same time, so it really needs to be something the compiler aware of - a single invocation of the linker with -o foo.dll will produce foo.dll.so, foo.dll.a, and foo.dll.fake and then foo.dll.fake needs to be installed as foo.dll. So in other words the executable wrapper needs to be plumbed though everywhere the implib currently is. We could create a new compiler class, but would it be possible to then propagate all that information up to the installer, or would we need to make a new platform?

[guijan]

Is this still being worked on?

I can't help with development because I don't know Python, but here's a project and branch with automated CI for it: https://github.com/guijan/libobsd/tree/add-winelib Here's a CI run: https://github.com/guijan/libobsd/runs/5644921927?check_suite_focus=true

The current winelib support in Meson can compile a hello world, but Meson doesn't understand that winegcc adds a suffix to the executables and libraries it creates as pointed out above. This makes tests and custom targets (if their command is an executable produced by Meson) fail with a "file not found" error.