On Mon, Sep 6, 2021 at 7:37 PM Zebediah Figura <zfigura@codeweavers.com> wrote:
Hello all,
I'm a contributor to the Wine project. To summarize the following mail, Wine needs special versions of some of its normal dependencies, such as libfreetype and libgnutls, built using the MinGW cross-compiler, and I'm sending out a mail to major distributions in order to get some feedback from our packagers on how these should be built and packaged.
For a long time Wine has built all of its Win32 libraries (DLLs and EXEs) as ELF binaries. For various reasons related to application compatibility, we have started building our binaries as PE instead, using the MinGW cross-compiler. It is our intent to expand this to some of our dependencies as well. The list of dependencies that we intend to build using MinGW is not quite fixed yet, but we expect it to include and be mostly limited to the following:
* libvkd3d * libFAudio * libgnutls * zlib (currently included via manual source import) * libmpg123 * libgsm * libpng * libjpeg-turbo * libtiff * libfreetype * liblcms2 * jxrlib
and dependencies of the above packages (not including CRT dependencies, which Wine provides).
There is currently some internal discussion about how these dependencies should be built and linked. There are essentially three questions I see that need to be resolved, and while these resolutions have a significant impact on the Wine building and development process, they also have an impact on distributions, and accordingly I'd like to get input from our packagers to ensure that their considerations are accurately taken into account.
(1) Should we build via source import, or link statically, or dynamically?
Static linking and source imports are dispreferred by openSUSE [1] [2], on the grounds that they make it harder to handle security updates. They also take up more space on disk, and make building and bisecting harder.
Note however that if they are linked dynamically, we need to make sure that we load our packages instead of MinGW builds of open-source libraries with applications ship with. There's some internal discussion about whether this is possible while using "stock" builds of MinGW libraries, but, due to the way the Win32 loader works, we will probably need to compile each library, and its dependencies, with a separate, wine-specific name, e.g. "libwinefreetype-6.dll" and "libwineharfbuzz.dll". For a detailed explantion see footnote [3]. Note that all we actually need to change is the name; we don't need to patch the source.
Accordingly, although static linking and source imports are generally disprefered, it may quite likely be preferable in our case. We don't get the benefits of on-disk deduplication, since Wine is essentially the only piece of software which needs these libraries.
(2) If we use dynamic libraries, should dependencies be included in the main wine package, or packaged separately?
This is mostly a question for packagers, although it also relates to (3).
(3) If dependencies are packaged separately, should Wine build them as part of its build tree (e.g. using submodules), or find and link (statically or dynamically) to existing binaries?
Linking to existing binaries is generally preferable: it avoids duplication on disk; it reduces compile times when compiling a single package from source (especially the first time). However, we aren't going to benefit from on-disk duplication. And, most importantly, unlike with ELF dependencies, there is no standardized way to locate MinGW libraries—especially if it comes to Wine-specific libraries. There is a MinGW version of pkg-config shipped by many distributions, which lets us find libraries, but there's no standardized way to find them at runtime. (Also, as far as I can tell, openSUSE doesn't build MinGW pkg-config? I couldn't seem to find it anywhere. That could be trivially solved, though.)
We switched to pkgconf some years ago... I wonder if the folks maintaining the MinGW stack switched over to using pkgconf's "personality" feature to support requesting various targets from pkgconf. If they did, then that would explain the lack of MinGW build of pkgconfig. -- 真実はいつも一つ！/ Always, there's only one truth!