Hello all,
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?
Static linking and source imports are dispreferred by Fedora [1] [2], as by many distributions, on the grounds that they cause duplication of libraries on disk and in memory, and make it harder to update the libraries in question (see also question 2). They also make building and bisecting harder.
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. Accordingly we need each library to be renamed, and to link to renamed dependencies. For example, if application X ships with its own copy of libfreetype-6.dll, we need to make sure that our gdi32.dll links to libwinefreetype-6.dll instead, and that libwinefreetype-6.dll links to libwineharfbuzz-0.dll and winezlib.dll. I think, although I haven't completely verified yet, that this can be done just with build scripts (i.e. no source patches), by using e.g. --with-zlib=/path/to/winezlib.dll.
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?
This is mostly a question for packagers, although it also relates to (3).
I expect that Fedora (and most distributions) want to answer "packaged separately" here, on the grounds that this lets them update (say) Wine's libgnutls separately, and in sync with ELF libgnutls, if some security fix is needed. There is a snag, though: we need libraries to be copied into the prefix (there's some internal effort to allow using something like symlinks instead, but this hard and not done yet). Normally we perform this copy every time Wine is updated, but if Wine and its dependencies aren't updated on the same schedule, we may end up loading an old version of a dependency in the prefix, thus missing the point of the update.
(3) If dependencies are packaged separately, should Wine build them as part of its build tree (e.g. using submodules), or find and link (statically or dynamically) to existing binaries?
Linking to existing binaries is generally preferable: it avoids duplication on disk; it reduces compile times when compiling a single package from source (especially the first time). However, we aren't going to benefit from on-disk duplication. And, most importantly, unlike with ELF dependencies, there is no standardized way to locate MinGW libraries—especially if it comes to Wine-specific libraries. We would need a way for Wine's configure script to find these packages—and ideally find them automatically, or else fall back to a submodule-based approach.
If we rely on distributions to provide our dependencies, the best idea I have here would be something like a x86_64-w64-mingw32-pkg-config. And if we use shared libraries rather than static, things get worse: we need to know the exact path of each library and its dependencies so that we can copy (or symlink) them into a user's WINEPREFIX.
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. In short, it's not clear whether distributions want their no-static-library policies to apply to us as well, or whether we're enough of a special case and would be enough of a pain to package that they'd rather we deal with the hard parts, and I don't want us to make any assumptions.
ἔρρωσθε, Zebediah
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-static-...
On 9/2/21 12:08 PM, Florian Weimer wrote:
- Zebediah Figura:
(2) If we use dynamic libraries, should dependencies be included in the main wine package, or packaged separately?
Aren't many of them already packages separately? For example mingw32-libpng and mingw32-gnutls?
Thanks, I wasn't aware of these. I had tried to search for Fedora mingw packages, but didn't realize that looking up "mingw" on rpmfind.net wasn't enough :-/
Note that this ties into (3) though. It would presumably be enough for static libraries, but we need specially named shared libraries, and we can't "just" use these packages since as far as I'm aware there's no standardized way to find them.
On Thu, Sep 02, 2021 at 12:11:43PM -0500, Zebediah Figura (she/her) wrote:
On 9/2/21 12:08 PM, Florian Weimer wrote:
- Zebediah Figura:
(2) If we use dynamic libraries, should dependencies be included in the main wine package, or packaged separately?
Aren't many of them already packages separately? For example mingw32-libpng and mingw32-gnutls?
Thanks, I wasn't aware of these. I had tried to search for Fedora mingw packages, but didn't realize that looking up "mingw" on rpmfind.net wasn't enough :-/
Note that this ties into (3) though. It would presumably be enough for static libraries, but we need specially named shared libraries, and we can't "just" use these packages since as far as I'm aware there's no standardized way to find them.
Why does wine need to use special names ?
In terms of locating them, you can find them using pkg-config eg
$ i686-w64-mingw32-pkg-config --variable prefix zlib /usr/i686-w64-mingw32/sys-root/mingw
tells you the install prefix under which it lives, and you'll find the dll in the bin/ sub-directory
/usr/i686-w64-mingw32/sys-root/mingw/bin/zlib1.dll
or the import lib at
/usr/i686-w64-mingw32/sys-root/mingw/lib/libz.dll.a
Regards, Daniel
On 9/2/21 12:34 PM, Daniel P. Berrangé wrote:
On Thu, Sep 02, 2021 at 12:11:43PM -0500, Zebediah Figura (she/her) wrote:
On 9/2/21 12:08 PM, Florian Weimer wrote:
- Zebediah Figura:
(2) If we use dynamic libraries, should dependencies be included in the main wine package, or packaged separately?
Aren't many of them already packages separately? For example mingw32-libpng and mingw32-gnutls?
Thanks, I wasn't aware of these. I had tried to search for Fedora mingw packages, but didn't realize that looking up "mingw" on rpmfind.net wasn't enough :-/
Note that this ties into (3) though. It would presumably be enough for static libraries, but we need specially named shared libraries, and we can't "just" use these packages since as far as I'm aware there's no standardized way to find them.
Why does wine need to use special names ?
Some Windows applications ship and link to their own versions of these libraries. They might have a wrong major version, or be out of date in some critical way. Because of the way the Windows loader works (and therefore, necessarily, the Wine loader), if a DLL links to zlib1.dll and a DLL named zlib1.dll has been already loaded in memory, that DLL will be the one loaded. Then you can get an ugly situation like:
* application foo.exe links to zlib1.dll * application copy of zlib1.dll is loaded * application loads Wine's builtin opcservices.dll * opcservices.dll links to zlib1.dll * application copy of zlib1.dll is already loaded, so we don't load the system copy * opcservices.dll tries to use some newer feature of zlib1.dll and fails.
Or a reverse:
* application links to opcservices.dll * Wine loads the builtin copy of zlib1.dll * application loads zlib1.dll, expecting its own * application tries to use some custom-patched feature of zlib and breaks when it's not present.
Admittedly zlib is a bad example when it comes to breaking compatibility, but it was the first DLL name that came to mind ;-)
So for shared libraries, we need Wine-specific names to make sure that we don't conflict with application-shipped libraries. And this applies recursively to dependencies.
Sorry for double-posting, my mail client helpfully removed everything from CC for me :-(
On 9/2/21 12:34 PM, Daniel P. Berrangé wrote:
On Thu, Sep 02, 2021 at 12:11:43PM -0500, Zebediah Figura (she/her) wrote:
On 9/2/21 12:08 PM, Florian Weimer wrote:
- Zebediah Figura:
(2) If we use dynamic libraries, should dependencies be included in the main wine package, or packaged separately?
Aren't many of them already packages separately? For example mingw32-libpng and mingw32-gnutls?
Thanks, I wasn't aware of these. I had tried to search for Fedora mingw packages, but didn't realize that looking up "mingw" on rpmfind.net wasn't enough :-/
Note that this ties into (3) though. It would presumably be enough for static libraries, but we need specially named shared libraries, and we can't "just" use these packages since as far as I'm aware there's no standardized way to find them.
Why does wine need to use special names ?
Some Windows applications ship and link to their own versions of these libraries. They might have a wrong major version, or be out of date in some critical way. Because of the way the Windows loader works (and therefore, necessarily, the Wine loader), if a DLL links to zlib1.dll and a DLL named zlib1.dll has been already loaded in memory, that DLL will be the one loaded. Then you can get an ugly situation like:
* application foo.exe links to zlib1.dll * application copy of zlib1.dll is loaded * application loads Wine's builtin opcservices.dll * opcservices.dll links to zlib1.dll * application copy of zlib1.dll is already loaded, so we don't load the system copy * opcservices.dll tries to use some newer feature of zlib1.dll and fails.
Or a reverse:
* application links to opcservices.dll * Wine loads the builtin copy of zlib1.dll * application loads zlib1.dll, expecting its own * application tries to use some custom-patched feature of zlib and breaks when it's not present.
Admittedly zlib is a bad example when it comes to breaking compatibility, but it was the first DLL name that came to mind
So for shared libraries, we need Wine-specific names to make sure that we don't conflict with application-shipped libraries. And this applies recursively to dependencies.
On Thu, Sep 02, 2021 at 12:46:09PM -0500, Zebediah Figura (she/her) wrote:
Sorry for double-posting, my mail client helpfully removed everything from CC for me :-(
On 9/2/21 12:34 PM, Daniel P. Berrangé wrote:
On Thu, Sep 02, 2021 at 12:11:43PM -0500, Zebediah Figura (she/her) wrote:
On 9/2/21 12:08 PM, Florian Weimer wrote:
- Zebediah Figura:
(2) If we use dynamic libraries, should dependencies be included in the main wine package, or packaged separately?
Aren't many of them already packages separately? For example mingw32-libpng and mingw32-gnutls?
Thanks, I wasn't aware of these. I had tried to search for Fedora mingw packages, but didn't realize that looking up "mingw" on rpmfind.net wasn't enough :-/
Note that this ties into (3) though. It would presumably be enough for static libraries, but we need specially named shared libraries, and we can't "just" use these packages since as far as I'm aware there's no standardized way to find them.
Why does wine need to use special names ?
Some Windows applications ship and link to their own versions of these libraries. They might have a wrong major version, or be out of date in some critical way. Because of the way the Windows loader works (and therefore, necessarily, the Wine loader), if a DLL links to zlib1.dll and a DLL named zlib1.dll has been already loaded in memory, that DLL will be the one loaded. Then you can get an ugly situation like:
- application foo.exe links to zlib1.dll
- application copy of zlib1.dll is loaded
- application loads Wine's builtin opcservices.dll
- opcservices.dll links to zlib1.dll
- application copy of zlib1.dll is already loaded, so we don't load the
system copy
- opcservices.dll tries to use some newer feature of zlib1.dll and fails.
Or a reverse:
- application links to opcservices.dll
- Wine loads the builtin copy of zlib1.dll
- application loads zlib1.dll, expecting its own
- application tries to use some custom-patched feature of zlib and
breaks when it's not present.
Admittedly zlib is a bad example when it comes to breaking compatibility, but it was the first DLL name that came to mind
So for shared libraries, we need Wine-specific names to make sure that we don't conflict with application-shipped libraries. And this applies recursively to dependencies.
Is it possible to modify existing DLLs to update their name ? I presume it is more than just renaming the file itself - some internal data field containing the reference name, similar to ELF's SONAME field ?
I'm thinking if you can just "edit" the existing DLLs to set the new name, then it is possible to avoid building & packaging it all twice
Regards, Daniel
On 9/2/21 1:04 PM, Daniel P. Berrangé wrote:
On Thu, Sep 02, 2021 at 12:46:09PM -0500, Zebediah Figura (she/her) wrote:
Sorry for double-posting, my mail client helpfully removed everything from CC for me :-(
On 9/2/21 12:34 PM, Daniel P. Berrangé wrote:
On Thu, Sep 02, 2021 at 12:11:43PM -0500, Zebediah Figura (she/her) wrote:
On 9/2/21 12:08 PM, Florian Weimer wrote:
- Zebediah Figura:
(2) If we use dynamic libraries, should dependencies be included in the main wine package, or packaged separately?
Aren't many of them already packages separately? For example mingw32-libpng and mingw32-gnutls?
Thanks, I wasn't aware of these. I had tried to search for Fedora mingw packages, but didn't realize that looking up "mingw" on rpmfind.net wasn't enough :-/
Note that this ties into (3) though. It would presumably be enough for static libraries, but we need specially named shared libraries, and we can't "just" use these packages since as far as I'm aware there's no standardized way to find them.
Why does wine need to use special names ?
Some Windows applications ship and link to their own versions of these libraries. They might have a wrong major version, or be out of date in some critical way. Because of the way the Windows loader works (and therefore, necessarily, the Wine loader), if a DLL links to zlib1.dll and a DLL named zlib1.dll has been already loaded in memory, that DLL will be the one loaded. Then you can get an ugly situation like:
- application foo.exe links to zlib1.dll
- application copy of zlib1.dll is loaded
- application loads Wine's builtin opcservices.dll
- opcservices.dll links to zlib1.dll
- application copy of zlib1.dll is already loaded, so we don't load the
system copy
- opcservices.dll tries to use some newer feature of zlib1.dll and fails.
Or a reverse:
- application links to opcservices.dll
- Wine loads the builtin copy of zlib1.dll
- application loads zlib1.dll, expecting its own
- application tries to use some custom-patched feature of zlib and
breaks when it's not present.
Admittedly zlib is a bad example when it comes to breaking compatibility, but it was the first DLL name that came to mind
So for shared libraries, we need Wine-specific names to make sure that we don't conflict with application-shipped libraries. And this applies recursively to dependencies.
Is it possible to modify existing DLLs to update their name ? I presume it is more than just renaming the file itself - some internal data field containing the reference name, similar to ELF's SONAME field ?
I'm thinking if you can just "edit" the existing DLLs to set the new name, then it is possible to avoid building & packaging it all twice
We can rename DLLs at install time, but it's trickier than that—we need to also rename their imports. Patching import tables is not trivial.
That said, I think I may have been wrong: there *may* be a workable solution that lets us use system DLLs without renaming. I'm not sure that we won't hit any internal snags, but it doesn't seem out of the question just yet.
It's worth pointing out that we will almost certainly need a fallback solution, if we do end up using shared libraries and *-w64-mingw32-pkg-config. This is mainly because Fedora, as far as I can tell, is unusual in providing mingw libraries (Debian ships a scant few; Arch ships none and in fact only recently even started shipping the cross-compiler.) And even Fedora doesn't provide all of the libraries we need.
I'm happy to work with Fedora and with other distributions to help get support across the board for mingw libraries and pkg-config, but it's going to be a hard sell to the Wine maintainers to rely on a feature that isn't widely supported. Still, we might be able to use it where it's present...
On Thu, Sep 02, 2021 at 04:58:01PM -0500, Zebediah Figura (she/her) wrote:
It's worth pointing out that we will almost certainly need a fallback solution, if we do end up using shared libraries and *-w64-mingw32-pkg-config. This is mainly because Fedora, as far as I can tell, is unusual in providing mingw libraries (Debian ships a scant few; Arch ships none and in fact only recently even started shipping the cross-compiler.) And even Fedora doesn't provide all of the libraries we need.
I'm happy to work with Fedora and with other distributions to help get support across the board for mingw libraries and pkg-config, but it's going to be a hard sell to the Wine maintainers to rely on a feature that isn't widely supported. Still, we might be able to use it where it's present...
I'm surprised - I thought Debian had a fairly complete set but I checked just now and they don't have many. OpenSUSE's package set is a bit thin which is also a surprise because we collaborated with them on packaging in the early days. (I might be looking in the wrong place for OpenSUSE).
Does Wine need 32- or 64-bit packages (or both)?
Rich.
On Fri, Sep 03, 2021 at 01:13:13PM +0100, Richard W.M. Jones wrote:
On Thu, Sep 02, 2021 at 04:58:01PM -0500, Zebediah Figura (she/her) wrote:
It's worth pointing out that we will almost certainly need a fallback solution, if we do end up using shared libraries and *-w64-mingw32-pkg-config. This is mainly because Fedora, as far as I can tell, is unusual in providing mingw libraries (Debian ships a scant few; Arch ships none and in fact only recently even started shipping the cross-compiler.) And even Fedora doesn't provide all of the libraries we need.
I'm happy to work with Fedora and with other distributions to help get support across the board for mingw libraries and pkg-config, but it's going to be a hard sell to the Wine maintainers to rely on a feature that isn't widely supported. Still, we might be able to use it where it's present...
I'm surprised - I thought Debian had a fairly complete set but I checked just now and they don't have many.
For Debian, I believe people typically add the "MXE" project apt repos
https://mxe.cc/ https://pkg.mxe.cc/repos/apt/dists/
Regards, Daniel
On Fri, Sep 3, 2021 at 8:13 AM Richard W.M. Jones rjones@redhat.com wrote:
On Thu, Sep 02, 2021 at 04:58:01PM -0500, Zebediah Figura (she/her) wrote:
It's worth pointing out that we will almost certainly need a fallback solution, if we do end up using shared libraries and *-w64-mingw32-pkg-config. This is mainly because Fedora, as far as I can tell, is unusual in providing mingw libraries (Debian ships a scant few; Arch ships none and in fact only recently even started shipping the cross-compiler.) And even Fedora doesn't provide all of the libraries we need.
I'm happy to work with Fedora and with other distributions to help get support across the board for mingw libraries and pkg-config, but it's going to be a hard sell to the Wine maintainers to rely on a feature that isn't widely supported. Still, we might be able to use it where it's present...
I'm surprised - I thought Debian had a fairly complete set but I checked just now and they don't have many. OpenSUSE's package set is a bit thin which is also a surprise because we collaborated with them on packaging in the early days. (I might be looking in the wrong place for OpenSUSE).
openSUSE maintains them in a separate devel project for now:
* Windows 32-bit x86: https://build.opensuse.org/project/show/windows:mingw:win32 * Windows 64-bit x86: https://build.opensuse.org/project/show/windows:mingw:win64
Once Wine needs them, they'll probably land in openSUSE:Factory and go into Tumbleweed.
On 9/3/21 7:13 AM, Richard W.M. Jones wrote:
On Thu, Sep 02, 2021 at 04:58:01PM -0500, Zebediah Figura (she/her) wrote:
It's worth pointing out that we will almost certainly need a fallback solution, if we do end up using shared libraries and *-w64-mingw32-pkg-config. This is mainly because Fedora, as far as I can tell, is unusual in providing mingw libraries (Debian ships a scant few; Arch ships none and in fact only recently even started shipping the cross-compiler.) And even Fedora doesn't provide all of the libraries we need.
I'm happy to work with Fedora and with other distributions to help get support across the board for mingw libraries and pkg-config, but it's going to be a hard sell to the Wine maintainers to rely on a feature that isn't widely supported. Still, we might be able to use it where it's present...
I'm surprised - I thought Debian had a fairly complete set but I checked just now and they don't have many. OpenSUSE's package set is a bit thin which is also a surprise because we collaborated with them on packaging in the early days. (I might be looking in the wrong place for OpenSUSE).
Does Wine need 32- or 64-bit packages (or both)?
We will need both 32-bit and 64-bit MinGW packages.
(On the plus side, one of the reasons we're building things in PE format is to have true WoW64 support. I've seen some distributions [and Mac OS] agitating to drop 32-bit support; I don't know if Fedora is one of them, but having everything in PE format would allow us to potentially drop 32-bit dependencies for all of our system libraries, including the ones that aren't in PE.)
On Thu, Sep 02, 2021 at 12:11:43PM -0500, Zebediah Figura (she/her) wrote:
On 9/2/21 12:08 PM, Florian Weimer wrote:
- Zebediah Figura:
(2) If we use dynamic libraries, should dependencies be included in the main wine package, or packaged separately?
Aren't many of them already packages separately? For example mingw32-libpng and mingw32-gnutls?
Thanks, I wasn't aware of these. I had tried to search for Fedora mingw packages, but didn't realize that looking up "mingw" on rpmfind.net wasn't enough :-/
BTW, current full list of mingw builds present in Fedora 34 seems to cover about 1/2 of the libs your first mail listed. Here is everything in F34 today:
mingw32-adwaita-icon-theme.noarch mingw32-adwaita-qt5.noarch mingw32-angleproject.noarch mingw32-angleproject-static.noarch mingw32-antlr.noarch mingw32-antlr-static.noarch mingw32-atkmm.noarch mingw32-atk.noarch mingw32-atk-static.noarch mingw32-biblesync.noarch mingw32-binutils.x86_64 mingw32-boost.noarch mingw32-boost-static.noarch mingw32-brotli.noarch mingw32-bsdcat.noarch mingw32-bsdcpio.noarch mingw32-bsdtar.noarch mingw32-bzip2.noarch mingw32-bzip2-static.noarch mingw32-cairomm.noarch mingw32-cairomm-static.noarch mingw32-cairo.noarch mingw32-cairo-static.noarch mingw32-c-ares.noarch mingw32-cfitsio.noarch mingw32-cfitsio-tools.noarch mingw32-clucene.noarch mingw32-cmocka.noarch mingw32-cmocka-static.noarch mingw32-colord-gtk.noarch mingw32-colord-gtk-static.noarch mingw32-colord.noarch mingw32-colord-static.noarch mingw32-cppunit.noarch mingw32-cpp.x86_64 mingw32-crossreport.noarch mingw32-crt.noarch mingw32-curl.noarch mingw32-curl-static.noarch mingw32-cxxtest.noarch mingw32-dbus-glib.noarch mingw32-dbus-glib-static.noarch mingw32-dbus.noarch mingw32-dbus-static.noarch mingw32-dirac.noarch mingw32-djvulibre.noarch mingw32-djvulibre-tools.noarch mingw32-dlfcn.noarch mingw32-dlfcn-static.noarch mingw32-drmingw-devel.noarch mingw32-drmingw.noarch mingw32-eigen3.noarch mingw32-enchant2.noarch mingw32-exiv2.noarch mingw32-expat.noarch mingw32-expat-static.noarch mingw32-fcgi.noarch mingw32-fftw.noarch mingw32-fftw-static.noarch mingw32-filesystem.noarch mingw32-flac.noarch mingw32-flac-tools.noarch mingw32-fltk.noarch mingw32-fltk-static.noarch mingw32-fontconfig.noarch mingw32-fontconfig-static.noarch mingw32-freeglut.noarch mingw32-freeimage.noarch mingw32-freeimage-static.noarch mingw32-freetype.noarch mingw32-freetype-static.noarch mingw32-freexl.noarch mingw32-fribidi.noarch mingw32-fribidi-static.noarch mingw32-ftplib.noarch mingw32-g2clib.noarch mingw32-gcc-c++.x86_64 mingw32-gcc-gfortran.x86_64 mingw32-gcc-objc++.x86_64 mingw32-gcc-objc.x86_64 mingw32-gcc.x86_64 mingw32-GConf2.noarch mingw32-gdal.noarch mingw32-gdal-tools.noarch mingw32-gdbm.noarch mingw32-gdbm-static.noarch mingw32-gdb.noarch mingw32-gdk-pixbuf.noarch mingw32-GeographicLib.noarch mingw32-geos.noarch mingw32-gettext.noarch mingw32-gettext-static.noarch mingw32-giflib.noarch mingw32-giflib-static.noarch mingw32-giflib-tools.noarch mingw32-glew.noarch mingw32-glew-static.noarch mingw32-glew-tools.noarch mingw32-glib2.noarch mingw32-glib2-static.noarch mingw32-glibmm24.noarch mingw32-glibmm24-static.noarch mingw32-glib-networking.noarch mingw32-glslang.noarch mingw32-gmp.noarch mingw32-gnutls.noarch mingw32-goocanvas2.noarch mingw32-graphite2.noarch mingw32-graphite2-static.noarch mingw32-gsl.noarch mingw32-gsl-static.noarch mingw32-gsm.noarch mingw32-gsm-tools.noarch mingw32-gstreamer1.noarch mingw32-gstreamer1-plugins-bad-free.noarch mingw32-gstreamer1-plugins-base.noarch mingw32-gstreamer1-plugins-good.noarch mingw32-gstreamer.noarch mingw32-gtk2.noarch mingw32-gtk2-static.noarch mingw32-gtk3.noarch mingw32-gtkmm24.noarch mingw32-gtkmm30.noarch mingw32-gtksourceview3.noarch mingw32-gtksourceviewmm3.noarch mingw32-gtkspell3.noarch mingw32-gtkspell3-static.noarch mingw32-gtkspellmm30.noarch mingw32-gtkspellmm30-static.noarch mingw32-gtk-update-icon-cache.noarch mingw32-gtk-vnc2.noarch mingw32-gvnc.noarch mingw32-gvnc-tools.noarch mingw32-hamlib.noarch mingw32-harfbuzz.noarch mingw32-harfbuzz-static.noarch mingw32-headers.noarch mingw32-hicolor-icon-theme.noarch mingw32-hidapi.noarch mingw32-hidapi-static.noarch mingw32-hunspell.noarch mingw32-hunspell-static.noarch mingw32-hunspell-tools.noarch mingw32-icu.noarch mingw32-id3lib.noarch mingw32-id3lib-tools.noarch mingw32-jansson.noarch mingw32-jasper.noarch mingw32-jasper-static.noarch mingw32-jimtcl.noarch mingw32-jsoncpp.noarch mingw32-json-glib.noarch mingw32-jxrlib.noarch mingw32-lcms2.noarch mingw32-lcms2-static.noarch mingw32-lcms.noarch mingw32-lcms-static.noarch mingw32-leptonica.noarch mingw32-leptonica-static.noarch mingw32-libadwaita-qt5.noarch mingw32-libadwaita-qt5-static.noarch mingw32-libarchive.noarch mingw32-libarchive-static.noarch mingw32-libcharset.noarch mingw32-libconfuse.noarch mingw32-libcroco.noarch mingw32-libcroco-static.noarch mingw32-libepoxy.noarch mingw32-libffi.noarch mingw32-libffi-static.noarch mingw32-libftdi.noarch mingw32-libgamerzilla.noarch mingw32-libgcrypt.noarch mingw32-libgcrypt-static.noarch mingw32-libgeotiff.noarch mingw32-libgeotiff-static.noarch mingw32-libgeotiff-tools.noarch mingw32-libglade2.noarch mingw32-libglade2-static.noarch mingw32-libglademm24.noarch mingw32-libgnurx.noarch mingw32-libgnurx-static.noarch mingw32-libgomp.x86_64 mingw32-libgovirt.noarch mingw32-libgovirt-static.noarch mingw32-libgpg-error.noarch mingw32-libgpg-error-static.noarch mingw32-libgsf.noarch mingw32-libgsf-static.noarch mingw32-libgta.noarch mingw32-libgusb.noarch mingw32-libgusb-static.noarch mingw32-libid3tag.noarch mingw32-libIDL.noarch mingw32-libIDL-static.noarch mingw32-libidn2.noarch mingw32-libidn2-static.noarch mingw32-libidn.noarch mingw32-libidn-static.noarch mingw32-libimagequant.noarch mingw32-libjpeg-turbo.noarch mingw32-libjpeg-turbo-static.noarch mingw32-libkml.noarch mingw32-libltdl.noarch mingw32-libmad.noarch mingw32-libmicrohttpd.noarch mingw32-libmicrohttpd-static.noarch mingw32-libmng.noarch mingw32-libmng-static.noarch mingw32-libogg.noarch mingw32-libosinfo.noarch mingw32-libpng.noarch mingw32-libpng-static.noarch mingw32-libpsl.noarch mingw32-LibRaw.noarch mingw32-LibRaw-static.noarch mingw32-LibRaw-tools.noarch mingw32-librsvg2.noarch mingw32-librsvg2-static.noarch mingw32-librttopo.noarch mingw32-libsigc++20.noarch mingw32-libsigc++20-static.noarch mingw32-libsigsegv.noarch mingw32-libsoup.noarch mingw32-libspatialite.noarch mingw32-libsq3.noarch mingw32-libsqlite3x.noarch mingw32-libssh2.noarch mingw32-libssh2-static.noarch mingw32-libtasn1.noarch mingw32-libtheora.noarch mingw32-libtiff.noarch mingw32-libtiff-static.noarch mingw32-libunistring.noarch mingw32-libusbx.noarch mingw32-libusbx-static.noarch mingw32-libvirt-gconfig.noarch mingw32-libvirt-glib.noarch mingw32-libvirt-gobject.noarch mingw32-libvirt.noarch mingw32-libvirt-static.noarch mingw32-libvorbis.noarch mingw32-libwebp.noarch mingw32-libxml2.noarch mingw32-libxml2-static.noarch mingw32-libxml++.noarch mingw32-libxslt.noarch mingw32-libxslt-static.noarch mingw32-libzip.noarch mingw32-llvm-static.noarch mingw32-llvm-tools.noarch mingw32-llvm.x86_64 mingw32-log4c.noarch mingw32-mediawriter.noarch mingw32-minizip.noarch mingw32-mpfr.noarch mingw32-nettle.noarch mingw32-nsiswrapper.noarch mingw32-nsis.x86_64 mingw32-openal-soft.noarch mingw32-opencv.noarch mingw32-opencv-tools.noarch mingw32-openexr.noarch mingw32-openexr-tools.noarch mingw32-openjpeg2.noarch mingw32-openjpeg2-tools.noarch mingw32-openssl.noarch mingw32-openssl-static.noarch mingw32-opusfile.noarch mingw32-opus.noarch mingw32-orc-compiler.noarch mingw32-orc.noarch mingw32-osinfo-db-tools.noarch mingw32-p11-kit.noarch mingw32-pangomm.noarch mingw32-pango.noarch mingw32-pango-static.noarch mingw32-pcre2.noarch mingw32-pcre2-static.noarch mingw32-pcre.noarch mingw32-pcre-static.noarch mingw32-pdcurses.noarch mingw32-physfs.noarch mingw32-physfs-static.noarch mingw32-pixman.noarch mingw32-pixman-static.noarch mingw32-pkg-config.x86_64 mingw32-plotmm.noarch mingw32-plotmm-static.noarch mingw32-podofo.noarch mingw32-podofo-tools.noarch mingw32-polyclipping.noarch mingw32-poppler-cpp.noarch mingw32-poppler-glib.noarch mingw32-poppler.noarch mingw32-poppler-qt5.noarch mingw32-portablexdr.noarch mingw32-portablexdr-static.noarch mingw32-portaudio.noarch mingw32-postgresql.noarch mingw32-postgresql-static.noarch mingw32-proj.noarch mingw32-protobuf.noarch mingw32-protobuf-static.noarch mingw32-protobuf-tools.noarch mingw32-python3-affine.noarch mingw32-python3-certifi.noarch mingw32-python3-chardet.noarch mingw32-python3-click.noarch mingw32-python3-Cython.noarch mingw32-python3-dateutil.noarch mingw32-python3-flask.noarch mingw32-python3-gdal.noarch mingw32-python3-GeographicLib.noarch mingw32-python3-homography.noarch mingw32-python3-idna.noarch mingw32-python3-itsdangerous.noarch mingw32-python3-jinja2.noarch mingw32-python3-libkml.noarch mingw32-python3-lxml.noarch mingw32-python3-markupsafe.noarch mingw32-python3.noarch mingw32-python3-numpy.noarch mingw32-python3-opencv.noarch mingw32-python3-OWSLib.noarch mingw32-python3-pillow.noarch mingw32-python3-psycopg2.noarch mingw32-python3-pygments.noarch mingw32-python3-pyqt5-sip.x86_64 mingw32-python3-pytz.noarch mingw32-python3-pyyaml.noarch mingw32-python3-qscintilla-qt5.noarch mingw32-python3-qt5.x86_64 mingw32-python3-requests.noarch mingw32-python3-setuptools.noarch mingw32-python3-setuptools_scm.noarch mingw32-python3-shapely.noarch mingw32-python3-sip.x86_64 mingw32-python3-six.noarch mingw32-python3-urllib3.noarch mingw32-python3-werkzeug.noarch mingw32-qca-qt5.noarch mingw32-qextserialport-qt5.noarch mingw32-qscintilla-qt5.noarch mingw32-qt5-qmake.x86_64 mingw32-qt5-qmldevtools-devel.i686 mingw32-qt5-qmldevtools-devel.x86_64 mingw32-qt5-qmldevtools.x86_64 mingw32-qt5-qt3d.noarch mingw32-qt5-qt3d-tools.x86_64 mingw32-qt5-qtactiveqt.noarch mingw32-qt5-qtbase-devel.i686 mingw32-qt5-qtbase-devel.x86_64 mingw32-qt5-qtbase.noarch mingw32-qt5-qtbase-static.noarch mingw32-qt5-qtcharts.noarch mingw32-qt5-qtdeclarative.noarch mingw32-qt5-qtdeclarative-static.noarch mingw32-qt5-qtgraphicaleffects.noarch mingw32-qt5-qtimageformats.noarch mingw32-qt5-qtlocation.noarch mingw32-qt5-qtmultimedia.noarch mingw32-qt5-qtquickcontrols2.noarch mingw32-qt5-qtquickcontrols2-static.noarch mingw32-qt5-qtquickcontrols.noarch mingw32-qt5-qtquickcontrols-static.noarch mingw32-qt5-qtscript.noarch mingw32-qt5-qtsensors.noarch mingw32-qt5-qtserialport.noarch mingw32-qt5-qtsvg.noarch mingw32-qt5-qttools.noarch mingw32-qt5-qttools-tools.x86_64 mingw32-qt5-qttranslations.noarch mingw32-qt5-qtwebchannel.noarch mingw32-qt5-qtwebkit.noarch mingw32-qt5-qtwebsockets.noarch mingw32-qt5-qtwinextras.noarch mingw32-qt5-qtxmlpatterns.noarch mingw32-qtkeychain-qt5.noarch mingw32-qtspell-qt5.noarch mingw32-qtspell-qt5-static.noarch mingw32-quazip-qt5.noarch mingw32-quazip-qt5-static.noarch mingw32-qwtpolar-qt5.noarch mingw32-qwt-qt5.noarch mingw32-readline.noarch mingw32-readline-static.noarch mingw32-rest.noarch mingw32-rest-static.noarch mingw32-sane-backends.noarch mingw32-sane-backends-static.noarch mingw32-SDL2_image.noarch mingw32-SDL2_mixer.noarch mingw32-SDL2.noarch mingw32-SDL2-static.noarch mingw32-SDL2_ttf.noarch mingw32-SDL_image.noarch mingw32-SDL_mixer.noarch mingw32-SDL.noarch mingw32-SDL_ttf.noarch mingw32-shapelib.noarch mingw32-shapelib-static.noarch mingw32-shapelib-tools.noarch mingw32-sigar.noarch mingw32-sparsehash.noarch mingw32-spatialindex.noarch mingw32-speexdsp.noarch mingw32-speex.noarch mingw32-speex-tools.noarch mingw32-spice-glib.noarch mingw32-spice-gtk3.noarch mingw32-spice-protocol.noarch mingw32-spirv-headers.noarch mingw32-spirv-tools.noarch mingw32-sqlite.noarch mingw32-sqlite-static.noarch mingw32-srvany.noarch mingw32-svg2svgt.noarch mingw32-sword.noarch mingw32-taglib.noarch mingw32-tcl.noarch mingw32-termcap.noarch mingw32-termcap-static.noarch mingw32-tesseract.noarch mingw32-tesseract-static.noarch mingw32-tesseract-tools.noarch mingw32-theora-tools.noarch mingw32-tk.noarch mingw32-twaindsm.noarch mingw32-uriparser.noarch mingw32-usbredir.noarch mingw32-usbredir-static.noarch mingw32-vulkan-headers.noarch mingw32-vulkan-loader.noarch mingw32-vulkan-tools.noarch mingw32-vulkan-validation-layers.noarch mingw32-wavpack.noarch mingw32-wavpack-tools.noarch mingw32-windows-default-manifest.noarch mingw32-wine-gecko.noarch mingw32-win-iconv.noarch mingw32-win-iconv-static.noarch mingw32-winpthreads.noarch mingw32-winpthreads-static.noarch mingw32-winstorecompat.noarch mingw32-wpcap-docs.noarch mingw32-wpcap-examples.noarch mingw32-wpcap.noarch mingw32-wxWidgets3.noarch mingw32-wxWidgets3-static.noarch mingw32-wxWidgets.noarch mingw32-wxWidgets-static.noarch mingw32-xerces-c.noarch mingw32-xz-libs.noarch mingw32-xz-libs-static.noarch mingw32-xz.noarch mingw32-yaml-cpp.noarch mingw32-zfstream.noarch mingw32-zlib.noarch mingw32-zlib-static.noarch mingw32-zstd.noarch
(there are equiv mingw64 packages too)
Regards, Daniel
On Thu, Sep 02, 2021 at 12:11:43PM -0500, Zebediah Figura (she/her) wrote:
On 9/2/21 12:08 PM, Florian Weimer wrote:
- Zebediah Figura:
(2) If we use dynamic libraries, should dependencies be included in the main wine package, or packaged separately?
Aren't many of them already packages separately? For example mingw32-libpng and mingw32-gnutls?
Thanks, I wasn't aware of these. I had tried to search for Fedora mingw packages, but didn't realize that looking up "mingw" on rpmfind.net wasn't enough :-/
Just a note that the authoritative source is:
https://src.fedoraproject.org/rpms/mingw-gnutls
(substitute package name as appropriate). There's also a search engine at https://src.fedoraproject.org/projects/rpms/%2A
Note that this ties into (3) though. It would presumably be enough for static libraries, but we need specially named shared libraries, and we can't "just" use these packages since as far as I'm aware there's no standardized way to find them.
Some of the mingw packages have static subpackages already, and those that don't can usually be enabled with relative ease. eg. for gnutls you'd have to make a few obvious changes to the spec file:
https://src.fedoraproject.org/rpms/mingw-gnutls/blob/rawhide/f/mingw-gnutls....
I think the important question is do these libraries match what Wine is expecting to use?
Rich.
packaging@lists.fedoraproject.org