New subject: [Fedora-packaging] Re: Wine MinGW system libraries

Thursday, 2 September 2021

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 Fedora [1] [2], as 
by many distributions, on the grounds that they cause duplication of 
libraries on disk and in memory, and make it harder to update the 
libraries in question (see also question 2). They also 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. Accordingly we need each library 
to be renamed, and to link to renamed dependencies. For example, if 
application X ships with its own copy of libfreetype-6.dll, we need to 
make sure that our gdi32.dll links to libwinefreetype-6.dll instead, and 
that libwinefreetype-6.dll links to libwineharfbuzz-0.dll and 
winezlib.dll. I think, although I haven't completely verified yet, that 
this can be done just with build scripts (i.e. no source patches), by 
using e.g. --with-zlib=/path/to/winezlib.dll.

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).

I expect that Fedora (and most distributions) want to answer "packaged 
separately" here, on the grounds that this lets them update (say) Wine's 
libgnutls separately, and in sync with ELF libgnutls, if some security 
fix is needed. There is a snag, though: we need libraries to be copied 
into the prefix (there's some internal effort to allow using something 
like symlinks instead, but this hard and not done yet). Normally we 
perform this copy every time Wine is updated, but if Wine and its 
dependencies aren't updated on the same schedule, we may end up loading 
an old version of a dependency in the prefix, thus missing the point of 
the update.

(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. We would 
need a way for Wine's configure script to find these packages—and 
ideally find them automatically, or else fall back to a submodule-based 
approach.

If we rely on distributions to provide our dependencies, the best idea I 
have here would be something like a x86_64-w64-mingw32-pkg-config. And 
if we use shared libraries rather than static, things get worse: we need 
to know the exact path of each library and its dependencies so that we 
can copy (or symlink) them into a user's WINEPREFIX.

For what it's worth, the current proposed solution (which has the 
support of the Wine maintainer) involves source imports and submodules. 
There's probably room for changing our approach even after things are 
committed, but I'd still like to get early feedback from distributions, 
and make sure that their interests are accurately represented, before we 
commit. In short, it's not clear whether distributions want their 
no-static-library policies to apply to us as well, or whether we're 
enough of a special case and would be enough of a pain to package that 
they'd rather we deal with the hard parts, and I don't want us to make 
any assumptions.

ἔρρωσθε,
Zebediah

[1] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-stat...

[2] https://fedoraproject.org/wiki/Bundled_Libraries

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wine MinGW system libraries