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?
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 may 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.
(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.
(Arch does not ship this, although it's available in the AUR [2].)
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.
ἔρρωσθε,
Zebediah
[1] The basic problem is that applications can and often do ship with PE
builds of cross-platform libraries. These libraries can be ahead of
Wine's system libraries, behind them, or even built with custom patches.
Accordingly we really don't want to load "our" freetype in place of
"their" freetype, or "theirs" in place of "ours". But because of the way
the Win32 loader works, you can generally only have one DLL of a given
name loaded in a process, and further attempts to dlopen() [as it were]
"libfreetype-6.dll" will return the handle to the already loaded
library, potentially breaking either Wine or the application. There
*may* be ways we can hack around this internally, but it's not clear
that it's feasible yet, and so it's probably best to assume that we'll
need special builds of dynamic libraries.
[2] https://aur.archlinux.org/packages/mingw-w64-pkg-config/
