On 9/6/21 1:57 AM, Stephen Kitt wrote:
On Sun, 5 Sep 2021 12:14:47 -0500, Zebediah Figura <
zfigura@codeweavers.com>
wrote:
On 9/5/21 11:19 AM, Stephen Kitt wrote:
On Sat, 4 Sep 2021 20:17:53 -0500, Zebediah Figura
<zfigura@codeweavers.com> wrote:
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?
Source imports are dispreferred by Debian [1], on the grounds that
they
cause duplication of libraries on disk and in memory, and make it
harder
to handle security updates. They also make building and bisecting
harder. Static libraries don't seem to be expressly discouraged, but
share most of the same downsides (see also [2]).
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.
Assuming Debian provides the dependencies (which is currently true only
for zlib), this could be handled in packaging by providing symlinks,
couldn’t it? Not in the Wine prefixes, but elsewhere.
Almost :-/
Copying/symlinking libfreetype-1.dll to libwinefreetype-1.dll is easy.
The problem is that libwinefreetype-1.dll is still going to link to
libharfbuzz-1.dll, but we need it to link to libwineharfbuzz-1.dll.
Ah yes, I hadn’t thought it through. So really Wine needs its own
parallel
ecosystem of DLLs in any case, which effectively means building them
along
with Wine (from Wine’s perspective, ignoring distribution constraints and
preferences).
This also works in Debian:
$ sudo apt install libz-mingw-w64-dev mingw-w64-tools
$ x86_64-w64-mingw32-pkg-config --libs zlib
-L/usr/x86_64-w64-mingw32/lib -lz
Ah, cool, I looked for that and somehow missed it.
Note that's the wrong path for dynamic libraries, though; those go in
/usr/x86_64-w64-mingw32/bin/. We'll need a way to find those. Maybe
hardcoding a list won't be too painful, though...
In Debian they go in /usr/x86_64-w64-mingw32/lib currently, which is why
the .pc file points there. But as you point out, that doesn’t help at
runtime.
Also, having pkg-config support doesn’t really help with a parallel set
of
DLLs, does it?
I mean... eh. In theory you could say "here's a library called
libwinefreetype, and to find it you do `pkg-config --cflags --libs
libwinefreetype`", but that does strike me as more than a little janky.
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.
Realistically, I think this is the best approach for now. As Debian
adds
support for PE libraries, we can replace the source imports in the Wine
source code; this is done in many other Debian packages for projects
which
vendor dependencies.
I still think this is true. With requirement for a Wine-specific set of
DLLs,
improving the situation in Debian would involve supporting source
build-dependencies, i.e. being able to say that a given package wants
access
to the source code of another package. That’s something that’s been
brought
up previously, and is worked around by providing binary packages
containing
package source code (e.g. binutils-source, gcc-11-source etc.), but isn’t
really upstream’s concern, in that it’s a Debian implementation detail.
Going back to your original three questions, I think that the best
approach
for you as upstream is to focus on providing a complete set of source
code
(including dependencies) which works, and to make it friendlier to
distributions, make the build process capable of handling alternative
locations for the dependencies’ source code or even build artifacts.
(This
has a number of knock-on effects — in particular, you should ensure that
the
upstream source code for all your dependencies works with Wine, i.e. that
Wine doesn’t require Wine-specific patches to any of its dependencies.)
Given how varied MinGW-w64 handling is in different distributions,
pushing
things further risks making it easier for one distribution and harder
for the
others...
Thanks for the detailed response!
It's probably worth pointing out that:
(1) if we use static linking, we should be able to use distribution
libraries unmodified. Of course, static linking comes with its own
downsides...
(2) Like I mentioned or hinted at in my original email, it *may* be
possible to use distribution dynamic libraries unmodified. It's not
clear that it can be done without breaking compatibility, but if it can,
would that change anything?