Re: Wine MinGW system libraries
Le lun. 6 sept. 2021 à 06:57, Stephen Kitt <skitt@debian.org> a écrit :
>
> 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).
I will really prefer something less laborious. Like using flexdll for
your own library.
Moreover using a custom loader will decrease the patching burden for
debian side, so a win win.
Bastien
> > > 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?
>
> > >> 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...
>
> Regards,
>
> Stephen
Reply to: