Hi Bastien, On Sun, 5 Sep 2021 08:53:49 +0200, Bastien ROUCARIES <roucaries.bast...@gmail.com> wrote: > Le dim. 5 sept. 2021 à 03:34, Zebediah Figura <zfig...@codeweavers.com> a > écrit : > > 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. > > > > Accordingly, although static linking and source imports are generally > > disprefered, it may quite likely be preferable in our case. We don't get > > the benefits of on-disk deduplication, since Wine is essentially the > > only piece of software which needs these libraries. > > > > (2) If we use dynamic libraries, should dependencies be included in the > > main wine package, or packaged separately? > > > > > Improve dpkg to support partial arch. I volonteer to implement none arch > but i am waiting from guillem here.
Thanks for stepping up! For MinGW-w64 dependencies, an additional requirement is figuring out a solution for https://bugs.debian.org/606825; https://wiki.debian.org/Teams/Dpkg/FAQ#Q._Can_we_add_support_for_new_dpkg_architectures.3F gives additional context. Regards, Stephen
pgpHCEnwcfbXF.pgp
Description: OpenPGP digital signature
