Re: Wine MinGW system libraries
Le lun. 6 sept. 2021 à 06:57, Stephen Kitt a écrit : > > On Sun, 5 Sep 2021 12:14:47 -0500, Zebediah Figura > wrote: > > On 9/5/21 11:19 AM, Stephen Kitt wrote: > > > On Sat, 4 Sep 2021 20:17:53 -0500, Zebediah Figura > > > 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 app
Require packages to build without any configured DNS
Hi, during the year, a src:dnspython change made it so that any software importing that library now requires a valid /etc/resolv.conf with at least one nameserver configured. This also made it so that something between 50-100 packages now fail to build if the build system doesn't have any working /etc/resolv.conf. I venture to say that this is a very reasonable configuration to have in a build system that tries to be network-disabled. It must be noted that no actual network operation happen, so this doesn't fall into the "no network activity" bucket. This is the bug that was filed against dnspython: https://bugs.debian.org/989171 Do anybody on the list have any opinion on where is the bug, on dnspython, or on the build environment? As the pbuilder maintainer, I've been asked to make it serve a non-working /etc/resolv.conf just to make that bug above moot, so I'm quite biased on the matter myself :) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Wine MinGW system libraries
On 9/6/21 1:57 AM, Stephen Kitt wrote: On Sun, 5 Sep 2021 12:14:47 -0500, Zebediah Figura wrote: On 9/5/21 11:19 AM, Stephen Kitt wrote: On Sat, 4 Sep 2021 20:17:53 -0500, Zebediah Figura 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 woul
Re: Wine MinGW system libraries
Le lun. 6 sept. 2021 à 18:36, Zebediah Figura 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 > >>> 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 wort
Re: Wine MinGW system libraries
On 9/6/21 1:34 PM, Bastien ROUCARIES wrote: Le lun. 6 sept. 2021 à 18:36, Zebediah Figura 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 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 o
Re: Wine MinGW system libraries
On Mon, Sep 6, 2021 at 9:54 PM Zebediah Figura wrote: > The basic problem is that applications can and often do ship with PE > builds of cross-platform libraries. These libraries can be ahead of > Wine's system libraries, behind them, or even built with custom patches. > Accordingly we really don't want to load "our" freetype in place of > "their" freetype, or "theirs" in place of "ours". But because of the way > the Win32 loader works, you can generally only have one DLL of a given > name loaded in a process, and further attempts to dlopen() [as it were] > "libfreetype-6.dll" will return the handle to the already loaded > library, potentially breaking either Wine or the application. I don't know the details here, but my immediate thought when reading this is that you need some kind of namespace. I then found that linker namespaces are a thing, perhaps they would provide the solution for you. It sounds like the OpenGL shim loader solution listed on the glibc wiki might work for your use-case. Or perhaps the LD_AUDIT feature would also work. https://www.sourceware.org/glibc/wiki/LinkerNamespaces -- bye, pabs https://wiki.debian.org/PaulWise
