So, I figure it's probably worth quantifying what we'd gain this way (as well as how many libraries we'd potentially have to build or maintain). As I see it, the libraries that can be built as PE (unless I misunderstand what any one of them requires, so please correct me if I'm wrong) are:
* zlib (of course, we'd undo the source import) * GLU * OSMesa * libxml2/libxslt * gnutls * v4l2 (but see below under qcap) * freetype * libunwind (but ntdll needs a .so component anyway) * FAudio * libgsm * libkrb5/libgssapi * jpeg, tiff, png * mpg123 * openal? * odbc? * vkd3d
And libraries that cannot (or should not be) are:
* X11 (etc.) * GL * pcap (we could build this as PE, but then we'd need to implement things like ndis.sys, which would be painful.) * dbus * hal * ncurses (I think?) * sane * gphoto2 * resolv (I think?) * pulse * gstreamer (we could build this as PE, but we'd lose host plugins) * udev * SDL2 * capi20 * cups * netapi (or could we manhandle this into building on top of winsock?) * vulkan
Which allows us to build the following as PE:
* wininet, dbghelp, opcservices, cabinet (already PE, but we could remove the imported zlib source) * glu32 (but why do we have this again?) * msxml3 * qcap? (It needs to do ioctls to Unix devices. But we can already open them with Win32 devices, and we could maybe map NtDeviceIoControlFile() to ioctl()?) * dwrite * xaudio et al. * msgsm32.acm * kerberos * user32, windowscodecs * mp3dmod * openal32 * odbc32, odbccu32 * d3d12, dxgi
There's also the following, which we *could* build as PE if we throw away the Mac parts and require PE libraries—I don't think I can judge the impact of this:
* gdi32 * bcrypt, crypt32, secur32 * l3codeca.acm
On 2/14/20 12:43 PM, Esme Povirk (they/them) wrote:
Options for distributing dependencies:
- Distribute headers and libs in a tarball built from wine-pedeps.
The binaries would be part of an addon, also built from wine-pedeps.
I personally don't like this. I think there's value in (1) not requiring the user to install libraries they don't need (like, say, libkrb5), (2) not prompting for every add-on (personally I feel that two is already too many), (3) letting the distribution choose what to distribute by default.
- Rely on the host distribution to package mingw headers, libs, and
binaries for the dependencies we need. The binaries would then be distributed with Wine. Fedora is the only distribution I'm aware of that has an extensive library of mingw packages. To make this easier on other distros, I could maintain wine-pedeps as an alternative source of headers, libraries, and binaries at build time. The trouble with this approach is that it's not clear how we can keep Wine's libraries independent from the application.
This was the idea that I proposed when the discussion came up internally. It strikes me as the architecturally "correct" thing to do. We're essentially building some of our files with a different host architecture, so just as we'd link separately to x86_64-pc-linux-gnu libraries and i686-pc-linux-gnu libraries, so too would we link separately to x86_64-w64-mingw32 libraries (as well as i686-w64-mingw32).
Thus we'd want to adjust configure to check for those libraries using *-w64-mingw32-pkg-config, define separate m4 macros to wrap AC_CHECK_LIB/AC_CHECK_HEADER/WINE_CHECK_SONAME in mingw tools, etc, but the task of actually providing those headers and libraries stays outside of Wine.
That this is the right thing to do is, I think, proven by the fact that (some) distributions provide such libraries. [As Esme said, only Fedora provides all of the libraries we need, but I know that Debian/Ubuntu does provide zlib, although I think only zlib.] So of course it would be our responsibility to build and distribute those libraries for most distributions, until/unless we can merge them into their respective "main" repositories. I know Rosanne probably isn't thrilled about this, but I'd be willing to volunteer to maintain those packages.
I've attached a patch—very messy so far—that sort of outlines how this would work, converting msxml3 to PE. One thing it doesn't do but should is fall back to host tools when mingw isn't available. Generally, though, it should roughly illustrate what I'm trying to propose.
I don't know what we'd do about Mac, but along the same lines, I'd think we'd want to extend/analogize the current solution regarding bitness to the whole architecture triple.
Perhaps an automated process could rename the binaries and edit their import tables, or sxs could be added after the fact.
I think some sort of manifest hack would be appropriate here, that ntdll would check when loading a builtin DLL. Presumably we don't even want the libraries to be copied into the prefix, but rather we want to make sure we load them always from /usr/i686-w64-mingw32/lib/* (or whatever the path is for any given distribution).