[RFC PATCH 0/5] XAudio PE conversion.

[Rémi Bernon]

On 6/25/21 2:38 PM, Jacek Caban wrote:
> On 6/23/21 8:38 PM, Alexandre Julliard wrote:
>> And honestly, building our dependencies as PE and linking them
>> statically would make things so much easier for everybody, that there
>> would need to be strong practical reasons to go out of our way to start
>> relying on distro packages for this. A general dislike of the approach
>> is not good enough IMHO.
> 
> 
> I agree that it's a good way to move forward.
> 
> To implement it, we will need to build dependencies with winegcc (rather 
> than plain mingw). I did experiment with it last year, you may see it here:
> 
> https://github.com/cjacek/wine-addons
> 
> While the build system itself is just a rough draft and needs 
> rethinking, it shows how to build static libs with winegcc (it links 
> them into standalone PE files, but they should be ready to statically 
> link to Wine modules as well).
> 
> We will probably also need such static libs to be more portable by 
> getting rid of libgcc dependency, but that's a latter step.
> 
> Jacek
> 

Hi all!

I went ahead on this approach, to see how nicely this could be 
integrated into Wine build, things well pretty well, and I reached a 
point where I'm quite happy with the result.

FAudio was my starting point, for XAudio libraries conversion, but 
things turned out well and I've been able to integrate several other 
dependencies pretty easily.

I don't know if I should invest more time on it, and I don't really know 
if we need this to even cover all these dependencies, it would be nice 
to make a list of which one we really need here (some may be hard to 
integrate that way, see at the bottom of the message).


# Where

If you are interested in having a look, I've pushed the related Wine 
changes to https://github.com/rbernon/wine, in a "wip/wine-ext" branch, 
with the text format patches here:

   https://github.com/rbernon/wine/compare/master...wip/wine-ext.patch

As well as the dependencies sources in "wine-ext" repository to 
aggregate them:

   https://github.com/rbernon/wine-ext

(The Wine patches include a bunch of not completely related commits, 
more specifically gdi32 font parsing, to ease the conversion of some 
unixlib code back to PE, I'll probably send them upstream at some point).


# How

The "wine-ext" repository references a fork of every dependency as a 
submodule. It needs to be cloned somewhere, with "--recurse-submodules", 
and then its path provided to "configure --with-wine-ext=<path>", which 
will check that its "VERSION" file number is what current version of 
Wine expects.

The repository can also be exported as a versioned tarball of all the 
sources, eventually downloaded, extracted and used in the same way.). I 
didn't even had to make any modification to the dependencies sources, 
and I just referenced the current latest release for each.


(To be completely honest I'm not even sure if submodules are really 
useful here, I don't really see what difference it would make to just 
extract their release tarballs... maybe it would lack the ability to do 
bisect on them, I don't know if that's useful.)

(I'm also not completely sure if it makes a real conceptual difference 
with including these sources directly in Wine tree, but I can see how 
this is a bit "cleaner".)


For every dependency, there's a Makefile.in in a new external/ folder in 
Wine source, and it references sources from the "wine-ext" location.

The dependencies then are built as static libraries. They could very 
well be changed to DLL without trouble, we would have to define a spec 
file for each one though.

(Having all built as static libraries makes everything a bit more 
verbose, as for instance, winefreetype depends on winezlib, winepng and 
others, and they all need to be added as imports to anything which needs 
winefreetype.)

Any module which would need functionality from these libraries is 
converted to import them, and add the relevant include flags from the 
"wine-ext" directory, in order to find the library headers.

(For simplicity, it's a hard dependency requirement, and if the 
"wine-ext" folder is not provided then the modules are disabled. It may 
be better to make that optional, but it would make the changes more 
complicated too.)


# Plumbing

It required adapting makedep a little bit to make it less strict on 
external sources, mostly to pass some conditional includes that aren't 
taken anyway, or because they sometimes include a "config.h", which 
would end up in some other location than Wine's "config.h".

Most of the time, we don't need anything more than a few extra 
compilation defines. For a few dependencies (libpng, mpg123), I added 
some plumbing headers in Wine source to make them happy, and it's a bit 
ugly, although the plumbing is very small.

These headers could also very well live in "wine-ext" instead but as it 
sometimes drives the enabled features it may be better to have them in Wine.


# Problems

Among the possible issues that went to mind:

* Would it cause licensing problems?  The "wine-ext" repository has a 
Makefile to create a tarball of all the sources, so they can be then 
redistributed (and eventually used to build Wine instead of the 
repository with submodules), so maybe it's all fine?

* There's some remaining dependencies, although I thought maybe they 
weren't the most important ones, and maybe a unixlib split could be more 
appropriate:

  - OpenAL is written in C++, and although Wine build system could 
perhaps be adapted to support building C++ sources, I faced a lot of 
compilation errors and didn't feel the energy to dig further.

  - libgphoto2 could be compiled, but its Win32 support seems to depend 
on MinGW posix runtime, so it misses a lot of things when built in Wine. 
I saw people mentioning MSVC builds, so maybe I missed something there.

   (It's a lot of code though, and I'm not sure if it's even going to be 
working in the Win32 world as it seems to be accessing some low-level 
camera stuff. There again I didn't spend much time on it.)

  - libcapi and libctapi, but I'm not sure if it's just a matter of 
building for Win32, and I didn't even try adding them.

* Some dependencies aren't built with all the features enabled:

   - mpg123 more specifically doesn't have its assembler optimizations. 
I think it may be possible to include them, but they are not in C but as 
separate assembly file for every architecture, and I didn't find an easy 
way to build them conditionally.

   - freetype2 also misses a few things, notably harfbuzz. I added 
brotli and bzip2 more for fun than anything, and it also went well, but 
harfbuzz is C++ too and it may be more complicated. I'm not sure how 
much of a trouble this is. Of course there's always the option not to 
use the PE freetype here, the unixlib split is done already.


Cheers,
-- 
Rémi Bernon <rbernon at codeweavers.com>