Le lun. 6 sept. 2021 à 18:36, Zebediah Figura <zfig...@codeweavers.com> a écrit :
> On 9/6/21 1:57 AM, Stephen Kitt wrote: > > 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). > > > >>> 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. > > ἔρρωσθε, > Zebediah > >
