Le lun. 6 sept. 2021 à 06:57, Stephen Kitt <sk...@debian.org> a écrit : > > On Sun, 5 Sep 2021 12:14:47 -0500, Zebediah Figura <zfig...@codeweavers.com> > wrote: > > On 9/5/21 11:19 AM, Stephen Kitt wrote: > > > On Sat, 4 Sep 2021 20:17:53 -0500, Zebediah Figura > > > <zfig...@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
