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,