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?
Yes i really prefer (2) it means we could use multiarch easilly....
Please try to document thé blocking point.